2

I'm facing a peculiar issue that I can't fix. I discovered recently that my Win 8.1 Update 1 (with all updates through WSUS offline) starts eating all the CPU when opening "the device and printers" window.

There's a 5-10' delay until the devices appear however the CPU keeps on spinning even after the icons are displayed for about 5-10' more minutes.

Xperf file (thanks to @magicandre1981 for instructions) is posted on Dropbox - 24MB zip unpacked to 145MB.

Looking through Sysinternals process explorer it seems the problem is caused by MultiByteToUnicodeN call (unfortunately I cannot post an image):

ntdll.dl!RtlMultiByteToUnicodeN+0x1cf0 ntdll.dl!RtlMultiByteToUnicodeN+0x1cf0 ntdll.dl!RtlMultiByteToUnicodeN+0x1cf0 ntdll.dl!RtlMultiByteToUnicodeN+0x1cf0 ntdll.dl!RtlMultiByteToUnicodeN+0x1cf0 SHCORE.dll!GetScaleFactorForDevice+0x1d4 FunDisc.dll!DllCanUnloadNow+0x2e8 SHCORE.dll!GetScaleFactorForDevice+0x1d4 SHCORE.dll!GetScaleFactorForDevice+0x1d4 windows.immersiveshell.serviceprovider.dll! SHCORE.dll!GetScaleFactorForDevice+0x1d4 SHCORE.dll!GetScaleFactorForDevice+0x1d4 SHCORE.dll!GetScaleFactorForDevice+0x1d4 SHCORE.dll!GetScaleFactorForDevice+0x1d4 Explorer.EXE

Any ideas how to fix this? Either I wait 20' or so or have to kill the explorer task. I've tried reinstalling all the devices to no avail; for some reason rendering this window causes the unicode translation to eat all the CPU.

Update with symbols

Based on the comment received, I've installed the retail symbols for windows 8.1 and pointed process explorer (as explained in this post to it however the output looks pretty much the same. I've looked at the stack for a thread and it seems it is spending most of its time in the synchronizing on one object: ntoskrnl.exe!KeSynchronizeExecution+0x2246 ntoskrnl.exe!KeRemoveQueueEx+0x108e ntoskrnl.exe!KeRemoveQueueEx+0xae9 ntoskrnl.exe!KeWaitForSingleObject+0x22a ntoskrnl.exe!KeSetBasePriorityThread+0x4ec ntoskrnl.exe!KeRemoveQueueEx+0x281d ntoskrnl.exe!KiCheckForKernelApcDelivery+0x23 ntoskrnl.exe!SeQuerySessionIdToken+0x1b99 ntoskrnl.exe!SeQuerySessionIdToken+0x15f9 ntoskrnl.exe!SeQuerySessionIdToken+0x1440 ntoskrnl.exe!FsRtlAllocateExtraCreateParameter+0x744e ntoskrnl.exe!FsRtlAllocateExtraCreateParameter+0x52c4 ntoskrnl.exe!FsRtlAllocateExtraCreateParameter+0x13c8 ntoskrnl.exe!FsRtlAllocateExtraCreateParameter+0x10da ntoskrnl.exe!IoDeleteAllDependencyRelations+0x14d0 ntoskrnl.exe!FsRtlAllocateExtraCreateParameter+0xa96 ntoskrnl.exe!FsRtlAllocateExtraCreateParameter+0x898 ntoskrnl.exe!ObReferenceObjectByHandleWithTag+0xe92 ntoskrnl.exe!NtDeviceIoControlFile+0x56 ntoskrnl.exe!setjmpex+0x34b3 ntdll.dll!NtDeviceIoControlFile+0xa KERNELBASE.dll!GetModuleHandleExA+0xb6 KERNEL32.DLL!DeviceIoControl+0x80 cfgmgr32.dll!SwMemFree+0x6a7 KERNELBASE.dll!SetKernelObjectSecurity+0xc1 ntdll.dll!RtlAcquireSRWLockExclusive+0x31e ntdll.dll!RtlMultiByteToUnicodeN+0x20a3 KERNEL32.DLL!BaseThreadInitThunk+0xd ntdll.dll!RtlUserThreadStart+0x1d

Here's another stack from one of the initiating threads (SHCORE.dll!GetScaleFactorForDevice): ntoskrnl.exe!KeSynchronizeExecution+0x2246 ntoskrnl.exe!KeRemoveQueueEx+0x108e ntoskrnl.exe!KeRemoveQueueEx+0xae9 ntoskrnl.exe!KeWaitForSingleObject+0x22a ntoskrnl.exe!KeSetBasePriorityThread+0x4ec ntoskrnl.exe!KeRemoveQueueEx+0x281d ntoskrnl.exe!KiCheckForKernelApcDelivery+0x23 win32k.sys+0x12aaea win32k.sys+0x6d10d win32k.sys+0xca699 win32k.sys+0x35a9f win32k.sys+0x2a514 win32k.sys+0x138e28 win32k.sys+0x19fa8 win32k.sys+0x4921e ntoskrnl.exe!setjmpex+0x34b3 USER32.dll!WindowFromPhysicalPoint+0x1a USER32.dll!CallWindowProcW+0x2bf USER32.dll!SendMessageW+0x111 UxTheme.dll!DrawThemeParentBackgroundEx+0x18f Comctl32.dll!ImageList_GetIconSize+0xee3 Comctl32.dll!ImageList_GetIconSize+0x1107 Comctl32.dll!DrawScrollBar+0x12bf USER32.dll!DispatchMessageW+0x154 USER32.dll!CallWindowProcW+0x132 Comctl32.dll!DefSubclassProc+0xb2 Comctl32.dll!DefSubclassProc+0x77 explorerframe.dll!Ordinal111+0x655d Comctl32.dll!DPA_GetPtr+0x282 Comctl32.dll!DPA_GetPtr+0x152 USER32.dll!DispatchMessageW+0x154 USER32.dll!OffsetRect+0x172 USER32.dll!OffsetRect+0x22d ntdll.dll!KiUserCallbackDispatcher+0x1f USER32.dll!WindowFromPhysicalPoint+0x1a USER32.dll!CallWindowProcW+0x2bf USER32.dll!SendMessageW+0x111 UxTheme.dll!DrawThemeParentBackgroundEx+0x1a6 explorerframe.dll!Ordinal111+0xabef explorerframe.dll!Ordinal111+0x6ae5 USER32.dll!DispatchMessageW+0x154 USER32.dll!OffsetRect+0x172 USER32.dll!OffsetRect+0x22d ntdll.dll!KiUserCallbackDispatcher+0x1f USER32.dll!WindowFromPhysicalPoint+0x1a USER32.dll!CallWindowProcW+0x2bf USER32.dll!SendMessageW+0x111 UxTheme.dll!DrawThemeParentBackgroundEx+0x1a6 explorerframe.dll!Ordinal111+0xaa52 Comctl32.dll!DPA_GetPtr+0x282 Comctl32.dll!DPA_GetPtr+0x152 USER32.dll!GetWindowLongPtrA+0x265 USER32.dll!OffsetRect+0x172 USER32.dll!OffsetRect+0x22d ntdll.dll!KiUserCallbackDispatcher+0x1f USER32.dll!SendMessageW+0x1aa USER32.dll!SendMessageW+0x1bc explorerframe.dll!Ordinal111+0x546e explorerframe.dll!Ordinal111+0x10568 explorerframe.dll!Ordinal111+0x11d50 explorerframe.dll!Ordinal111+0x11d00 explorerframe.dll!Ordinal111+0xeee3 SHELL32.dll!SHGetKnownFolderPathWorker+0x84c SHELL32.dll!SHGetKnownFolderPathWorker+0xa23 SHCORE.dll!GetScaleFactorForDevice+0x333 KERNEL32.DLL!BaseThreadInitThunk+0xd ntdll.dll!RtlUserThreadStart+0x1d

Note it took 30' or so this time around - had time to install the symbols, read the posts, do some diagnostics and post back and still have the CPU jacked up..

Second Update for symbols

Thanks to @kinokijuf, I have used the Windows Defender Debug.dll and have more accurate info. The Threads now look as follows:

ntdll.dll!TppWorkerThread ntdll.dll!TppWorkerThread ntdll.dll!TppWorkerThread ntdll.dll!TppWorkerThread ntdll.dll!TppWorkerThread SHCORE.dll!Microsoft::WRL::FtmBase::MarshalInterface+0x1c SHCORE.dll!Microsoft::WRL::FtmBase::MarshalInterface+0x1c FunDisc.dll!CNotificationQUeue::ThreadProc SHCORE.dll!Microsoft::WRL::FtmBase::MarshalInterface+0x1c windows.immersiveshell.serviceprovicer.dll!CImmersiveShellController::s_ImmersiveShellComponentsThreadProc Explorer.EXE!wWinMainCRTStartup

While the top level threads still show thread/lock contention ?:

ntoskrnl.exe!KiSwapContext+0x76 ntoskrnl.exe!KiSwapThread+0x14e ntoskrnl.exe!KiCommitThreadWait+0x129 ntoskrnl.exe!KeWaitForSingleObject+0x22a ntoskrnl.exe!KiSchedulerApc+0x74 ntoskrnl.exe!KiDeliverApc+0x1fd ntoskrnl.exe!KiSwapThread+0x2da ntoskrnl.exe!KiCommitThreadWait+0x129 ntoskrnl.exe!KeRemoveQueueEx+0x27b ntoskrnl.exe!IoRemoveIoCompletion+0x8a ntoskrnl.exe!NtWaitForWorkViaWorkerFactory+0x30a ntoskrnl.exe!KiSystemServiceCopyEnd+0x13 ntdll.dll!NtWaitForWorkViaWorkerFactory+0xa ntdll.dll!TppWorkerThread+0x286 KERNEL32.DLL!BaseThreadInitThunk+0xd ntdll.dll!RtlUserThreadStart+0x1d

Thanks,

13
  • Do you have symbols loaded for everything? Cause to me it seems you don’t
    – kinokijuf
    Nov 28, 2014 at 23:07
  • How can I check what symbols are loaded or what are the ones that are missing? Sorry if the question doesn't make sense - I'm not familiar with Windows internals...
    – HerleifC
    Nov 28, 2014 at 23:34
  • Nevermind, figured out what you meant. I've installed the retail symbols for windows 8.1 and pointed process explorer (as explained in this post to it however the output looks pretty much the same.
    – HerleifC
    Nov 28, 2014 at 23:54
  • capture a xperf trace of the cpu usage and share the trace: pastebin.com/pgE11HRD Nov 29, 2014 at 8:21
  • You don’t have symbols. A correct stack trace would not show functions like Ordinal111.
    – kinokijuf
    Nov 29, 2014 at 11:17

1 Answer 1

1

ok, the CPU usage comes from reading a lot of registry keys from MACHINE\SOFTWARE\Classes\DeviceDisplayObject\InterfaceClass\{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}\DeviceDisplayStatus (over 4000 calls).

enter image description here

I also see a lot of calls to MACHINE\System\ControlSet001\Control\DeviceClasses\{53f5630d-b6bf-11d0-94f2-00a0c91efb8b} where I see over 5700 HarddiskVolumeSnapshot ( like REGISTRY\MACHINE\System\ControlSet001\Control\DeviceClasses\{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}\##?#STORAGE#VolumeSnapshot#HarddiskVolumeSnapshot5753#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}\#\Properties).

All those calls make Explorer so slow. Try to figure out why you have so many Snaphots and reduce the amount to make Explorer faster.

1
  • Any idea though what causes these calls? The snapshots are caused by backups - I can remove them but they seem cheap. As for the {53f..} that Interface class seems to be related to USB devices however I'm unclear why this huge number of calls (or retries) especially as the entry does not exist in the registry... Forgot to say thanks for your patience and time so far!
    – HerleifC
    Nov 30, 2014 at 18:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.