0
Not a bug

High CPU usage in Explorer process

SDL 2 weeks ago updated by RaMMicHaeL 4 days ago 4

Firstly, keep up the great work on what is a fantastic product! Something of a modern day Windows PowerToy :-)

I'm frequently seeing high CPU usage in the explorer.exe process, which seems to get worse overtime until I reboot. When I say "high", it's not a large number, so much as a constant underlying activity. The system I'm on is a 6C/12T Xeon and after a few days uptime a single thread in the explorer.exe process uses a constant ~0.3% to ~1.0%. It's not substantial, but it's very noticeable when the system is otherwise idle, and I suspect it's also introducing some lag across the Windows UI, possibly due to certain types of GDI calls which use critical sections.

Taking a look at the thread it seems to be attributable to 7+ TT. I've captured a sample stack trace via Process Explorer and also recorded a more detailed trace via Windows Performance Recorder if that were at all useful. Would you be able to provide any thoughts or advice on how to best troubleshoot this and isolate the underlying cause?

System is Windows 10 v1903 x64 w/ 7+ TT 5.8.


Sample stack trace:

ntoskrnl.exe!KiSwapContext+0x76
ntoskrnl.exe!KiSwapThread+0xbfd
ntoskrnl.exe!KiCommitThreadWait+0x144
ntoskrnl.exe!KeWaitForSingleObject+0x255
ntoskrnl.exe!KiSchedulerApc+0x397
ntoskrnl.exe!KiDeliverApc+0x2e8
ntoskrnl.exe!KiCheckForKernelApcDelivery+0x2b
ntoskrnl.exe!KeLeaveCriticalRegion+0x37
win32kbase.sys!HANDLELOCK::vUnlock+0x12e
win32kbase.sys!hbmSelectBitmap+0x19d
win32kfull.sys!NtGdiSelectBitmap+0x11
ntoskrnl.exe!KiSystemServiceCopyEnd+0x25
win32u.dll!NtGdiSelectBitmap+0x14
gdi32full.dll!SelectObjectImpl+0x1f0
USER32.dll!CreateIconIndirect+0x1c7
comctl32.dll!Common_GetIcon+0x39b
comctl32.dll!CImageList::GetIcon+0x2e
comctl32.dll!ImageList_GetIcon+0x8a
Explorer.EXE!CTrayNotify::_ModifyNotify+0x536
Explorer.EXE!CTrayNotify::_TrayNotifyIcon+0x9c1
Explorer.EXE!TrayUI::HandleCopyData+0x7c
Explorer.EXE!CTray::v_WndProc+0xf8
Explorer.EXE!CImpWndProc::s_WndProc+0x78
USER32.dll!UserCallWinProcCheckWow+0x2bd
USER32.dll!CallWindowProcW+0x8e
comctl32.dll!CallNextSubclassProc+0x89
comctl32.dll!DefSubclassProc+0x77
inject.dll!Init+0x1a7ab
comctl32.dll!CallNextSubclassProc+0x89
comctl32.dll!MasterSubclassProc+0xa2
USER32.dll!UserCallWinProcCheckWow+0x2bd
USER32.dll!DispatchClientMessage+0x9c
USER32.dll!_fnCOPYDATA+0x50
ntdll.dll!KiUserCallbackDispatcherContinue
win32u.dll!NtUserPeekMessage+0x14
USER32.dll!_PeekMessage+0x42
USER32.dll!PeekMessageW+0x149
Explorer.EXE!CTray::_MessageLoop+0x4c
Explorer.EXE!CTray::MainThreadProc+0x4d
shcore.dll!_WrapperThreadProc+0xf5
KERNEL32.DLL!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21

Under review

The stack trace that you posted looks unrelated to the tweaker. You can see inject.dll in there, but that's only because the tweaker hooks some of the explorer windows, so the messages go through it.

I see another thread on my computer which can be contributed to the tweaker, and it looks like this:

That's the mouse hook thread, and it's only running when one of the mouse-related tweaks is enabled (The "Mouse wheel" section on the upper right corner, and several advanced options).

For a start, try to disable the mouse-related options of the tweaker, and see whether you see any change.

+1

Hey there,

Thanks for taking the time to reply!


I've drilled down into the problem further and you're quite right, it looks like the culprit is a different piece of software that's aggressively updating its taskbar icon, resulting in a lot of GDI calls which seem to block Windows Explorer at various points, making the shell sometimes appear quite "laggy". The "inject.dll" belonging to 7+ Taskbar Tweaker incorrectly led me to believe it was at fault. Thanks for your help, I'll investigate further and get the related software vendor involved.

Sorry for the trouble!

-SDL

Great, I'm glad you found and fixed the issue.