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.
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.