Is WMIprvse a real villain?
How often has it occurred that you were working on something and suddenly your computer became slow? You opened task manager to find out the culprit that is hogging your systems CPU cycles. You sorted the processes according to CPU usage and saw WMIprvse.exe happily sitting at the top.
Before putting the blame on WMIprvse.exe have you ever wondered that it can be that some other application contracted the WMIprvse.exe to create havoc on your computer? Here’s how you can find the culprit which is using WMIprvse.exe to eat up your system resources.
Open Event viewer (Control Panel\System and Security\Administrative Tools\Event Viewer) and enable “Show Analytic and Debug Logs”
Navigate to Application and Services Logs -> Microsoft -> Windows -> WMI-Activity
Right Click on WMI-Activity -> Trace and select Properties
Select “Enable Logging”
And now you are all set to trace the path culprit takes.
Let’s see how a typical event looks like and try to understand the various fields in the event
GroupOperationID: is a unique identifier that is used for all events reported for a specific client.
OperationId: indicates the operation sequence.
Operation: This will give you the WMI query issued by the client application. In the above example, CreateInstanceEnum has been issued on the win32_process class.
ClientMachine: Computer name from which the request originated.
User: indicates the account that makes a request to WMI by running a script or through CIM Studio.
ClientProcessId: Process Identifier for the process which issued the WMI query.
NamespaceName: shows the WMI namespace to which the connection is made
(Visit https://msdn.microsoft.com/en-us/library/aa826686(VS.85).aspx for detailed information.)
A quick look up in the task manager for the ClientProcessId will give you the process name against which you might want to take action to bring your computer back to the normal state.
Hope this will help in finding the real villain!!
Varun Singh
MSFT
Comments
Anonymous
May 26, 2009
PingBack from http://asp-net-hosting.simplynetdev.com/is-wmiprvse-a-real-villain/Anonymous
May 26, 2009
Thanks for the tip Varun, but is there a chance to find the real villain in XP too? Usually we use ProcessExplorer and look at the threads wmiprvse is starting but this has one huge disadvantage: it's realtime only.Anonymous
June 10, 2009
What OSes is this tip valid for? When you publish tips like this you should always say what OSes it is valid for. That said, it is very useful, for a few of us anyway. ThanksAnonymous
July 02, 2009
The comment has been removedAnonymous
January 30, 2011
Hi, This worked for me!!! I followed the tutorial, and I found out that DChelper.exe from Asus Direct Console 2.0 was causing this issue now I have 1~10% of CPU Usage! Thanks a lot!Anonymous
February 26, 2011
so i followed all of your steps to the part where i enabled logging, then i tried to run the trace, and an error showed up, which didn't let me run the trace properly. please let me know what to do.Anonymous
March 09, 2011
Thanks, this was pretty darn useful info! It would be nice if they stuck this right in the process monitor. SVCHOST is another one of these proxies... will this work on that too I wonder.... Cheers.Anonymous
March 31, 2011
Thanks for the information. iBooty (an application that is used to boot your jailbroken iPhone) was causing the problem for me.Anonymous
April 05, 2011
How would I do this in XP? Thanks.Anonymous
June 06, 2012
Hi, Actually I've been looking for a way to bring down wmiprvsrv.exe load for a long time - installed different anti viruses scan, loggers etc. It is your tutorial which helped to pin point a real CPU killer - application from Cisco Pure Networks. Since I am not using it anymore I just removed it (first I stopped its process and it helped) and that just SOLVED THE PROBLEM. Thank you very much (even though you probably will not read the comment, your article is like 3 years old already). :-DAnonymous
December 03, 2012
This was of great help, problem was resolved swiftly. Thanks a lot! (Offending application was sidebar.exe, specifically a buggy gadget)Anonymous
May 06, 2013
The comment has been removedAnonymous
May 16, 2013
cimwin32.dll is the culprit on mine too. I'm running Windows 7. It seems to be in some kind of endless loop. I haven't found any useful or directional answers on Google either for cimwin32.dll. There are 2 versions running - one that has SYSTEM as the user name and another that has NETWORK SERVICE as the user name. The NETWORK SERVICE one is the problem. An interesting note however - my computer at work also runs Windows 7. WMIprvse.exe isn't always running on that one. That computer also has different Microsoft updates.Anonymous
May 27, 2013
The "Show Analytic and Debug Logs" is grayed out! Help?Anonymous
July 25, 2013
What if my ClientProcessId = 0? Which it does. "GroupOperationId = 360; OperationId = 18424; Operation = Start IWbemServices::ExecQuery - select * from Win32_Process; ClientMachine = Local; User = .SYSTEM; ClientProcessId = 0; NamespaceName = .rootCIMV2" Then what does that mean?Anonymous
July 28, 2013
My report is completely different to the rest of yours... "ProviderInfo for GroupOperationId = 118; Operation = Provider::CreateInstanceEnum - CIMWin32 : Win32_Process; HostID = 5804; ProviderName = CIMWin32; ProviderGuid = {d63a5850-8f16-11cf-9f47-00aa00bf345c}; Path = %systemroot%system32wbemcimwin32.dll" What does this mean, and how can i sort this annoying problem out?Anonymous
August 09, 2013
cimwin32.dll is the Provider that services many of the Win32_* classes in the root/cimv2 namespace. That by itself is actually not the whole story. The issue really depends on who is using that provider (for example, if an application is enumerating Win32_Process repeatedly, this would cause wmiprvse.exe to load cimwin32.dll to carry out the request.Anonymous
September 22, 2013
Based on another thread I've seen I've used the Windows Services utility (Task Manager-Services-Services-Standard) to stop the Windows Management Instrumentation service, which in turn kills Windows Security Center. Is there a bug with Security Center?Anonymous
October 15, 2013
I traced it to this. It looks like a Windows process. clientProcessId = 1360 NamespaceName = .RootMicrosoftHomenetAnonymous
October 16, 2013
The comment has been removedAnonymous
October 19, 2013
Like RP said stopping Windows Management Instrumentation service always takes care of this for me. Is there a fix for that?Anonymous
October 23, 2013
Well I didn't stop WMI because it stops security center, but I did pause and unpause it. Seemed like the problem disappeared.Anonymous
November 04, 2013
I didn't research the problem right away. I just did a System Restore and the problem went away. Hope it does not come back.Anonymous
November 16, 2013
The comment has been removedAnonymous
November 26, 2013
What if the clientprocessid is 0?Anonymous
November 29, 2013
I was reading the comments and realized I was having the same problem as some here. I figured it out. To get to the part where it tells you the group operation ID and whatnot, you have to close (I said yes to the little window that popped up after I pressed enable, not sure if it helped or not) abd then open WMI-activity. Hope I helped.Anonymous
December 09, 2013
Logging is powerful stuff; I got a nice log. ClientProcessid = 0. so I'm stuckAnonymous
December 09, 2013
The comment has been removedAnonymous
December 29, 2013
Don Jon Online 2013 http://j.mp/19vjxQXAnonymous
December 29, 2013
Ping Back OK........Thank's http://j.mp/19vCZgEAnonymous
December 31, 2013
Followed the instructions on Vista Home Premium. TM shows it running but log shows nothing, ie, no events--blankAnonymous
February 25, 2014
I agree with what Tyson said - pausing and unpausing it seems to handle the problem. I just made a script to do this and set it to run a few minutes after startup. net pause Winmgmt net continue WinmgmtAnonymous
July 02, 2014
Thanks, found the real culprit service & made (rather saved) my day :)Anonymous
October 03, 2014
This is all well and good for people that have the smarts to follow all the convoluted instructions here, but what about the people Who don't.. Is there something that I can have my non techie father do who lives 5 hours away that doesn't take a rocket scientistAnonymous
October 24, 2014
Amazing, helpful post! I had spent hours trying to find out what was eating CPU on one of my servers and found the rogue service in minutes after following these instructions. They couldn't be more simple to follow either..Anonymous
February 15, 2015
Can anyone make this into a small tool that just points out the PID (or even better... process/service name) right away? I tried folowing the guide, but clearly i'm doing something wrong because ive ended 3 processes and/or uninstalled the software they relied on and the problem still persists. Clearly i'm following the wrong process or something... Anyone know where i could go for someone creating a tool for this?Anonymous
February 26, 2015
For me the real villain here was 'Comodo System Utilities' - however, this does beg the question of what is wrong with the design of Windows, and why these issues do not exist in the Unix-type operating systems such as OSX, Linux & BSD (which are vastly superior to Windows, much easier to troubleshoot, more stable & reliable, and much more sensible in terms of their fundamental system architecture)Anonymous
April 02, 2015
So nice to see someone actually explain things rather than just saying "go to the clientprocessid". Well done Varun!Anonymous
April 26, 2015
The comment has been removedAnonymous
May 14, 2015
So WMI can be abused by other apps, Villain is still WMI, disable WMI. Could have been a shorter article.Anonymous
May 16, 2015
restarting the wmi service is only a temporary fix. Each time I restart my computer problem keeps coming back.Anonymous
July 04, 2015
thank you very much for changing my scope of conception about this process and its origins.Anonymous
July 04, 2015
Good info! Thanks, Varun and the Contributors!Anonymous
October 26, 2015
Thank you for this post, it's been a great help. Had a CPU that was fluctuating from 10% to 100% every 5 seconds on my domain controller. Managed to track it down to software another admin had installed called 'Netwrix Account Lockout Examiner' that was running in the background.Anonymous
March 11, 2016
The comment has been removed