WMI Troubleshooting Techniques
You can troubleshoot WMI by using the following steps:
If the management application or script seems to be partially successful by using WMI or it returns a complex error message, see the "Programming Issues" section later in this appendix.
If the management application or script is running successfully but very slowly or it is causing WMI to consume excessive resources on the computer, see the "Resource Consumption Issues" section later in this appendix.
Ensure that WMI is installed. Verify that the %Windir%\System32\WBEM directory exists and that it contains WinMgmt.exe. For more information, see the "Installation Issues" section later in this appendix.
Connect to WMI by using a WMI browsing tool. If you cannot connect to WMI, see the "Connectivity Issues" section later in this appendix.
Review WMI security by using WMI Control (or Wbemperm.exe for earlier versions of WMI). Ensure that the accounts that are used by your management application are able to access WMI and the namespaces that are used by that application.
Use a WMI browsing tool to browse the namespace that is used by your management application. You should be able to find the relevant classes and see instances of data that should be available. If classes are missing, you might have to recompile the MOF files for the management application or reinstall the management application. If instances are missing, troubleshoot the provider for the system that is being managed (the Exchange Provider, for example) and the system itself.
Review the logs that are available in the %Windir%\System32\wbem\logs directory. The logs are described in Table B.4.
Use WMI Control to enable verbose logging. Reproduce the problem and review the logs again. Set WMI logging back to normal after you complete this step.
If the problem might be provider-specific, enable provider logging. In addition to default WMI logging, you can enable provider logging by changing the Logging or Level values in the following registry tree:
HKLM\Software\Microsoft\WBEM\Providers\Logging
If you think that the CIM Repository might be corrupted, verify that it has a normal complement of namespaces, providers, and classes. For more information, see the "Verifying the State of the CIM Repository" section later in this appendix. If this confirms that the CIM Repository is corrupted, see the "Backing Up WMI Data" section earlier in this appendix.
For additional solutions to your problem, see the Microsoft Knowledge Base at https://support.microsoft.com.
If a later version of WMI, DCOM, or the operating system (even a service pack) is available, apply that upgrade.
Contact Microsoft Product Support Services.
Table B.4 WMI Logs
Log |
Content |
|---|---|
Wbemcore.log |
Core |
WinMgmt.log |
The WMI service |
Framework.log |
The WMI framework, including the Win32 Provider |
Wbemess.log |
The event subsystem |
Setup.log |
Setup and upgrade |
Mofcomp.log |
MOF Compiler messages |
Wbemprox.log |
The connection proxy, which is relevant during the connection to WMI, especially for DCOM-related issues |
WMIAdap.log |
The high-speed performance counter adapter |
WMIProv.log |
Providers-related issues, but not necessarily provider-specific issues |
WMIC.log |
The WMI Command-line tool |
Dsprovider.log |
The Active Directory provider |
NTEvt.log |
The Windows NT event log provider |
WbemSnmp.log |
The SNMP Provider |
Note
- The WMI logs might have a file name extension of .lo_. This is the previous version of the log. When the logs grow to a specific size, the log is renamed with the .lo_ file name extension and a new log is created for new entries. Any previous log with the .lo_ file name extension is overwritten.
For More Information
Did you find this information useful? Please send your suggestions and comments about the documentation to smsdocs@microsoft.com.