Obtaining Diagnostic InformationIf 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 LoggingWMI 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:
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 FilesThe 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.
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:
Tip
Using the Err ToolAs 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.exeMofComp.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 WMIcheckWMIcheck.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:
![]() |