WMI Service Log Files

  • Article

In operating systems earlier than Windows Vista, the WMI Service maintains text log files. Starting with Windows Vista, these files no longer exist in the operating system. For more information, see WMI Log Files and Logging WMI Activity.

  • Wbemcore.log
  • Wbemess.log
  • Mofcomp.log
  • Wmiadap.log
  • Wbemprox.log
  • Framework.log
  • Winmgmt.log
  • Related topics

Wbemcore.log

The Wbemcore.log file contains trace messages generated by the WMI service. For example, it records logon attempts as well as capturing why WMI failed to instantiate a class for a provider.

The following table lists some common messages that can occur and offers possible causes and solutions.

Message Description
DCOM connection from client name at authentication level %s, Authnsvc = %d, Authzsvc = %d, Capabilities = %d You must have the logging level set to verbose to receive this log message.

This message indicates which credentials and RPC values were used to connect to WMI. This can be useful when Wbemprox.log contains a connection failure message that was caused by bad credentials.
Error wmi hresult occurred executing queued request This log entry is followed by additional details that provide specific trace information for the related WMI HRESULT.
Failed to CoGetClassObject for provider <provider name> error code 0x<COM error number> (<a short explanation>) There are many reasons why WMI may not be able to instantiate the class. The short explanation appended to the message provides information to help identify the error.

This message is also logged in the Windows Event log and contains more information that may be useful.

 

Wbemess.log

The Wbemess.log file contains all warning and error messages related to the WMI event subsystem. Those errors that require administrator attention are also logged in the Windows Event log. Warning messages are only logged in the Wbemess.log file when the logging level has been set to verbose.

The following table lists some common problems that can occur and offers possible causes and solutions.

Message Description
Skipping provider <provider name> invalid registration query <query>. The query cannot be parsed.
Consumer provider <provider name> does not support <interface name> interface. This warning message is only logged when the logging level has been set to verbose.
Attempting to register for events (<query>) from an incompletely registered provider <provider name>. A provider registration error occurred or one of the event registration pieces is missing. Ensure that all event registration components are in place.

 

Mofcomp.log

The Mofcomp.log file contains compilation details from the MOF compiler.

The compiler writes two messages to the log when it compiles your MOF file. The first entry identifies the MOF file being compiled. The second entry shows that the compiler successfully parsed and committed your MOF entries in the WMI repository, or that a syntax or WMI error occurred. Be aware that the compiler returns on the first error it encounters.

The following log entry shows that an illegal constant value was specified on line 15 of the MOF file.

carpool.mof (15) : error SYNTAX 0X006c: 
Illegal constant value. 
(Numeric value out of range or strings without quotes)

When the MOF file is syntactically correct, the compiler attempts to commit your MOF entries in the CIM repository. If an error occurs, the compiler logs an entry that contains the WMI HRESULT value and a brief description of the error. The description also contains the line number of the object that failed.

For example, the following log entry shows that object 2 of the MOF file contains a type mismatch.

An error occurred while creating object 2 defined 
on lines 9 - 15: 0X80041005: 
The value specified for property 'parentnodekey' conflicts 
with the declaration of the property.

Wmiadap.log

The Wmiadap.log trace log file contains error messages related to the AutoDiscoveryAutoPurge (ADAP) process. For more information, see Performance Libraries and WMI and ADAP Event Messages Before Vista.

Wbemprox.log

The following table lists some common problems that can occur and offers possible causes and solutions.

Message Description
ConnectViaDCOM, CoCreateInstanceEx resulted in hr = 0x800706ba

This is a WMI connection error that you receive for one of the following reasons:

  • Incorrect server is specified
  • Incorrect credentials
  • Environment error, such as the RPC server is unavailable
NTLMLogin resulted in hr = 0x8004103 : Access denied was returned, giving up! The most common HRESULT from this message indicates that you do not have permission to perform the action. The second-most common HRESULT indicates that an incorrect namespace was specified or that the namespace does not exist. It is also possible to get various RPC errors returned with this message.

 

Framework.log

Trace information and error messages for the provider framework and the Win32 Provider. The Provider Framework classes are obsolete and not recommended. For more information about the preferred ways to write a WMI COM provider or a WMI provider that uses the .NET FrameworkMicrosoft.Management.Infrastructure namespaces, see Using WMI. (the System.Management namespace is no longer supported.)

The following table lists some common problems that can occur and offers possible causes and solutions.

Message Description
Impersonation failed. The client must connect with an authentication level of Impersonate or Delegate.
Failed: Invalid class name. The namespace specified in the static constructor for your class is incorrect.
ERROR CInstance(<class name>)::SetCHString(<property name>) FAILED!error# <hresult> This is the most common log entry.

For example, the following message indicates that the provider framework was unable to set the AdapterCompatibility property. The HRESULT indicates that the AdapterCompatibility property was not found in the Win32_DesktopMonitor class.

ERROR CInstance(Win32_DesktopMonitor)::SetCHString(AdapterCompatibility) FAILED!error# 80041002

 

Winmgmt.log

Trace information that is typically not used for diagnostics.

The two most common entries in Winmgmt.log are the following:

  • Core is being shut down by WinMgmt.exe; it returned 0x0

    The core was successfully shut down and a WMI HRESULT of 0 was returned.

  • Core is being shut down by WinMgmt.exe; it returned 0x80041001

    The program was unable to shut down the core because the program was still in use. An HRESULT that is nonzero is returned.

WMI Log Files