Basic WMI Testing

Basic WMI Testing

  • Comments 8
  • Likes

OK - following on from our recent WMI Architecture post, let's start digging into some Basic WMI Troubleshooting.  There's a lot of material to cover, so this is going to be a multi-part series!  It's important to note that these are general concepts and tips and the order in which we publish the material may not necessarily be the order in which you should troubleshoot your WMI Issue!

When accessing WMI local or remote data in an application or script, you may encounter errors ranging from missing classes to access denied.  The first step in most WMI-related cases is to test the ability to connect to the service on the local computer. Depending on the nature of the problem, you may also have to test the ability to connect to the WMI service on a remote computer.

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.  Despite what you may have heard or read elsewhere, deleting or rebuilding the WMI repository as the first step in troubleshooting is not recommended!  Deleting the WMI repository could cause issues with the operating system or 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.  After you have downloaded the utility, extract the files to C:\WMIDiag (for simplicity's sake) and run the WMIDiag.vbs file.  By default the WMIDiag script will write the output to the user's temp folder, so I suggest defining where you want the log files written when you run the script - as follows: cscript c:\wmidiag\wmidiag.vbs LOGFILEPATH=c:\wmidiag.  Once the script is finished, the log file will identify WMI issues.  We'll look at WMIDiag in more detail in a future post. 

Now let's take a quick look at some very simple troubleshooting steps that we could use to determine if the WMI Service is functioning.

Testing the Local WMI services

Oftentimes, the quickest way to test the if the WMI service is working at all is to just start the WMI Control snap-in.

  1. Click Start, click Run, type wmimgmt.msc, and then click OK.
  2. Right-click WMI Control (Local), and then click Properties. 

image

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.

Starting with Microsoft Windows XP, the version of WMI should match the build version of the operating system.  For example, in Windows XP, the WMI version is "2600.0000," and in Microsoft Windows Server 2003, the WMI version is "3790.000."  The version of WMI in Microsoft Windows 2000 is "1085.0005."  In versions of Windows earlier than Windows 2000, WMI was an installable component. The two most common distributions were v1.1 (build 698) and v1.5 (build 1085).  On Windows XP and later operating systems, you can also use the WMIC utility to retrieve the OS build information - wmic OS get Caption,BuildNumber.

It is important to note that in the majority of instances, if you are able to pull up this information locally, then your WMI repository is in good shape (at least from a basic OS perspective).

Sometimes, you may have to test the ability to connect to the WMI service on a remote computer. The process is similar to the local test.

Testing the WMI Service on a Remote Machine

 The process to perform a quick test of the WMI services on a remote machine is not much different than testing the local services.image

  1. Click Start, click Run, type wmimgmt.msc, and then click OK. 
  2. Right-click WMI Control (Local), and then click Connect to another computer. 
  3. Click Another computer, and then enter the name of the remote computer. 
  4. If you have to provide user credentials, click Change. 
  5. Click OK. 
  6. Right-click WMI Control (remote system name), and then click Properties.

In this example, I am connecting from my Windows Vista machine to my Windows Server 2003 machine which is named DARKSIDE.  As you can see, I am able to retrieve the same information as if I ran the WMI test locally.

If you cannot connect to WMI on a remote computer, the first thing to do is test the WMI service locally on both of the computers (local and remote). If the WMI service looks good locally on both computers, then there may be a problem with COM permissions (which we'll look at in a future post).

Now let's take a look at testing WMI via a local script.

The Win32_WMISetting class was added in WMI v1.5 (Windows 2000, build 1085).  Starting with this version, you can use the script that follows to gather the WMI settings data, including the build version.  This script does not work on build 698, which is distributed with Microsoft Systems Management Server (SMS) for Microsoft Windows NT 4.0 clients and Microsoft Windows 9x clients).  This script can be used as quick test of the WMI service (and scripting interface) on Windows 2000 and later versions of the Windows operating system.

Paste the following script into a text file, and then save the file with a .vbs extension (for example, Test.vbs):

set WMI = GetObject("WinMgmts:/root/cimv2") 
set obj = WMI.Get("Win32_WMISetting=@")
WScript.Echo obj.GetObjectText_(0)

When you run the script, the WMI Core Settings are returned, including a listing of all the MOF Files, the Build Version, the location of the WMI Repository and other settings.  To test the provider host interface you could use a script similar to the one below:

set WMI = GetObject("WinMgmts:/root/cimv2")
set objs = WMI.InstancesOf("Win32_OperatingSystem")
for each obj in objs
WScript.Echo obj.GetObjectText_
next

If you recall our review of a basic script from our WMI Architecture post, this script parses the Win32_OperatingSystem WMI class and returns the values for each instance within the class.

And that brings us to the end of our post on Basic WMI Testing.  In our future posts, we'll discuss Access Denied and Invalid Namespace issues, how to troubleshoot service startup failures, Data Gathering and more.

Additional Resources:

 - Axel Rivera

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • PingBack from http://www.ditii.com/blog/2007/06/22/basic-wmi-testing/

  • Back in June, we published our post on Basic WMI Testing . Today we're going to go over some common issues

  • having high processor usage associated with wmiprvse.exe.  After running "wmidiag checkconsistency" I have identified HiPerfCooker_v1 event in the log, along with "incorrect shutdown events".  Symantec virus signatures have been checked and wmiprvse.exe passes the scan.  Running VS debugger on the process (from task manager) in the monitor view shows huge number of dlls continuously getting loaded.  Please help with solution.

  • Joe -

    You would be best served by opening a support incident with Microsoft Product Support.

  • I am having problems with overflow of SeaMonkey and the error is always associated with an installation of HiPerfCooker_V1. Was not this only a statistical counter? I appreciate your help.

  • Yes. I too encountered Hi PerfCooker_v1. Just before the bios on my HP dv6000 series laptop game computer was fried.

    There were many freeze ups. There was one final crash.

    I found HiPerfCooker_v1 on a computer management log.

    The HP dv6000 series laptops have a well known graphics processor weakness that was exploited to destroy the computer. Read motherboard here.  The DRM or spyware forces the wireless, probably with its own drivers, to open either to fry the computer or transmit data. The hard drive winds up trashed, it can be check discked but not healed, like a worm, maybe it is, it fills up again with fragments. The wireless unit will become extremely hot. That heat transfers to whatever is nearby. It corrupts memory. Power cords were also defective, but that might be because of feedback from the wireless. Just FYI.

    I tried looking at the hard disk later, couldn't even get into it, didn't want to at that point, and I doubt that I'll even try to use the ram. Once your physical equipment has been corrupted with strange electrical or radio charges, who knows what it's goin to do, it will retain negative and positive polarities that it shouldn't be keeping. It's a subtle thing. Deep fried notebook isn't. Thank you.

  • I'm running Vista with a WMI version of 6001.18226.  The button that enables us to change credentials when connection to WMI on another computer does not exist.

  • WMIDiag 2.1 is now available!

    www.microsoft.com/.../details.aspx

    Supported Operating Systems: Windows 7, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Vista, Windows XP