WMI can fail for a number of reasons. Some of those can include not having appropriate rights and permissions for access to machines or namespaces, problems with provider registration, corrupted repository, and scripting errors to name a few.
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.
Never delete the WMI repository as a first troubleshooting step because deleting the repository can cause damage to the system or to installed applications.
Scoping the Issue:
When dealing with troubleshooting remote WMI connectivity, we need to first ensure that the local WMI subsystem is healthy. The quickest way to do this is via the WMI Control snap-in. Please refer to the
WMI Permissions and General Errors
topic on the AskPerf Support Center for testing and ensuring that WMI is working locally on each box as well as data collection before moving to troubleshooting remote connectivity.
Click Start, click Run, type wmimgmt.msc, and then click OK.
Right-click WMI Control (Local), and then click Properties.
If the WMI service is configured correctly, the WMI Control will connect to WMI and display the Properties dialog box.
On the General tab, you should see information about the operating system and the version of WMI. If it shows any errors or is unable to display the information, document the message seen (or capture a screenshot)
When working on WMI issues, we also need to check the status of DCOM. If you are not terribly familiar with DCOM, our blog post "
COM and DCOM for Administrators
" is a good place to get familiar with the basics. Changes to default COM security may result in problems and unexpected results. We can use DCOMCNFG to view and change settings as needed
Click Start, click Run, type dcomcnfg, and then click OK.
Expand the Component Services node.
Expand the Computers node.
Right-click the My Computer node, and then click Properties.
Click the [Default] COM Security tab.
Make sure that the Default Access Permissions lists the following accounts:
Windows XP / Windows Server 2003
Local and Remote
Windows Vista / Windows Server 2008
You can add the Administrators group and grant the group Local and Remote access if it is not already present.
Under the Default Launch and Activation Permissions, ensure that at least INTERACTIVE, SYSTEM and Administrators are set to Allow Launch locally and remotely.
In all instances, collecting either
with the General, Internet and Networking, Business Networks and Server Components diagnostics, or a Performance-oriented MSDT manifest must be done. Additional data required may include the following:
Run the WMIDiag utility for all issues
The WMI Diagnosis Tool can be run from Windows Explorer or from the command line. (cscript wmidiag.vbs)
Each time it runs, the WMI Diagnosis Tool creates three files: A .LOG, .TXT, and a CSV file
The three files are created, by default in the %TEMP% directory
Configure WMI Verbose logging on the local (and remote machines if needed) via the WMI Management snap-in (wmimgmt.msc)
Right click on WMI Control (local) and select Properties
Select the Logging tab, and change the "Logging Level" to verbose
Set the "Maximum Size" value to 26214400
Troubleshooting / Resolution:
Once you have gathered the data, here are some things to check:
Review the Event Logs for relevant events
You should also check the Event Logs and Windows Update logs to see if there were any application updates or patches that preceded the unexpected behavior - there may be a correlation
Review the WMIDIAG report.
At the end of the .LOG file you will find the WMI report which is the same information found in the .TXT file. Fix all reported problems suggested by the WMI Diagnostic Tool