Gdi Explorer UPDATED
After this, you can make a scheduled task that runs this little guy. The bad part is that It will close any explorer window you have oppened, but at least it will keep windows usable if you leave it opened overnight.
Now, for me the problem is that Microsoft uses the same process, explorer.exe both for the "Taskbar/desktop" and the, now called, "File Explorer". Have been that way for ages (I think even was like that in Windows95, and a lot of users requested that to be changed, because those are separated tasks)
explorer!CTray::CheckGDIHandleLimit is on the call stack, so perhaps explorer has a GDI handle leak (maybe even related to a tray program?). you could track the handles of the explorer process to see if they are increasing over time before the crash occurs.
On your advice I am looking at the handle count of explorer.exe and using PerfMon to track the number I have noticed that during normal behavior the count is around 2,500, but when explorer crashes the count will drop to zero or close to it (from the 2,500 number) and quickly rise to around 5,500 handles for about a minute before sharply dropping back down to normal level of around 2,500. I'm not sure what this indicates yet, it could just be behavior related to Windows logging and reporting the explorer.exe crash event.
@EckiS I think the GDI count thing is on the right track. Thanks for pointing me in that direction. Windows 10 has a 10k GDI object limit per process and I believe that my explorer.exe is hitting that and then crashing. After the crash it quickly goes right back up to just under 10k so I need to figure out why explorer is loading up so many GDI objects on this one laptop.
When I close Edge, the GDI objects drops down to just over 200. I do have a lot of tabs and browser windows open but when I open the browser task manager (Shift+Esc), it shows only 78 GDI handles while the explorer GDI objects explodes to near 10k.
To try to reduce (or eliminate) the frequency of explorer crashes I've increased the GDI limit to 12,500 in the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\GDIProcessHandleQuota) for the time being while I continue to troubleshoot.
you could create a full dump file from explorer when the GDI object reach 10k . in task manager: details-page, right click the explorer process with the high GDI object cound: "create dump file". perhaps we can see more with this. I still believe some 3rd party library responsible for the leak, but could not find something in your first dump.
there is no need to use a script: when you reduce the limit back to 10.000 explorer will creash and when you enable writing crash dumps this will be done automatically (thats what obviously happened on your first dump file you posted).
Problem is find what leaks the GDI objects: I can't help you with this. When no 3rd party dll is loaded this seems to either be a bug explorer, or the onedrive integration: you could try to disable this with ShellExcview.
This only happens when I open up Edge, and I have lots and lots of tabs across multiple windows at the moment. I'm not sure the relationship between the browser tabs and GDI in explorer.exe... particularly when most of tabs are "sleeping" I'm sure.
I'm ultimately looking for a way to set up an automated alert that will warn me if a process's GDI Object count is approaching the default 10,000 limit. I have a known issue with some software our company uses that causes explorer.exe to have the count build up until it crashes without warning - there's apparently a fix for this in a later version of the software, but we cannot upgrade for reasons beyond my control. My idea is to create a background program/script that will pop up an alert when it sees a GDI count approaching the 10,000 limit. However, the only ways I can seem to view the GDI count is through a GUI either in task manager or Process Explorer - if I could somehow just dump that to a text file automatically I'd be set, but I don't know if that's possible. 041b061a72