Shell Resource Leaks

Found a bug in "Everything"? report it here
Post Reply
dolos
Posts: 8
Joined: Wed Jul 17, 2019 3:39 pm

Shell Resource Leaks

Post by dolos »

Not entirely sure what's going on here, but when using the context menu on files, each time Everything.exe seems to span at least one new thread, and that one does not go away. Also, there is a bunch of new handles each time that won't go away either. And I think RuntimeBrowser.exe leaks a few resources too.

I saw a few hundred threads in ProcessHacker, but when I tried to get a stack trace, but Everything.exe just died before PH was done downloading symbols. Didn't yet try to attach a real debugger.

This will eventually lead to some adverse effects:
  • System might run out of handles (unlikely, but not impossible)
  • When in thumbnail mode, it may lock the thumbcache system files (via thumbcache.dll via shell) which means all programs incl first and foremost E.g. Explorer will not fail to generate thumbnails. And Everything itself will also fail to generate thumbnails
  • Spurious crashes of Everything.exe (the userland not the service)
  • Everything.exe may hang when closing an Everything window
  • Everything.exe may hang-on-exit (related to above, I'd guess)
Not sure if the thumbnail stuff is really related, but I only observed it only when using Everything and when using it a lot and clicking around a lot, in thumbnail mode. Also, killing Everything.exe and the bloated RuntimeBroker.exe will restore the thumbnailing functionality for all other apps incl Everything after it gets restarted.

I do not see any resource leaks from other processes displaying the shell file context menu, nor from processes using the thumbnail shell service. This to me suggests the problem lies with Everything and not any of the (few) shell context/thumbnail/WIC handlers I have installed.

Magic Eight Ball points to a missing ->Release() somewhere, but it's just a Magic Eight Ball, what does it know...

Latest Win10 Pro (running a HiDPI RDC session)
Latest Everything 1.4.935
therube
Posts: 4580
Joined: Thu Sep 03, 2009 6:48 pm

Re: Shell Resource Leaks

Post by therube »

(You say, RuntimeBrowser.exe in the first paragraph. Is that in error?)


reference: https://www.ghacks.net/2017/04/06/what- ... -cpu-load/
I saw a few hundred threads in ProcessHacker
So under Threads, these would be "Everything.exe+0x148210" that would be accumulating?
No, it would be under Handles, with a Thread therein named Everything.exe.
Or is it Mutants that we're looking for?
(I'm just winging it, as you might gather.)


(Wonder if this might not only occur on Win8+, where RuntimeBroker exists?)



(Similar sounding, in MPUI, viewtopic.php?p=27269#p27269.)
void
Developer
Posts: 15096
Joined: Fri Oct 16, 2009 11:31 pm

Re: Shell Resource Leaks

Post by void »

Thanks for the bug report.

Could you please send me a list of the shell context menu extensions you are using to support@voidtools.com (or post them here)
I'll need to reproduce the issue to have any luck in finding the problem.

Some debug output might be useful (a shell extension could be throwing an exception causing the leak in Everything):
The debug output will also show shell extension verbs:
  • In Everything, type in the following search and press ENTER:
    /debug
  • What is shown in the debug console when you right click a file or folder?
To close the debug console:
  • In Everything, type in the following search and press ENTER:
    /debug
One more question, does the leak occur when you click a single file, or only occur when you click multiple files? -there's two paths of execution when you click a single file or multiple files.

Hope I can help.
NotNull
Posts: 5167
Joined: Wed May 24, 2017 9:22 pm

Re: Shell Resource Leaks

Post by NotNull »

dolos wrote: Wed Jul 17, 2019 4:56 pm I do not see any resource leaks from other processes displaying the shell file context menu,
To create a level playing field for comparing (after you send in the debug logs of course):
  • Are you running 32-bit Everything?
    Install the 64-bit version.
    32-bit and 64-bit programs have a different context menu (but might have the same/similar entries).
  • Are you running Everything as administrator?
    Enable Everything Service and uncheck Run as administrator (both can be found under Menu:Tools > Options)
    Different user accounts might have different context menu's.
void wrote: Thu Jul 18, 2019 1:50 am does the leak occur when you click a single file, or only occur when you click multiple files?
And does it occur with specific file types or any filetype?
dolos
Posts: 8
Joined: Wed Jul 17, 2019 3:39 pm

Re: Shell Resource Leaks

Post by dolos »

void wrote: Thu Jul 18, 2019 1:50 am Thanks for the bug report.

Could you please send me a list of the shell context menu extensions you are using to support@voidtools.com (or post them here)
I'll need to reproduce the issue to have any luck in finding the problem.
Other than what the default Microsoft ones that ship with Windows, there is Dropbox, 7-zip and Notepad++ and one of my own.
I grepped over HKCR for ContextMenuHandlers to see if anything else snuck in but no.

I disabled all context menu handler extensions for now (by being lazy and changing their GUIDs in regedit, except for dropbox which I actually uninstalled :p) and confirmed they are not loaded anymore for my further tests.

There is are few regular shell verbs too, like MediaInfo, VS code and such, but they are plain command verbs not shell extensions.

void wrote: Thu Jul 18, 2019 1:50 am Some debug output might be useful (a shell extension could be throwing an exception causing the leak in Everything):
The debug output will also show shell extension verbs:
  • In Everything, type in the following search and press ENTER:
    /debug
  • What is shown in the debug console when you right click a file or folder?

    To close the debug console:
    • In Everything, type in the following search and press ENTER:
      /debug
Nifty, with colors even.
OK, here are some minimal STR, with all third party context menu handlers disabled:
  • Search a file in "details" mode (no /debug console open)
  • Repeatedly bring up and dismiss the context menu.
  • Watch thread count (e.g. in ProcessHacker or TaskMan)
  • --> each time the context menu is shown (for the same file) the thread count goes up by at least one.
  • Wait a couple of minutes to see if some of the threads vanish again (e.g. they could be cached, or been waiting on some event, IPC/RPC, whatever).
  • --> After 10 minutes or so some threads indeed vanished again, like a thread in dlnashellext.dll (which seems to be part of the Windows built-in Play To Device context handler)
  • --> The thread count remains high, and if I haven't miscounted, has one additional thread per context menu activation. 10 clicks = 10 threads
  • Repeat above, but this time select an action such as "open" instead of dismissing the menu.
  • --> This also leaks threads
The one constant seems to be that the new threads have a start address that according to MS Symbol servers resolves to "WorkFoldersShell.dll!ThreadFunction_MenuAction", which further points to the context menu being the culprit.

Image

I then checked the .947 nightly. Same behavior, same problem.

As for /debug output:

Code: Select all

ParseDisplayName G:\test.jpg
parse display name G:\test.jpg
parse display name OK
bind to parent
get menu 1 1
got menu 1878452416
got menu 1
menu type 3
QueryContextMenu...
QueryContextMenu 000000b0
track menu 0000000017750c45
WM_INITMENUPOP 0000000017750c45 0000000000000000
menu count 30
wid 4: 167 (000000a6)
00000000
VERB open
wid 4: 168 (000000a7)
00000000
VERB 3D Edit
wid 5: 169 (000000a8)
00000000
VERB MediaInfo
wid 6: 170 (000000a9)
00000000
VERB setdesktopwallpaper
wid 7: 171 (000000aa)
00000000
VERB edit
wid 8: 172 (000000ab)
00000000
VERB print
wid 10: 164 (000000a3)
00000000
VERB rotate90
wid 11: 165 (000000a4)
00000000
VERB rotate270
menu item info fail 0
wid 14: 98 (00000061)
80070057
wid 15: 97 (00000060)
00000000
VERB Windows.ModernShare
menu item info fail 0
wid 17: 28 (0000001b)
00000000
VERB PreviousVersions
wid 18: 32765 (00007ffc)
80070057
menu item info fail 0
wid 20: 32764 (00007ffb)
80070057
wid 21: 25 (00000018)
00000000
VERB cut
wid 22: 26 (00000019)
00000000
VERB copy
menu item info fail 0
wid 24: 17 (00000010)
00000000
VERB link
wid 25: 18 (00000011)
00000000
VERB delete
wid 26: 19 (00000012)
00000000
VERB rename
wid 27: 32766 (00007ffd)
80070057
wid 28: 20 (00000013)
00000000
VERB properties
rem dbl sep
WM_SELECT ffff0000 00000000 17750c45
idCommand 0
<... rinse and repeat for next click >
Except for the changing menu handle addresses, the logs look the same for each click as I clicked the same file, and there is not other information logged.

void wrote: Thu Jul 18, 2019 1:50 am One more question, does the leak occur when you click a single file, or only occur when you click multiple files? -there's two paths of execution when you click a single file or multiple files.
I performed my tests above by clicking repeatedly on a single file.

NotNull wrote: Thu Jul 18, 2019 10:01 am
  • Are you running 32-bit Everything?
    Install the 64-bit version.
    32-bit and 64-bit programs have a different context menu (but might have the same/similar entries).
  • Are you running Everything as administrator?
    Enable Everything Service and uncheck Run as administrator (both can be found under Menu:Tools > Options)
    Different user accounts might have different context menu's.
void wrote: Thu Jul 18, 2019 1:50 am does the leak occur when you click a single file, or only occur when you click multiple files?
And does it occur with specific file types or any filetype?
Should have mentioned I am running 64-bit Everything, so I am seeing the "native" context menu, not the WoW one.
Everything is running as a service. The UI process is running under my user account, the service process under root, all as expected.

About what file types, not sure. I am guessing you allude to different types potentially having different sets of context menu handlers, and only a particular one registered with a particular (set of) type(s) might be affected?
Before, I mostly clicked pictures. Now I tested repeatedly clicking a jpeg, a txt file, a folder and a file without extension. There is no difference, the thread leaks happen either way.
NotNull
Posts: 5167
Joined: Wed May 24, 2017 9:22 pm

Re: Shell Resource Leaks

Post by NotNull »

dolos wrote: Sat Jul 20, 2019 11:09 am About what file types, not sure. I am guessing you allude to different types potentially having different sets of context menu handlers, and only a particular one registered with a particular (set of) type(s) might be affected?
Exactly.

As I was curious, I followed your steps to reproduce the issue.

Opened the context menu for about 50 files (twice per file)
Before: 14 hreads
After: 14 threads
All according to Process Explorer.

Everything 1.4.1.947 x64 @ Win 10 1803;
The only dynamic verbs are coming from 7-Zip (beside the few out-of-the-box ones I left enabled)


Before
2019-07-20 16_36_21-Everything.png
2019-07-20 16_36_21-Everything.png (25.95 KiB) Viewed 20894 times

After
2019-07-20 16_41_04-Everything.exe_2620 Properties.png
2019-07-20 16_41_04-Everything.exe_2620 Properties.png (26.5 KiB) Viewed 20894 times
void
Developer
Posts: 15096
Joined: Fri Oct 16, 2009 11:31 pm

Re: Shell Resource Leaks

Post by void »

Thanks for the detailed reply.

I'm able to reproduce the issue on stock Windows 10 x64 1903.

The leak occurs when calling IContextMenu::QueryContextMenu()
Everything is destroying the menu passed to this call and the IContextMenu interface is released (IContextMenu::Release returns 0). However, the leak still occurs.

I also see the same behavior in Windows Explorer. Can you check if the issue occurs for you in Windows Explorer?

I've tested Windows 10 x64 1703 and 1803 and the issue does not appear present, the thread is created and closes a couple of seconds after the context menu is closed.
void
Developer
Posts: 15096
Joined: Fri Oct 16, 2009 11:31 pm

Re: Shell Resource Leaks

Post by void »

I've also double checked my IDataObject is released and it is.

For now, to avoid the leak, you can access most context menu items from the main File Menu.
dolos
Posts: 8
Joined: Wed Jul 17, 2019 3:39 pm

Re: Shell Resource Leaks

Post by dolos »

Damn, you're right.
I am seeing this in Windows Explorer. too, in Win10 Pro x64 1903.
I am pretty sure I did not see it in earlier versions of Windows (cannot test right now).

Looks like this might be a new full-blown Windows bug introduced with the May update.
Bruce Dawson
Posts: 2
Joined: Tue Dec 29, 2020 12:51 am

Re: Shell Resource Leaks

Post by Bruce Dawson »

Did you find anymore about this bug? I think we are hitting the same issue in Chrome, except there it manifests as a crash. That is, we shut down Chrome and this thread is still running, which leads to sadness because WorkfoldersShell.dll is now unloaded.

I'd be interested to hear if this was reported to Microsoft, if you can still reproduce it on more recent versions of Windows, etc. I have not been able to reproduce the crash variant of this bug.
NotNull
Posts: 5167
Joined: Wed May 24, 2017 9:22 pm

Re: Shell Resource Leaks

Post by NotNull »

What version of Everything are you running?

And what version of Windows? As that is the deciding factor here ...
Bruce Dawson
Posts: 2
Joined: Tue Dec 29, 2020 12:51 am

Re: Shell Resource Leaks

Post by Bruce Dawson »

I haven't seen the crash issue myself, but I am seeing it in crash reports from Chrome users. It looks like it happens on the very latest versions of Windows 10 (19041 and 19042), but all I'm sure of is that the crashes happen with the 10.0.19041.329 version of WorkfoldersShell.dll.

I'm engaged with a Microsoft developer who seems motivated to get the bug. I am able to reproduce the thread leak in explorer in Windows 10.0.19041 so thank you for mentioning that. I think that might help drive a fix.
Post Reply