WMI Diagnosis Utility

A New Utility for Diagnosing and Repairing Problems with the WMI Service

Download the All-New WMI Diagnosis Utility

Version 2.0 of the WMI Diagnosis Utility is now available in the Microsoft Downloads Center

The newly-revised WMI Diagnosis Utility is a VBScript script written by Alain Lissoir of the WMI team at Microsoft. This utility is designed to help you ascertain the current state of the WMI service on a computer. (For a complete list of all the tests carried out by the WMI Diagnosis Utility, see Appendix A.) The utility can do everything from verify the validity of all your WMI namespaces to check for possible corruption of the WMI repository. (Although we should note that the ability to check for repository corruption is limited to computers running Windows® XP Service Pack 2 or Windows Server™ 2003 Service Pack 1.) The WMI Diagnosis Utility performs a detailed examination of the WMI service and all its related components. If a problem is found, the utility not only reports on the problem and its possible causes, but also offers suggestions for repairing the problem. (Note that this is a diagnostic tool only: although it will offer step-by-step instructions for fixing a problem it cannot fix the problem itself.)

The WMI Diagnosis Utility runs on Windows 2000, Windows XP, Windows Server 2003, and Windows Vista™. The utility needs no additional software other than Windows Script Host (WSH), which is installed and enabled by default on all those versions of Windows. The WMI Diagnosis Utility must be run locally (you cannot run the script against a remote computer), and you must have local administrator rights on any computer on which you run the script.

So why can’t you run the tool against a remote computer; isn’t WMI supposed to work against remote computers just as well as it does against the local computer?

Yes, but remember, you might very well be running the utility because you suspect that there is a problem with the WMI service. If the WMI service is not working properly, then it’s likely any WMI script that you try running will fail. Therefore, the WMI Diagnosis Utility does not rely on WMI itself; for example, it uses Windows Script Host methods when retrieving information from the registry. This enables the tool to function even when the WMI service is not working; however, this also prevents the tool from running against remote machines. That’s because many of these WSH methods can run against only the local computer. However, the WMI Diagnosis Utility can be initiated using applications such as Systems Management Server (SMS) or Microsoft® Operations Manager (MOM). Likewise, you can run the utility with a Group Policy logon script.

Is This Something I Should Be Using?

Maybe, but then again, maybe not. The WMI Diagnosis Utility is designed for use by experienced Windows and/or SMS administrators. This is not just because the script requires local administrator privileges. On top of that, you will likely require administrative experience in order to make sense of the tool’s reports and recommendations. And you will definitely need this kind of experience in order to undertake any suggested remedies. For example, the WMI Diagnosis Utility might recommend that you change a number of values in the registry, a task that is not recommended for anyone new to computing.

When Should I Run the Utility?

The WMI Diagnosis Utility should be run any time you suspect that you are having problems with the WMI service. This suspicion might have manifested itself either because of obvious problems with WMI itself or because of problems with other software programs known to use WMI. However, you might also want to periodically run the utility on all your servers; this helps you identify potential problems before they begin to affect the functioning of a server.

How Do I Run the Utility?

In most cases you can run WMIDiag.vbs without any command-line parameters. The WMI Diagnosis Utility is designed to run under the CScript script host; however, you do not have to specify the script host when starting the tool. If the utility detects that it is running under WScript it will run, albeit in “silent” mode: that is, no data will be output to the screen. (That’s to prevent you from having to dismiss literally hundreds of dialog boxes.)

The bottom line? You can run the WMI Diagnosis Utility, using the default settings, simply by double-clicking the WMIDiag.vbs icon in Windows Explorer, or by typing the following from the command prompt:

wmidiag.vbs

Note. This document details many of the more useful command-line parameters that can be used when starting the WMI Diagnosis Utility; however, not all of the optional parameters are discussed here. To get a complete list of command-line parameters, along with a brief explanation of each parameter, simply specify the ? parameter when starting the utility:

wmidiag.vbs ?

Although execution times will vary based on everything from processor speed to the size of the WMI repository, you can assume that it will take the utility several minutes (anywhere from 5 to 15 in preliminary tests) to complete its work. As the tool runs it displays detailed progress information on the screen:

This information is displayed primarily to let you know that the tool is still working. If you have no need to view progress then you can suppress the on-screen display of information by including the NoEcho parameter when starting the tool:

wmidiag.vbs NoEcho

As it runs, the WMI Diagnosis Utility also records information to a pair of text files; these two files will have names similar to the following:

• WMIDIAG-V1.10_XP__.CLI.SP1.32_TOMSERVO_2006.02.05_22.30.19.LOG. This file contains a detailed listing of all the actions carried out by the tool, as well as a summary report of its findings and recommendations.
• WMIDIAG-V1.10_XP__.CLI.SP1.32_TOMSERVO_2006.02.05_22.30.19-STATISTICS.CSV. This file contains information that – if you choose to share it – can be used by Microsoft to help track trends and analyze the overall state of WMI.

The file names are a combination of WMIDiag and its version number (WMIDIAG-V1.10), the operating system (XP__.CLI.SP1.32), the computer on which the tool is running (TOMSERVO) and the date and time at which the script was started (2006.02.05_22.30.19). The WMI Diagnosis Utility always writes information to these text files, which are stored by default in the user’s temp folder. This folder (for example, C:\Documents and Settings\KenMyer\Local Settings\Temp) is determined by the value of the %TEMP% environment variable. You can redirect these files to an alternate location simply by including the LogFilePath parameter in your startup command. For example, this command causes the tool to write information to the C:\Scripts folder:

wmidiag.vbs LogFilePath="C:\Scripts"

Tip. Because the utility uses the current timestamp when naming files it will not overwrite any existing files. This has some obvious advantages, but at least one disadvantage: log files will begin to accumulate – and use up valuable disk space – over time. Is there an easy way to deal with that problem? Yes: simply include the OldestLogHistory parameter when starting the tool. When you use OldestLogHistory and a specified value, the WMI Diagnosis Utility will automatically delete log files older than that value. For example, this command will cause the tool to delete any log files older than 20 days:

wmidiag.vbs oldestloghistory=20

Writing Errors to the Event Log

Another optional parameter – LogNTEvents – will cause the utility’s messages (including error messages) to be written to the Application Event log. In turn, that makes it easy for you to use Microsoft Operations Manager (MOM) or a custom script to retrieve these messages from all of your computers.

Of course, the one drawback to this is the fact that, in a situation where the WMI service has become corrupted, you could easily find yourself writing hundreds of events to the event log. Because of that, you might want to use the LogWMIState parameter instead. This parameter causes only three events to be written to the event log:

• The time the tool started.
• The overall state of the WMI service: Success, Warning, Error.
• The time the tool ended.

A WMI Diagnosis Utility event will always have WSH as the source and will have an event ID of 0 if successful, 1 if an error occurred, and 2 if a warning was issued. For example:

The WMI Diagnosis Utility for SMS Administrators

The WMI Diagnosis Utility includes a command-line parameter – SMS – designed primarily for use by SMS administrators. When running under SMS mode, the tool does not display any message boxes. By default (and any time it is run in interactive mode), the utility will occasionally display information in a message box. For example, if errors are detected a message box similar to this appears; however these messages boxes do not apply when run under SMS mode:

Under SMS mode the tool also enables the NoEcho and Silent parameters. This allows the utility to run unattended, and to run without displaying information to the screen. In this mode the WMI Diagnosis Utility also turns off the ERRORLEVEL return code. By default the tool sets the ERRORLEVEL environment variable to one of the following values upon termination:

• 0 = SUCCESS
• 1 = ERROR
• 2 = WARNING
• 3 = Command Line Parameter errors
• 4 = User Declined

When the WMI Diagnosis Utility runs under the SMS parameter, however, ERRORLEVEL will not be changed. This is due to the fact that SMS always uses the exit code to determine whether or not the script was successfully completed. If the exit code is set to 2 (Warning) SMS will assume the script failed to run; it won’t realize that the script completed successfully but simply discovered some potential problems. If you are using SMS to run the tool you should always set the SMS parameter to On.

Of course, you do not need to be an SMS administrator in order to use the SMS parameter. Whether you are using SMS or not you can run the utility in silent, unattended fashion by starting the program like this:

wmidiag.vbs sms

You can also use an optional parameter – RunOnce – to ensure that the utility runs no more than once a day. Each time it runs, the tool updates a value in the registry:

HKEY_LOCAL_MACHINE\Software\Microsoft\WMIDiag\LastRun. When the RunOnce parameter is used, the WMI Diagnosis Utility checks the existing value in the registry. If that value indicates that the tool has already been run on this particular day, then the utility will exit without running a second time. Note that the utility bases this decision on the calendar, not on, say, a 24-hour period. If you run the tool at 11:50 PM on a Tuesday and then run it again at 1:00 AM on Wednesday, the program will run, even though barely an hour has elapsed. That’s because the dates on which the program ran (Tuesday and Wednesday) are different.

The RunOnce parameter is particularly useful when the WMI Diagnosis Utility is used in a logon script; after all, it’s not unusual for administrators to log on multiple times in a single day. By using RunOnce you prevent the tool from running each time these administrators log on.

Using BaseNamespace to Speed Up the WMI Diagnosis Utility

One of the tests the WMI Diagnosis Utility performs by default is to verify all of the classes found in all the WMI namespaces. Because of the size of the WMI repository this testing can take quite a bit of time: on a test computer running Windows XP, for example, the tool took approximately 15 minutes to complete.

If you want to use the utility to check the overall health of the WMI service you can reduce this time by as much as two-thirds by using the BaseNamespace parameter. When you specify a BaseNamespace, the tool still performs its global diagnostic tests; however, it verifies only the classes found in the specified namespace. For example, starting the WMI Diagnosis Utility using this command causes the utility to verify only classes found in the root\default namespace:

wmidiag.vbs basenamespace="root\default"

When run on the same test computer, the tool required just 5 minutes to complete all its tests when the BaseNamespace was set to root\default.

The BaseNamespace parameter is also useful if you have reason to believe that a particular WMI namespace might be the source of your problems. By setting the base namespace the tool will verify the classes in that namespace, but will skip verification of classes found in other namespaces.

What Do I Do When the Utility Finishes?

Once the WMI Diagnosis Utility finishes you should examine the log file. To be honest, much of the log file will be of little use to you: it’s simply a blow-by-blow account of each test that the tool ran. Instead, you should open the log file and search for the WMI REPORT: BEGIN section of the file. The report section provides a summary of the tests run by the tool. For example:

17424 21:01:35 (0) ** System drive:....... C: (Disk #0  Partition #1)
17425 21:01:35 (0) ** Drive type:......... IDE (IC25N040ATMR04-0)
17426 21:01:35 (0) ** There are no missing WMI system files: ...OK
17427 21:01:35 (0) ** There are no missing WMI repository files: ...OK

If the WI Diagnosis Utility has detected problems of any kind they will be noted either as warnings or as errors. For example, here’s a warning that indicates that the WMI logging level has been set to 1 instead of the recommended level of 2:

17479 21:01:35 (2) !! WARNING: - Unexpected registry key value:
17480 21:01:35 (0) ** -Current: HKLM\SOFTWARE\Microsoft\WBEM\CIMOM\Logging (REG_SZ) -> 2
17481 21:01:35 (0) ** -Expected: HKLM\SOFTWARE\Microsoft\WBEM\CIMOM\Logging (REG_SZ) -> 1

Errors will usually be accompanied by suggested ways to try and fix the problem:

17456 21:01:35 (1) !! ERROR: WMI service DCOM setup: ..........................
................................... ERROR!
17457 21:01:35 (0) ** => You can correct the WMI service DCOM configuration by executing the
'WINMGMT.EXE /REGSERVER' command.

At the end of the report the tool will summarize the overall health of the WMI service:

17489 21:01:35 (0) ** ERROR: WMIDiag detected issues that could prevent WMI to work properly!.

Check 'C:\DOCUMENTS AND SETTINGS\KENMYER\LOCAL SETTINGS\TEMP\

 WMIDIAG-V1.08_XP__.CLI.SP1.32_TOMSERVO_2006.02.12_20.48.29.LOG' for details.

Some tests check items that are absolutely critical in order for the WMI service to function; for example, certain files must be present for WMI to even run. If one of these tests fails the overall WMI state will be marked as Error. Other tests check items that are less critical; for example, a missing DCOM registration affects only the class supported by the unregistered provider but does not affect the WMI service as a whole. If one of these tests fails, the WMI service is marked as Warning. The following items result in a health level of Warning:

These items will result in a health level of Error:

After analyzing the report you should follow the suggested steps for correcting any problems that were uncovered. Upon completing the recommended procedures, run the tool again to verify that the problems have been repaired. If the problem truly has been fixed, it should no longer be flagged as a warning or error in the report.

What If That Didn’t Fix the Problem?

Suppose you take all the recommended steps and, upon re-running the WMI Diagnosis Utility, discover that the problems have not been corrected. In that case you can do one of two things: rerun the tool using the “CheckConsistency” parameter, or rerun the utility using the “WriteInRepository=Root” parameter.

Rerun the Utility Using the “CheckConsistency” Parameter

This parameter – which is applicable only to Windows XP Service Pack 2 and Windows Server 2003 SP1 – checks the WMI repository for consistency. If the test succeeds, that again means that the WMI service is probably not responsible for your problems. If the test fails, then the repository will automatically be rebuilt for you (a behavior built into Service Pack 2) and your current repository is saved as %SystemRoot%\System32\Repository.001.

Incidentally, CheckConsistency is automatically invoked any time the tool is run on a computer running Windows Server 2003 Service Pack 1. However, with this operating system a failed consistency test will not cause the repository to automatically be rebuilt. The repository will be rebuilt only if you manually request it to be rebuilt.

Rerun the Utility Using the “WriteInRepository=Root” Parameter

If you are not running Windows XP SP2 or Windows Server 2003 SP1 you can test the repository to a certain extent by writing information to the repository. The WriteInRepository parameter causes the tool to create 250 temporary class instances in each of the existing WMI namespaces. (By default this will take place in every namespace, although you can use the BaseNamespace parameter to specify a particular namespace.)

If the test succeeds that means no apparent problems were detected with the WMI repository; in turn, that suggests (but by no means guarantees) that WMI is not the cause of the problems you are experiencing. Operating systems other than Windows XP SP2 and Windows Server 2003 SP1 are unable to validate the consistency themselves. Fortunately, performing a write operation across all the namespaces of the repository is a good indicator of the repository state. If the test fails, you will likely have to rebuild the WMI repository. For more information on doing that, please see the article WMI Isn’t Working.

Checking for AutoRecover MOF Files

The WMI repository is built using MOF (Managed Object Format) files, text files that contain definitions of namespaces, classes, properties, methods, and other WMI objects. If you delete the WMI repository, the repository will automatically be rebuilt for you; however, it will only be built using the so-called “AutoRecover” MOFs, MOF files specifically listed in the registry. If a MOF file is not marked as AutoRecover then you will have to manually compile the file in order to restore it to the repository. If a MOF file is missing, then it will not be included in the rebuild of the repository either. For more information on how to mark a MOF file as autorecover, see the WMI SDK.

By including the ShowMOFErrors parameter when starting the WMI Diagnosis utility, your report will include, among other items, a list of MOF files (or at least those MOF files found in the %SystemRoot%\WBEM folder) that are not listed in the AutoRecover portion of the registry. That report will look something like this:

1) !! ERROR: MOF file(s) present in the WBEM folder not referenced in the Auto-Recovery list: 6 ERROR(S)!
0) ** - C:\WINDOWS\SYSTEM32\WBEM\CLIEGALIASES.MFL(*)
0) ** - C:\WINDOWS\SYSTEM32\WBEM\CLIEGALIASES.MOF(*)
0) ** - C:\WINDOWS\SYSTEM32\WBEM\FCONPROV.MFL(*)
0) ** - C:\WINDOWS\SYSTEM32\WBEM\FCONPROV.MOF(*)
0) ** - C:\WINDOWS\SYSTEM32\WBEM\NCPROV.MFL(*)
0) ** - C:\WINDOWS\SYSTEM32\WBEM\NCPROV.MOF(*)
0) ** => After fixing all other issues previously mentioned, if the WMI repository is rebuilt,
0) **    the listed MOF file(s) will not be recompiled, and therefore the definition they contain
0) **    will not be available in the WMI repository.
0) ** => You must manually recompile the MOF file(s) with the 'MOFCOMP.EXE <FileName.MOF>' command.
0) ** => If you want the MOF file(s) to be part of the Auto-Recovery list, make sure the
0) **    statement '#PRAGMA AUTORECOVER' is included.
0) **    Note: MOF file(s) marked with a (*) are not included BY DEFAULT in the auto-recovery process.

This output also includes:

• MOF files listed in the registry that cannot be found on the file system.
• Providers that do not have MOF files listed in the registry key or stored in the WBEM folder.

Associating Classes, Providers, and MOF Files

One very useful function included within the tool is the ability to associate each WMI class with its provider and with the MOF file for that provider. To generate this information, simply include the CorrelateClassAndProvider parameter when starting the tool:

wmidiag.vbs CorrelateClassAndProvider

Upon completion the utility will create a spreadsheet (with a name similar to WMIDIAG-V1.10_XP__.CLI.SP1.32_TOMSERVO_2006.02.12_22.45.42-PROVIDERS.CSV) that will contain an enormous amount of data about each class, each provider, and each MOF file:

This is a very useful reference, and it’s highly recommended that you use the WMI Diagnosis Utility to generate such a spreadsheet even if you are not currently experiencing any problems with the WMI service. The spreadsheet helps document the WMI setup of a critical machine; this is especially important if you have applications that add WMI objects that you do not know about. The download package for the tool includes spreadsheets for several standard operating system installations.

Sending WMI Diagnosis Utility Results to Microsoft

The WMI Diagnosis Utility includes the ability to email your report files directly to the WMI team at Microsoft. To do so, simply specify the SMTPServer parameter, followed by the name of your SMTP server:

wmidiag.vbs smtpserver="fabrikam_mail_server"

Why would you want to send your results to Microsoft? Two reasons. For one, the WMI team is gathering log files and using the aggregate information to look for trends and commonalities. This information is useful in improving both the WMI service and the utility itself. Second, it is possible, though not guaranteed, that someone from the WMI team will contact your about your problem.

Important. By including the SMTPServer parameter you agree to send your WMI Diagnosis Utility results to Microsoft and give Microsoft the right to use that information in its analyses.

You can also use the SMTPServer parameter to email results to someone other than Microsoft. To do that, simply include the SMTPTo parameter followed by the appropriate email address:

wmidiag.vbs smtpserver="fabrikam_mail_server" smtpto="kenmyer@fabrikam.com"

If you add the SmtpWMIInvalidState parameter then this information will be sent only if the WMI service is found to be in a Warning or Error state:

wmidiag.vbs smtpserver="fabrikam_mail_server" smtpto="kenmyer@fabrikam.com" smtpwmiinvalidstate

Use the command wmidiag.vbs ? to see a list of all the available SMTP parameters. These are especially useful if you need to supply a user name and password when connecting to your SMTP server.

What If I Still Have Questions?

Although we cannot guarantee you will receive an answer, send questions, comments, and other feedback to WMIDiag@microsoft.com.

Appendix A: Tests Carried Out By the WMI Diagnosis Utility

• Verifies the date and time when the tool was previously run. A warning is displayed if the tool is run more than once a day.
• Collects WMI system information based on the OS version, environment, a list of WMI system files, and registry keys.
• Checks for the presence of WMI system files in the %Windir%\System32\WBEM folder and returns an error if a file is missing.
• Checks for the presence in %Windir%, %Windir%\System32 and %Windir%\System32\Wbem folders of known Trojans and viruses that use WMI system file names (and thus appear like real WMI system files).
• Checks for the presence of WMI repository files and returns an error if a file is missing.
• Checks for the consistency of the CIM repository (on Windows XP SP2 and Windows Server 2003 SP1 only). Under Windows XP SP2 and Windows Server 2003 SP1, Windows implements a RUNDLL32 command validating the repository consistency. The generated log file (SETUP.LOG for Windows XP SP2 and REPLOG.LOG for Windows Server 2003 SP1) is parsed by the tool and any consistency error is returned by the WMI Diagnosis Utility. The utility always performs this validation under Windows Server 2003 SP1. This feature is optional under Windows XP SP2 because it rebuilds a new repository automatically when inconsistencies are discovered.
• Verifies the presence of the MOF files specified in the auto-recover registry key and returns an error if a listed file is missing.
• Verifies the presence of MOF files in the WBEM folder and matches them with the auto-recover registry key. An error is returned if a MOF file is missing in the auto-recovery registry key.
• Checks the WMI DCOM application registry keys and returns an error if a registry key is missing. You can see DCOM configuration information by running DCOMCNFG at the command prompt.
• Checks for the presence of the CLSID, TypeLib or Interfaces registry keys for all WMI COM servers and returns an error if a registry key is missing or incorrectly set.
• Checks the state of the Windows Firewall service, including Windows Firewall status, RemoteAdmin status and UNSECAPP.EXE exception presence and status.
• Checks the WMI service registry setup and returns an error if specific registry keys are missing or are set up differently than expected.
• Checks for the presence of services that are known to be dependent on the WMI service and returns information if any are found.
• Checks the RPSS service status, for example, running or stopped. If the RPSS service is stopped the utility starts it.
• Checks the WMI service status (for example, running or stopped) and starts it if stopped.
• Retrieves the WMI system settings such as __CIMOMIdentification, __ArbitratorConfiguration, __CacheControl, __ProviderHostQuotaConfiguration and writes their values into the log file. Any static instances coming from __ArbitratorConfiguration, __ProviderHostQuotaConfiguration, and __CacheControlStatistics are validated against the known defaults. Any modification against these static values will be reported in the log.
• Uses the WMI provider registration data (CLSID) to locate the corresponding MOF file from the known list (auto-recovery and WBEM folder MOF files). An error is returned if no corresponding MOF file is found. Some well-known providers, such as the SMS providers or the performance counter provider NT5_GENERICPERFPROVIDER_V1, do not store MOF files in the standard location (or might not even use MOF file registration). In these cases, the tool writes a warning in the log file but no error is returned in the report.
• Uses the WMI CLSID to check WMI DCOM registrations for coupled providers (in-process and out-of-process) and returns an error if no DCOM registration information is found. This means that there is a missing InProcServer32 or LocalServer32 registry key.
• Retrieves the list of WMI providers that are using a non-authorized LocalSystem hosting model or not specifying any Hosting Model. Exceptions are allowed for missing DCOM registrations for certain well-known providers that do not have a registration by design; for example, the MICROSOFT WMI TEMPLATE ASSOCIATION PROVIDER or the RSOP PLANNING MODE PROVIDER. In these cases, a warning is returned in the log but no error is returned in the report.
• Locates the corresponding DLL in the file system based on the DCOM registration data (InProcServer32 or LocalServer32 path). Returns an error if the file is missing.
• Determines whether an in-process or an out-of-process provider that has no DCOM registration is still used by some classes in the namespace. Returns an error if this is the case. If the provider with no DCOM registration is not in use then a dead registration warning is generated but no error is reported. However, the event is logged in the log file.
• Retrieves static information for each class in the namespace. The information is represented in MOF syntax. An error is returned if this operation fails.
• Retrieves instances of each static and dynamic class in the namespace if the RequestAllInstances parameter is specified. An error is returned if this operation fails. Note that it is possible to retrieve only the static instances with RequestAllInstances=Static. The same applies for the dynamic instances: RequestAllInstances=Dynamic
• Checks for the presence of some well-known namespaces. If the examined system lacks a well-known namespace, an error will be reported.
• Checks the state of the ADAP process (responsible for creating performance counters) to determine any issues that might prevent the creation of the performance classes.
• Checks WMI features by running queries to retrieve typical classes and instances. Any failures will be returned in the log file.
• Retrieves all hardware resource information (processor, memory, DMA and IRQ settings, disk controller, network setup, operating system configuration, updates) to gather more information about the hardware and software used. Captures the controller type for the bootable partition (for example, IDE or SCSI) and returns it in the WMI report. The information inventory capture requires a fully functional WMI installation. Any error during this inventory report returns errors in the log).
• Allows users to send the .LOG and .CSV files created by email.