Event 5858 from WMI-Activity

Question

Many instances of Event 5858 from WMI-Activity are appearing in the Microsoft-Windows-WMI-Activity/Operational log.
An example of the event message text is "Id = {BA4361BF-423A-0001-1284-43BA3A42CD01}; ClientMachine = SERVER1; User = SERVER\bnf1; ClientProcessId = 928; Component = Unknown; Operation = Start IWbemServices::ExecQuery - root\cimv2 : SELECT * FROM Win32_ComputerSystem;
ResultCode = 0x80041032; PossibleCause = Unknown
Is there a solution or a workaround?
Thanks.

Answer 1

The core problem for this set of issues is that the WMI error event ID 5858 is being generated generically and is not only representing functional error conditions.
Unfortunately, for application/backwards compatibility, we can’t just get rid of it, because people have gone to the effort of parsing the event (more below) to look for the instances where there is useful data.
Event 5858 is generated any time there is an error returned to the WMI client API. Many of these “errors” are behaviors that the client application handles (for example, checking
for something that is not present), so seeing event 5858 does not tell you enough. The user data section of the event has the information to explain if the problem is important, but it must be parsed. That makes this event hard to use for monitoring, so some
notes on that are at the end.
To understand WMI event 5858, the key elements are in userdata, specifically:
ResultCode – this tells you the real reason event is generated, and is the most valuable piece of information. More info is below, but searching TechNet for the ResultCode will
usually give you the information you need.
Operation – the relevant info follows “Start IWbemServices::”, and tells you what WMI was asked to do. This includes run a query, enumerate/create/delete instances, look for
a class, etc. There is a full list here: //msdn.microsoft.com/en-us/library/windows/desktop/gg196568(v=vs.85).aspx
User – it sometimes it helps to know what account was trying to do the Operation, particularly if the ResultCode is 0x80041003 – Access Denied.
ResultCode details: There is a good list of ResultCodes here: //support.microsoft.com/kb/295821.
The ones listed in this thread are:
0x80041032 – Call Cancelled. The client application cancelled the request that was made. That is almost always ignorable as a WMI error. The component or application (SCCM,
or Group Policy) for example) that was calling into WMI cancelled the request, and will likely generate its own event if it is important to do.
0x8004100A – Critical Error. This could be a significant problem, and should be investigated. The WMI infrastructure is not working properly. You can either use WMIDiag (see
this article: //blogs.technet.com/b/askperf/archive/2012/02/03/wmidiag-2-1-is-here.aspx)
or from an elevated command prompt run Winmgmt –VerifyRepository.  
0x80041002 – Not Found. This is usually ignorable by itself. It means that WMI could not find the instance of a class that was requested, which is not unusual.
0x8004100F – Invalid Object. This could be a significant problem and should be investigated. It could be a problem where the WMI provider is badly written, or it could be an
issue within the WMI repository. See Troubleshooting below.
Operation details – This begins with “Start IWbemServices::”, then the actual operation, with parameters you can use to find out more info. Examples from the thread above are:
ExecQuery – run a WMI query. The structure is ExecQuery - <namespace> : <query>. Example is ExecQuery - root\CIMV2 : select * from Win32_OperatingSystem Where ProductType!=2
or ProductType!=3. You can use the PS command get-wmiobject –namespace (insert the namespace) –query “(insert the query portion)”
DeleteInstance – delete a specific instance of a WMI class. Looks like: DeleteInstance - <namespace>: <instance information>. Example is DeleteInstance - Root\Rsop\User\S_1_5_21_1447720405_913420198_1853421413_1156
: RSOP_ExtensionStatus.extensionGuid="{1A6364EB-776B-4120-ADE1-B63A406A76B5}".
CreateInstanceEnum – sets up to enumerate all instances of a class. Structure is CreateInstanceEnum - <namespace> : <classname>.
Troubleshooting:
As noted, some of the issues listed above are important to understand. There are some good topics on WMI Troubleshooting in TechNet, so I won’t try to repeat them. There is
a generally good article here:
technet.microsoft.com/en-us/magazine/2006.09.wmievents.aspx.
The most critical things to check for are repository issues, which you can do either using WMIDiag (see this article:
blogs.technet.com/b/askperf/archive/2012/02/03/wmidiag-2-1-is-here.aspx) or from an
elevated command prompt run Winmgmt –VerifyRepository, and confirm that the repository is in good shape.
Monitoring:
You have to parse event 5858 to get the critical info, so other events are easier to use
for monitoring. The most critical events to watch for relating to WMI are still in the Windows-Application log, not Microsoft-Windows-WMI-Activity/Operational log (where event 5858 is found). All of the most serious errors that will show up with an event 5858
will also have something in the Windows-Application log. Documentation for the most relevant events are listed in multiple topics under this reference:
//technet.microsoft.com/en-us/library/cc727020(v=ws.10).aspx
In summary:
Event 5858 is confusing, generally ignorable, and unfortunately not something we can get rid of easily. It does provide valuable information if you know how to parse it. The
most relevant information is the ResultCode in the UserData section – copy and paste that into a search of TechNet for meaningful information.