Previous Page
Next Page

Obtaining Diagnostic Information

If the previously discussed checks do not point to an immediate solution, the next step is to obtain more information. To do this, you have several tools at your disposal. The primary source of troubleshooting information is WMI logging. By changing the logging level to Verbose, you will generate a diagnostic trace of WMI events in several WMI logs.

Enabling Verbose WMI Logging

WMI has three logging levels: Disabled, Errors Only, and Verbose. These logging levels are recorded in the registry at the following location:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\Logging

A value of 0 disables all logging, a 1 will enable errors only logging, and a value of 2 will set the logging to Verbose.

These logging levels can be set using the WMI Control tool. As seen in Figure 21-4, the logging levels are displayed on the Logging tabthe same tool used to increase or decrease the logging level. After the WMI problem is solved, it is important that you reduce the logging level back to Errors Only, or the increased logging activity could cause performance problems for WMI and for all applications that rely upon its services. To increase the logging level, follow the steps listed below:

1.
Click Start and then click Run.

2.
In the Run dialog box, type wmimgmt.msc and click OK.

3.
Right-click WMI Control (Local).

4.
Select Properties.

5.
Select the Logging tab.

6.
Change Logging Level to Verbose.

7.
Increase the maximum log size to 256,000 or higher.

8.
Click OK and close the Microsoft Management Console (MMC).

Increasing the logging level will take effect immediately in Windows XP and on Windows Server 2003. Earlier versions of Windows will require a reboot.

Figure 21-4. Verbose logging is a primary source of troubleshooting information


Examining the WMI Log Files

The WMI log files are stored in the %systemroot%\system32\WBEM\Logs\ directory by default. This is configurable from the Logging tab, as seen in Figure 21-4. In addition, the WMI log file directory is recorded in the registry at the following location:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\Logging Directory

If you open the Logs directory, you will find a number of WMI logs. One of the challenges in troubleshooting WMI is to select the correct log file in which to look for the correct information that is needed to troubleshoot the problem at hand. Table 21-1 provides a quick listing of the most common WMI log files, as well as the purpose of each file.

Table 21-1. WMI log files and their usage

Log File

Purpose

Dsprovider.log

Traces information and error messages for the Directory Services provider

Framework.log

Traces information and error messages for the provider framework and the Win32 provider

MofComp.log

Compiles details from the MOF compiler, including MofComp failures during setup

Ntevt.log

Traces messages from the Event Log provider

Setup.log

Reports on MOF files that failed to load during the setup process

Viewprovider.log

Traces information from the View provider

WbemCore.log

Provides logging from the WbemCore provider

Wbemess.log

Logs entries related to events

Wbemprox.log

Traces information for the WMI proxy server; remote logons

Winmgmt.log

Traces information that is typically not used for diagnostics

Wmiadap.log

Provides error messages related to the AutoDiscoveryAutoPurge (ADAP) process

Wmiprov.log

Provides management data and events from WMI-enabled Windows Driver Model (WDM) drivers; hardware


Your computer system may or may not have all these log files. Some of the providers will have their own procedure for configuring logging levels. For example, the View provider requires adding a registry key to the following location:

HKEY_LOCAL_MACHINE \SOFTWARE\Microsoft\WBEM\
PROVIDERS\Logging\ViewProvider\Level

Once the registry key is added, you use the same 0, 1, and 2 values to configure no logging, error only logging, or verbose logging respectively. This works in the same way as setting the overall WMI logging level.

The key WMI log files that you will probably use the most are listed below:

  • WbemCore.log

  • MofComp.log

  • Wbemprox.log

Tip

Use the date. When I am troubleshooting a WMI issue, once I bump up the diagnostic logging, the next thing I do is try to reproduce the problem. If I am successful in reproducing the problem, I will note the time, open the WMI logging directory, and sort by time. Sometimes, if I am lucky, I will find a log file with a time stamp that is very nearly the time I noted when I was able to reproduce the error. I also like to use the VBScript Now function in my script that is generating the error, because it will give me a time stamp I can refer back to when I am analyzing a diagnostic log file. If you follow this simple procedure, you can easily eliminate more than half of the WMI log files in your troubleshooting due to the fact they were not updated around the same time that you reproduced the error.


Using the Err Tool

As you look through the WMI log files, you will quickly see that they are filled with strange numbers. The Err.exe tool is sometimes called the Exchange Server Error Code Look-Up Tool, but it is much more than that. It pulls error codes from header files installed on your computer. On my Windows XP computer at home, it can supply information on nearly 20,000 error messages that come from more than 170 different sources--and I don't even have Microsoft's Exchange server installed at home! The Err.exe tool can be downloaded for free from the Microsoft Download center at http://www.microsoft.com/downloads. If you do a search for Exchange Server Error Code, the Err.exe tool will be the only item returned. We will use the Err tool in the Step-by-Step exercise while troubleshooting some WMI script problems. The Err tool is a single executable and does not need installation. This means it can easily be copied to any machine. To use the Err tool, type err at a command prompt (ensuring it is in the path) and supply an error number. An example of this is seen below:

C:\Utils>err 0x80041003

The tool will return every match it has for the error number. You may get only one item or you may get many, depending on the error number. You should always look for a source that is related to what you are troubleshooting. In the output below, we see there are two sources that generate an 0x80041003 error. But because we are troubleshooting a WMI problem, we choose the meaning Access Denied, because it is generated from wbemcli.h. We choose this meaning from the Err.exe output because wbemcli looks similar to wbem clientwhich sounds like an application that is using WMI.

# for hex 0x80041003 / decimal -2147217405 :
 REC_E_TOODIFFERENT                      reconcil.h
 WBEM_E_ACCESS_DENIED                     wbemcli.h
# 2 matches found for "0x80041003"

Using MofComp.exe

MofComp.exe is a tool that is used to compile MOF files. We will use MofComp in the One Step Further exercise. There are basically two times when you will need to use MofComp. If you have a MOF file you need in WMI, you will need to run MofComp to add the MOF to the repository. You would use MofComp in these situations to add additional functionality to WMI. Some applications do not register themselves with WMI for autorecovery, and if you ever delete the repository, you will need to recompile those MOFs back into WMI after rebuilding the repository. In either case, the syntax is the same. If we look at the number of switches available for MofComp, it looks like a rather complicated tool. This is seen below:

Microsoft (R) 32-bit MOF Compiler Version 5.1.2600.2180
Copyright (c) Microsoft Corp. 1997-2001. All rights reserved.

usage: mofcomp [-check] [-N:<Path>]
        [-class:updateonly|-class:createonly]
        [-instance:updateonly|-instance:createonly]
        [-B:<filename>] [-P:<Password>] [-U:<UserName>]
        [-A:<Authority>] [-WMI] [-AUTORECOVER]
        [-MOF:<path>] [-MFL:<path>] [-AMENDMENT:<Locale>]
        [-ER:<ResourceName>] [-L:<ResourceLocale>]
        <MOF filename>

  -check          Syntax check only
  -N:<path>         Load into this namespace by default
  -class:updateonly     Do not create new classes
  -class:safeupdate     Update unless conflicts exist
  -class:forceupdate    Update resolving conflicts if possible
  -class:createonly     Do not change existing classes
  -instance:updateonly   Do not create new instances
  -instance:createonly   Do not change existing instances
  -U:<UserName>       User Name
  -P:<Password>       Login password
  -A:<Authority>      Example: NTLMDOMAIN:Domain
  -B:<destination filename> Creates a binary MOF file, does not add to DB
  -WMI           Do Windows Driver Model (WDM) checks, requires -B switch
  -AUTORECOVER       Adds MOF to list of files compiled during DB recovery
  -Amendment:<LOCALE>    splits MOF into language neutral and specific versions
               where locale is of the form "MS_4??"
  -MOF:<path>        name of the language neutral output
  -MFL:<path>        name of the language specific output
  -ER:<ResourceName>    extracts binary mof from named resource
  -L:<ResourceLocale>    optional specific locale number when using -ER switch

  Example c:>mofcomp -N:root\default yourmof.mof

Most of the time, you will not need any of these switches. In its most basic form, the MOF file tells WMI where to compile the class, namespace, or instance of an event provider. Using MofComp in this fashion only requires that you type mofcomp mymof.mof with no switches. Of course, mymof.mof would need to be the name of the MOF file you were trying to compile. The next most common MofComp command is one where you need to specify the namespace into which the MOF will be compiled. This is illustrated below:

C:\mofcomp -N:root\myNameSpace myMofFile.mof

Using WMIcheck

WMIcheck.exe is a tool that was developed by Microsoft Premier Support Services to aid in quickly gathering all the information needed to perform initial troubleshooting of WMI configuration problems. The amount of information supplied by this tool can save you hours of information gathering. It is included in the \My Documents\Microsoft Press\VBScriptSBS\Resources folder on the CD accompanying this book. To use the WMIcheck.exe tool, you open a command prompt and type the following command:

C:\>wmicheck >wmiCheck.txt

Open the WMIcheck.txt file that is produced by running the WMIcheck.exe program, in Microsoft Notepad. Some of the items reported by this program are listed below:

  • Registry settings for WMI, including default namespace, logging levels, and log file sizes

  • Operating system version and service pack level

  • Software installed on the computer

  • Services and processes running on the computer

  • A listing of namespaces, providers, and event filters defined on the computer


Previous Page
Next Page