WMI Troubleshooting

When accessing WMI local or remote data in an application or script, you might encounter errors ranging from missing classes to access denied. Providers also have debugging options and troubleshooting classes available.

Windows 7, Windows Server 2008 R2, Windows Vista and Windows Server 2008:

If WMI returns error messages, be aware that they might not indicate problems in the WMI service or in WMI providers. Failures can originate in other parts of the operating system, and emerge as errors through WMI. Under no circumstances should you delete the WMI repository as a first step; because deleting the repository can cause damage to the system or to installed applications.

Previously, to obtain more info about the source of the problem, you could download and run the WMI Diagnosis Utility diagnostic command line tool. This tool produced a report that could usually isolate the source of the problem, and provide instructions on how to fix it. The report also aided Microsoft support services in assisting you. The WMI Diagnosis Utility was previously available at the Download Center.

As a provider writer, you might also encounter debugging issues unless you're writing a decoupled provider. For more info, see Debugging providers.

The WMI log files no longer exist; they were replaced by Event Tracing for Windows (ETW). For more info, see Tracing WMI activity, Logging WMI activity, and WMI log files.

WMI contains a set of classes for troubleshooting client applications that use WMI providers. For more info, see Troubleshooting WMI client applications.

Provider-writers can prevent many problems (that appear in error messages through WMI) by performing the following actions:

• Registering your provider correctly. For more information, see Registering a provider.
• Adding the #pragma autorecover statement to the Managed Object Format (MOF) file that defines your provider classes.

For more info, see Debugging providers, Providing data to WMI, and Provider configuration and troubleshooting classes.

Access denied errors that are reported by scripts and applications that access WMI namespaces and data generally fall into three categories. The following table lists the three categories of errors along with issues that might cause the errors and possible solutions.

• Typically, DCOM errors occur when connecting to a remote computer with a different operating system version.

• Providers may also deny access to data in specific namespaces or may require certain levels of connection security. For more information, see Setting Client Application Process Security and Provider Hosting and Security.

• Access denied errors from Internet Connection Firewall (ICF) changes.

  For more information, see Connecting Through Windows Firewall.

• An access denied error is returned by DCOM security when a low-integrity client tries to access WMI. For example, an ActiveX control that is running in Internet Explorer, which has the security level set to low, does not have access to perform local WMI operations.

  Windows 7: Low-integrity users have read-only permissions for local WMI operations.

When you get an error message from WMI, you can locate the message in WMI Error Constants or, for scripting, WbemErrorEnum. However, the information supplied by the error alone is typically insufficient to determine what is happening. WMI repository corruption may masquerade as classes or instances "not found".

For more information about WMI errors:

• The WMI logs track events from within the WMI core and from providers. For more information, see Logging WMI Activity.
• Use the WMI Troubleshooting Classes to check WMI internal status or receive notifications of provider or WMI service events. For more information, see Provider Configuration and Troubleshooting Classes and Troubleshooting WMI Client Applications.

WMI Troubleshooting

Tracing WMI Activity

Logging WMI Activity