WMI Troubleshooting

When accessing WMI local or remote data in an application or script, you may encounter errors ranging from missing classes to access denied. Providers also have debugging options and troubleshooting classes available. For more information about troubleshooting problems with WMI scripts and the WMI service, see WMI Isn't Working!

WMI Diagnosis Utility

If WMI returns error messages, be aware that they may 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 any circumstances, do not delete the WMI repository as a first action because deleting the repository can cause damage to the system or to installed applications.

To obtain more information about the source of the problem, you can download and run the WMI Diagnosis Utility diagnostic command line tool. This tool produces a report that can usually isolate the source of the problem and provide instructions on how to fix it. The report also aids Microsoft support services in assisting you. You can download the WMI Diagnosis Utility at the Download Center.

 

Provider writers may also encounter debugging issues unless you are writing a decoupled provider. For more information, see Debugging Providers.

Logging and Tracing

Starting with Windows Vista, the WMI log files no longer exist. They are replaced by Event Tracing for Windows (ETW). For more information, see Tracing WMI Activity, Logging WMI Activity, and WMI Log Files.

Troubleshooting in Scripts and Applications

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

How Provider Writers Can Prevent WMI Problems

 

Provider writers can prevent many problems, which 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 information, see Debugging Providers, Providing Data to WMI, and Provider Configuration and Troubleshooting Classes.

Access Denied

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.

Error	Possible Issues	Solution
0x800706BA - RPC Server Unavailable Firewall issue or server not available.	The computer really doesn't exist · The Windows Firewall is blocking the connection	Connecting to Vista: netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=yes Connecting to downlevel: Allow the "Remote Administration" rule in Windows Firewall.
0x80070005 – E_ACCESS_DENIED Access denied by DCOM security.	The user does not have remote access to the computer through DCOM. Typically, DCOM errors occur when connecting to a remote computer with a different operating system version.	Give the user Remote Launch and Remote Activation permissions in dcomcnfg. Right-click My Computer-> Properties Under COM Security, click "Edit Limits" for both sections. Give the user you want remote access, remote launch, and remote activation. Then go to DCOM Config, find "Windows Management Instrumentation", and give the user you want Remote Launch and Remote Activation. For more information, see Connecting Between Different Operating Systems
0x80041003 – WMI Access Denied Access denied by a provider	The user does not have permission to perform the operation in WMI. This could happen when you query certain classes as a low-rights user, but most often happens when you attempt to invoke methods or change WMI instances as a low rights user. The namespace you are connecting to is encrypted, and the user is attempting to connect with an unencrypted connection	Give the user access with the WMI Control (make sure they have Remote_Access set to true) Connect using a client that supports encryption.

 

• 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.

  The firewall is enabled in the Windows XP with Service Pack 2 (SP2) client, but not in Windows Server 2003 with Service Pack 1 (SP1) or Windows Server 2003 R2. For more information, see Connecting Through Windows Firewall.

  Windows Server 2003, Windows XP, Windows 2000, Windows NT, and Windows Me/98/95:  ICF does not exist.

• 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.

Information on Errors

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.

Related topics

WMI Troubleshooting

Tracing WMI Activity

Logging WMI Activity