Repository: electron/electron (language: cpp)

Issue:
[Bug]: Renderer process crashes on power resume
### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

13.1.7

### What operating system are you using?

Windows

### Operating System Version

Windows 10 build 19043

### What arch are you using?

x64

### Last Known Working Electron version

_No response_

### Expected Behavior

Application should resume after power resume

### Actual Behavior

White screen in browser window after power resume (not always)

### Testcase Gist URL

_No response_

### Additional Information

There are no algorithm to 100% reproduce, just wake up computer and you may see white screen in electron app

Access violation exception
Call stack:
   AppName.exe!uv__wake_all_loops() Line 170    C
     AppName.exe!uv__system_resume_callback(void * Context, unsigned long Type, void * Setting) Line 41    C
     powrprof.dll!PowerpResumeSuspendCallback()    Unknown
     UMPDC.dll!00007ffd8b3d37c3()    Unknown
     UMPDC.dll!00007ffd8b3d371d()    Unknown
     UMPDC.dll!00007ffd8b3d35ca()    Unknown
     ntdll.dll!TppAlpcpExecuteCallback()    Unknown
     ntdll.dll!TppWorkerThread()    Unknown
     KERNEL32.DLL!BaseThreadInitThunk()    Unknown
     ntdll.dll!RtlUserThreadStart()    Unknown


Discussion / hints:
Hey @Xano, thanks for reporting this! Would it be possible for you to make a standalone testcase with only the code necessary to reproduce the issue? You can use Electron Fiddle to publish your test case to a gist that Electron maintainers can use. Stand-alone test cases make fixing issues go more smoothly: it ensure everyone's looking at the same issue, it removes all unnecessary variables from the equation, and it can also provide the basis for automated regression tests.

I also noticed you're using Electron 13, which is now EOL. Does the issue persist for you on Electron 14 or higher?

I'm adding the blocked/need-repro label for this reason. After you make a test case, please link to it in a followup comment. Thanks!
Unfortunately, we haven't got a way to reproduce this bug with guarantee. For a long period of time I got that crash only once after waking up my computer. Also we have a lot of crash reports every day, but we can say nothing about that excluding call stack. So, i can't provide you a standalone testcase.

Also i can't check that bug on Electron version 14 or higher, because i don't have a standalone testcase, and cant' upgrade our project, because we use 13.1.7 and a lot of work required to update Electron.
I'm investigating a similar electron crash on power resume for a client. I don't have a way to reproduce the issue. The crash happens also with higher electron version such as 16. In my case the app is **failing to load with error code -2.**. I'm waiting to receive the stack trace to compare it with the one of this ticket.
For my client app crashes only on power resume, after that it works fine.
We've noticed a large increase in crashes from users after upgrading from 10.1.7 to 13.6.7 that seems to be the same (or similar) issue. We're working on upgrading to 14+ but still working on the context aware native module transition. So far we've been unable to narrow down the cause of the crash or reproduce locally.

So far we've only seen it on Windows 10 64 bit.

```
OS Version: Windows 10.0.19044 (1566)
Report Version: 104

Crashed Thread: 37248

Application Specific Information:
Fatal Error: EXCEPTION_ACCESS_VIOLATION_READ

Thread 37248 Crashed:
0   electron.exe                    0x7ff6c8151c40      uv__wake_all_loops (core.c:170)
1   electron.exe                    0x7ff6c878ee12      uv__system_resume_callback (detect-wakeup.c:39)
2   powrprof.dll                    0x7fff5cac2ded      PowerpResumeSuspendCallback
3   UMPDC.dll                       0x7fff5c9837c2      PdcpProcessMessageInternal
4   UMPDC.dll                       0x7fff5c98371c      PdcpAlpcProcessMessage
5   UMPDC.dll                       0x7fff5c9835c9      PdcpAlpcCallback
6   ntdll.dll                       0x7fff600903bc      TppAlpcpExecuteCallback
7   ntdll.dll                       0x7fff600c2f25      TppWorkerThread
8   KERNEL32.DLL                    0x7fff5efe7033      BaseThreadInitThunk
9   ntdll.dll                       0x7fff600c2650      RtlUserThreadStart
```
This is also our top error report - just crash on power resume.

See detailed sentry crash report at:
https://sentry.wappler.io/share/issue/692f596d36b34183b56e27d01547ebab/

But it has the same crash signature:
```
UMPDC 			+0x0005eb3 	PdcPortSendMessage
powrprof 		+0x00035e7 	PowerpResumeSuspendCallback
UMPDC 			+0x00062d0 	PdcpProcessMessageInternal
UMPDC 			+0x00060d9 	PdcpAlpcProcessMessage
UMPDC 			+0x0005f09 	PdcpAlpcCallback
ntdll 			+0x002214c 	TppAlpcpExecuteCallback
ntdll 			+0x0016d97 	TppWorkerThread
KERNEL32.ntdll          +0x00154df 	BaseThreadInitThunk
ntdll 			+0x000485a 	RtlUserThreadStart
```

we have over 2000 reports about this and quickly growing. It is our most common problem.

We are also stuck to Electron 13 for now due to native module dependencies.

Please address this issue urgently.
The exact same crash is wreaking havoc in our production. 

@VerteDinde  Could Electron team at least confirm that the call stack is different in Electron 17? (since this problem still exist in E16). 
We are migrating our app to E17 because of this issue, but this is a significant effort in combination with absence of understanding that this issue is fixed in E17. 

I understand that E13 is no longer supported, but we cannot afford updating electron just to get the same issue again.

btw, it's impossible to reproduce this at will, many of our engineers tried very hard.
We met this issue as well. Can someone take a look? 

Fix patch:
diff --git a/shell/common/node_bindings.cc b/shell/common/node_bindings.cc
index 71a2f54eb5c65..c350720a67766 100644
--- a/shell/common/node_bindings.cc
+++ b/shell/common/node_bindings.cc
@@ -136,6 +136,7 @@ void stop_and_close_uv_loop(uv_loop_t* loop) {
       break;
 
   DCHECK_EQ(0, uv_loop_alive(loop));
+  uv_loop_close(loop);
 }
 
 bool g_is_initialized = false;


Test patch: