WMI Event ID 5858


  • Hi, I've actually never posted before so I hope I'm doing this right, but I'm having a problem that is continually getting worse. My processor has been constantly between 25% and 50% and has been an incredible annoyance, so I started doing some digging and some research and I found the cause of the issue. I looked in my Applications and Services Log and looked for WMI Activity because I knew it was WMIPrvSE.exe that was eating up my processor via taskmgr. Anyway I found a butt load of errors with Event ID 5858. I tried looking online for help and all I could find were a bunch of people with the same problem but no answers. I just got this labtop and I really need it working so please if anyone can help I would Greatly Appreciate it. I would have put the error details below but this forum won't let me, so I'll post them when you get back to me.

    Thanks So Much

    Tuesday, May 14, 2013 4:39 AM


All replies

  • Hi Mikey,

    Firstly, would you please let us know edition of your operating system.

    Meanwhile, as the issue may be related to WMI, we can start troubleshooting by referring to WMI Troubleshooting.

    Hope this helps.

    Jeremy Wu
    TechNet Community Support

    Thursday, May 16, 2013 9:22 AM
  • Hi Mikey - There's a fairly detailed discussion of event ID 5858 in another post at //

    Having a problem in WMIPRVSE can be frustrating because it's difficult to get to the real issue - although there are likely to be clues in those events.

    Some quick background: WMI is an infrastructure used primarily to provide management information or access to management features on your system. The way it works is something makes a call into some class to do some management action. WMI knows what DLL that class is in, and loads it. To reduce startup time and memory use, WMI most often loads the DLL into our own process - the WMIprvse that you mentioned. The DLL is referred to in WMI terms as a "provider", since that code provides either management information or management controls. Not to point fingers, but typically the problem is either some app is calling into a provider a lot, which is why you get a lot of time/memory spent within WMIPRVSE, or the provider is doing something a bit strange.

    The problem is knowing what the provider is, and what the app is. That brings us back to the event log.

    You can figure out what providers are being called by looking in the event log for the events with 5857 which contain the string "provider started".  In those events, the last bit of that event says something like: ProviderPath = %SystemRoot%\system32\wbem\<DLLNAME>.dll. The path will change, but you can do searches online with the dllname to find out what the DLL is used for, where it came from, which may help you make some progress.

    If you are seeing lots of event 5858, you need to read the events themselves. The other article points to a lot of things you can try, but one of the most common issues is some app is making a lot of unnecessary calls into WMI. If you look at the text of the event, you will see the following elements (I use <brackets> to replace real info with more descriptive terms) :

    Id = {<some guid>}; ClientMachine = <machine name  - should be your machine, but if not, it's a remote machine>; User = <some process like NT AUTHORITY\SYSTEM, or an actual user>; ClientProcessId = <this is rarely useful. By the time you read the log, that ID is long gone>; Component = <rarely filled in>; Operation = <IMPORTANT STUFF 1>; ResultCode = <IMPORTANT STUFF 2>; PossibleCause = Unknown:

    The <Important stuff> following the Operation tag is described in the other article, along with what to do with them. If Operation is ExecQuery, there's a problem with the provider (DLL), or with some app calling the provider. Search with the information in ResultCode. If the problem you are having is something wrong within the provider, the error code will indicate a "call cancelled" or "quota violation", which says that the provider is taking a long time to do something. If the ResultCode is most often "not found", then the problem is most often some app that is making unnecessary calls into WMI.  

    What is missing is information on where the call is coming from. I am still looking for a way to describe how to do that without writing code. When I figure that out, I'll publish again.

    I hope this long response provides some help, or at least some pointers to move the ball forward.

    Thursday, August 08, 2013 5:43 PM