# ntdll.dll module causing CPU spikes



## shadownai31 (Jun 5, 2011)

I have recently been having a problem where my cpu usage spikes anywhere from 25-50% every 10 seconds due to the WMIPrvSE.exe service. I tracked it using process explorer and it is obviously the problem in question. The red is tracking the WMIPrvSE.exe process.









I followed the tutorial found here How to get the cause of high CPU usage caused by apps? - MSFN Forum
to try and figure out what process within this WMIPrvSE.exe is causing the spikes. It appears that it is an ntdll.dll issue but I have no clue about how to remedy this. 

The dump file from using xperf can be found here:latency zip

Using process explorer I found that the Thread ID is 3508 and starts at address: ntdll.dll!RtlDosSearchPath_Ustr+0x69a

The entire stack for the thread looks like this:

ntoskrnl.exe!memset+0x64a
ntoskrnl.exe!KeWaitForMultipleObjects+0xd52
ntoskrnl.exe!KeWaitForSingleObject+0x19f
ntoskrnl.exe!__misaligned_access+0xba4
ntoskrnl.exe!__misaligned_access+0x1821
ntoskrnl.exe!KeWaitForMultipleObjects+0xf5d
ntoskrnl.exe!KeRemoveQueueEx+0x323
ntoskrnl.exe!ExQueryAttributeInformation+0x189f
ntoskrnl.exe!KeDetachProcess+0x4d2
ntoskrnl.exe!KeSynchronizeExecution+0x3a43
ntdll.dll!ZwWaitForWorkViaWorkerFactory+0xa
wow64.dll!Wow64EmulateAtlThunk+0x1c993
wow64.dll!Wow64SystemServiceEx+0xd7
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x2d
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!RtlIsDosDeviceName_U+0x24c87
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!NtWaitForWorkViaWorkerFactory+0x12
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36

Someone's expertise would be greatly appreciated.

Thanks


----------



## cluberti (Aug 26, 2010)

So the question is, what is calling WMI to scan the machine? The ntdll binary is just an API binary, and "does what it's told", so to speak. Given the binary causing the CPU work is wmiprvse (WMI provider engine), some process on the machine is calling into WMI to get information (which spawns a WMI provider to do the work). In looking at the xperf trace, it appears there could be a few culprits, but xperf is not the best tool for process parent tracing if you don't enable stackwalking of that data in the trace (which you didn't). It would be easier at this point to run Process Monitor to track back the process PID of the wmiprvse.exe that consumes the CPU to it's parent - it's *probably* a service, and I wouldn't be surprised if it ultimately walks you back to the HP ProtectTools on the machine (I do see hpqwmiex.exe running on this box), but it's hard to say with an xperf.


----------



## shadownai31 (Jun 5, 2011)

Thanks for the advice. I used process monitor to trace it back to the parent thread (628) and found that it is associated with the DCOM Launcher. Unfortunately this had three different services associated with it: Power, PlugPlay and DCOM Service Process Launcher. Now I'm hunting the mighty internets for what might be causing one of those to constantly call the WMIPrvSE.exe and so far I've no luck.


----------



## cluberti (Aug 26, 2010)

DCOM is just a service for handling COM requests - again, it doesn't really "do anything" on it's own. It means a process is calling into COM and starting WMI by making WMI requests. At this point, you probably need to do trial and error - stop 50% of the non-Microsoft things on the machine and test, and if that doesn't work, stop the other 50% - rinse/repeat until you figure out what's causing it. There are other ways, of course (mostly involving debugging) that will probably be accurate, but will take far longer to walk through (speaking from experience, especially with WMI).


----------

