Compartir a través de

WMI Isn't Working!

  • Artículo

Troubleshooting Problems with WMI Scripts and the WMI Service

Important

Before you begin repairing suspected problems with the WMI service it is strongly recommended that you run the new WMI Diagnosis Utility. You should always run this utility before making any changes to the WMI service.

WMI is a resilient piece of software. For example, suppose the WMI service is stopped, yet you still try running a WMI script. What do you think will happen? Will the script fail? Will the computer lock up? Will the very fabric of space and time be ripped apart? Not exactly. Instead, the WMI service will probably just restart itself and run your script. Most likely you will never even know that the service had been stopped.

Is there a lesson in that for script writers? You bet there is: if you are having problems with a WMI script, don’t jump to conclusions and assume that WMI is broken. If you have a script that doesn’t work it’s usually due to a problem with the script and not due to a problem with WMI. Admittedly, you could encounter a catastrophic failure of WMI itself, a failure that requires you to re-register all the WMI components or to rebuild the WMI repository. However, it’s far more likely that any problems you are experiencing are the result of doing something like typing in an incorrect namespace or trying to connect to a remote computer where you do not have local Administrator rights.

This document (developed in conjunction with the WMI team at Microsoft) is designed to help you troubleshoot problems with WMI scripts and the WMI service. Although the focus here is on scripting, the same troubleshooting information can be applied to other WMI consumers, such as Systems Management Server (SMS).  Scenarios – and the error codes they produce – will often be the same regardless of whether you encounter problems using a script, the WMIC command line, a compiled application (such as SMS) that calls WMI, etc.

The topics in this document are listed roughly in order; for example, the last thing you should do is rebuild the entire Repository. However, it’s important to note that problems with WMI scripts and/or the WMI service can’t always be resolved on a step-by-step basis. Because of that, we encourage you to read the entire document and familiarize yourself with both the things that can go wrong with WMI scripts as well with steps you can take to try and correct those problems.

We also encourage you to play close attention to any error messages you receive when trying to run your script; those error messages are described in the WMI SDK and can often tip you off as to why the script isn’t working. In fact, if you know which error message is being generated by your script or if your problem seems to fit one of the more-common scenarios, then you can jump directly to the appropriate topic listed below (although we still recommend you read the entire document).

On This Page

  • My script doesn’t return any data
  • I can’t connect to a remote computer
  • I’m getting an 0x8004100E (“Invalid Namespace”) error
  • I’m getting an 0x80041010 (“Invalid Class”) error
  • I’m getting an error (0x800A01B6) that says a property or method is not supported
  • I’ve verified that the namespace, class, and property names are correct, yet my script still doesn’t work
  • I’m getting an 0x80041013 (“Provider not found”) or an 0x80041014 (“Component failed to initialize) error
  • I’m getting an error regarding provider registration
  • I have a script that I know is valid, the WMI service is running, and I’ve re-registered all the .dlls, yet my script still doesn’t work
  • I’ve rebuilt the WMI Repository and my script still doesn’t work

My script doesn’t return any data

To begin with, don’t panic: after all, it’s possible for a WMI script to work perfectly at yet not return any data. How? Well, consider the following script, which returns the name of each tape drive installed on a computer:

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colItems = objWMIService.ExecQuery("Select * from Win32_TapeDrive")

For Each objItem In colItems
    Wscript.Echo "Name: " & objItem.Name
Next

Suppose you don’t have any tape drives installed on the computer. In that case the script will return no information whatsoever. That’s to be expected: after all, the script can’t return the names of the tape drives installed on the computer if there aren’t any tape drives installed on the computer.

One way to check for this situation – the script is working correctly, but there is no data for it to return – is to retrieve the value of the Count property. Each collection returned by a WMI query includes a Count property that tells you the number of items in that collection; this is true even if there are no items in the collection (in that case, the Count will be reported as 0). For example, here’s a script that reports the number of tape drives installed on a computer (that is, the number of Win32_TapeDrive instances):

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colItems = objWMIService.ExecQuery("Select * from Win32_TapeDrive")

Wscript.Echo colItems.Count

If the Count comes back as 0 then your script is probably working fine. If the Count is greater than 0 (meaning you have at least one tape drive installed), then you have a problem. In that case, you might have written a WQL query so specific that nothing meets the criteria. For example, this script returns information about all the services named Alerter that are currently running:

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colItems = objWMIService.ExecQuery _
    ("Select * from Win32_Service Where Name = 'Alerter' and State = 'Running'")

For Each objItem In colItems
    WScript.Echo "Name: " & objItem.Name
Next

Needless to say, if the Alerter service on a computer is stopped then this script will not return any data; that’s because the service must meet both criteria: it must have the Name Alerter and a State of Running.

If you are having difficulty getting a script to return data, you might begin by simplifying your WQL query. For example, this script removes the Where clause and simply reports back the Name and State for each service installed on a computer:

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colItems = objWMIService.ExecQuery ("Select * from Win32_Service")

For Each objItem In colItems
    WScript.Echo objItem.Name, objItem.State
Next

By running this script, you can check the name and state of the Alerter service and then, if necessary, adjust your Where clause and try again. Because all Windows computers (well, except for Windows 98 computers) must have at least some services installed the preceding script should always return data of some kind. If it does not, then you have a more serious problem and should continue reading.

I can’t connect to a remote computer

Often times you will have a script that works great on your local computer; however, the minute you point that script towards a remote machine you get an error message similar to this:

If you get a message like this one it is possible that the WMI service is experiencing problems on either your local computer or on the remote computer. However, that is usually not the case. Instead, problems connecting to a remote computer typically revolve around one of the following scenarios:

  • The remote computer is not online. Sometimes the simplest explanation is the best: if a computer is offline you won’t be able to connect to it using WMI (or using much of anything, for that matter). If you are getting a “Remote server machine does not exist or is unavailable” error the first thing you should do is verify that the computer is actually online; you can do this by trying to ping the remote machine, or by trying to connect to it using a command-line or GUI tool. Difficulties with the network tend to be more common than difficulties with the WMI service; because of that, you should investigate problems with the network before investigating problems with WMI.

  • You do not have local Administrator rights on the remote computer. As a regular user (that is, a non-Administrator) you have limited ability to run WMI scripts on the local computer; typically you will be able to retrieve information using WMI but will not be able to use WMI to change settings. This is not the case when connecting to a remote computer: in order to use WMI remotely, you must have local Administrator rights on the remote machine. If you do not, access to that computer will be denied.
    Ok, so maybe that isn’t entirely true: it’s possible for you to be granted access to a WMI namespace even if you aren’t a local Administrator. (This is rarely done, but it’s possible.) You can check namespace security by right-clicking the My Computer icon and selecting Manage. In Computer Management, expand Services and Applications, right-click WMI Control and then click Properties. Information about namespace security can be found on the Security tab in the WMI Control Properties dialog box.
    You can find additional information about setting WMI security in this Knowledge Base article.

  • A firewall is blocking access to the remote computer. WMI uses the DCOM (Distributed COM) and RPC (Remote Procedure Call) protocols to traverse the network. By default, many firewalls block DCOM and RPC traffic; if your firewall is blocking these protocols then your script will fail. For example, the Windows Firewall found in Microsoft Windows XP Service Pack 2 is configured to automatically block all unsolicited network traffic, including DCOM and WMI: in its default configuration, the Windows Firewall will reject an incoming WMI request and give you a “Remote server machine does not exist or is unavailable” error
    If you are sure that a computer is online and you know that you have local administrator rights on that computer, then problems getting past a firewall often explain why your script is failing. We can’t tell you how to configure your firewall to permit DCOM and RPC traffic; that obviously depends on the type of firewall you have. However, if you suspect that the Windows Firewall is to blame you can find information about managing and configuring the firewall settings in the article I Married Bigfoot! Oh, and Windows Service Pack 2 Made My Computer Disappear. The WMI SDK also has additional information about connecting to the WMI service through the Windows firewall.

  • The version of WMI on your local computer is not compatible with the version of WMI on the remote computer. Unfortunately, not all versions of WMI are created equal. If you are running Windows XP or Windows Server 2003 (and assuming you have the appropriate Administrator rights and have your firewalls configured properly), you should be able to connect to any remote computer. This is not necessarily the case with older versions of Windows. For example, suppose you have Windows 2000 with Service Pack 1 installed. With this setup you will not be able to connect to a remote computer running Windows Server 2003. Instead, you must have Service Pack 2 (or a later service pack) installed in order to connect to remote machines running Windows Server 2003.
    For more information about connecting to machines running different versions of Windows, see the WMI SDK topic Connecting Between Different Operating Systems.

If you are having problems connecting to a remote computer one of the first things you should do is determine whether the problem lies with the script or with making the connection. To do that, go to the remote computer and try running the script locally (that is, start the script directly from that remote machine). If the script works your problem likely lies in making a connection and could be due to a firewall or DCOM setting. If the script does not work, that suggests a problem with the WMI service on the remote computer. In that case, try to get the script to run locally before attempting another remote connection.

You can find a fairly extensive discussion of WMI and remote machines in the WMI SDK topic Connecting to WMI on a Remote Computer.

I’m getting an 0x8004100E (“Invalid Namespace”) error

Typically invalid namespace errors are due to one of two problems. For one, you might simply have misspelled the namespace name. For example, this script tries to connect to the root\cim2v namespace; because there is no such namespace, the script fails with an 0x8004100E error:

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cim2v")

In this case, changing root\cim2v to the correct name – root\cimv2 – fixes the problem.

Alternatively, you might be trying to connect to a namespace that, while valid on some computers, does not exist on other computers. For example, the root\RSOP namespace can be found on Windows XP and Windows Server 2003, but not on Windows 2000; that means this script will fail on a machine running Windows 2000:

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\rsop")

Likewise, certain applications create their own namespaces, custom namespaces that are not part of the default installation of the operating system. If you are running the SMS client on a computer then that computer will have the root\SMSDm namespace; if a computer does not have SMS installed, however, it will not have that particular namespace. Differences in the operating system and differences in installed applications and hardware often explain why a script runs fine on Computer A yet fails with an Invalid Namespace error on Computer B.

If you receive an Invalid Namespace error you should rule out these two possibilities (a misspelled namespace name or a namespace that doesn’t exist on a particular computer) before jumping to more drastic conclusions. One easy to way to verify both the existence and the correct spelling of a namespace is to use Scriptomatic 2.0. Although the Scriptomatic utility was designed as a way to help you write simple WMI scripts, the tool can also be used to diagnose problems with the WMI service.

After downloading and installing the Scriptomatic, start the utility and wait for the WMI namespace information to load. At that point click the drop-down list labeled WMI Namespace:

This drop-down list shows all of the WMI namespaces found on the computer, making it easy for you to verify that: 1) the namespace actually exists on the machine, and 2) the namespace name has been spelled correctly.

But what if the namespace does exist, and what if you did spell the name correctly? In that case, you might try this script, which attempts to bind to the root\default namespace:

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\default")

If this script succeeds, that suggests that the WMI service is working correctly; in that case, it might be just one particular namespace that is experiencing problems. If so, you might need to recompile the MOF file for the namespace in question; for more information on recompiling MOF files see I’m getting an error regarding provider registration. If the connection to root\default fails, that suggests more serious problems. In that case, try stopping and restarting the WMI service (see I’ve verified that the namespace, class, and property names are correct, yet my script still doesn’t work) and then proceed from there.

You can also use the following command from the command prompt to try connecting to the root\default namespace:

wmic /interactive:on /namespace:\\root\default

If you receive the message “Interactive mode set” then you were able to connect to the namespace. If you receive an “Invalid namespace” message that means the connection failed.

I’m getting an 0x80041010 (“Invalid Class”) error

An error message of 0x80041010 means that you are trying to reference a WMI class that does not exist. This error typically occurs when:

  • You misspell the name of a class. For example, you try to connect to a class named Win32_Services (with an s on the end) when the actual class name is Win32_Service (without an s on the end).

  • You reference the wrong namespace. Often-times script writers connect to the root\cimv2 namespace and then try to access the StdRegProv class. Unfortunately, StdRegProv actually resides in the root\default namespace.

  • You try to access a class that is not supported by a particular operating system. For example, the SystemRestore class (found in the root\default namespace) is supported only on Windows XP. If you try to access that class on, say, a computer running Windows 2000 you will probably get an “Invalid Class” error.

Note. Instead of an error 0x80041010, you might get error 0x80041002 (“Object could not be found”) or error 0x80041006 (“Insufficient memory”) when trying to connect to a nonexistent class.

If you are getting an error regarding an invalid class, then once again it’s [Scriptomatic](https://technet.microsoft.com/en-us/scriptcenter/dd939957.aspx) to the rescue. After downloading and installing Scriptomatic, start the utility and wait for the WMI namespace information to load. When it does, click the drop-down labeled WMI Namespace and select the appropriate namespace. (For example, if your class is ostensibly in the root\wmi namespace then select root\wmi.) After the class information loads, click the WMI Class drop-down and verify whether or not the class exists and, if it does, whether or not you have spelled the name correctly:

If you do not see the class listed, then it either does not exist or is actually housed in a different namespace. You can select alternate WMI namespaces from the drop-down list as a way to browse through the entire WMI Repository and see if the class can be found.

If the class exists in the specified namespace (and if you spelled both the namespace and class names correctly) you might be experiencing more serious problems with the WMI service. In that case, you might try this script, which attempts to bind to the Win32_Process class:

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2:Win32_Process")

If this script succeeds that suggests that the WMI service is working correctly; in that case, it might be just that this one particular class that is experiencing problems. If so, you might need to recompile the MOF file for the class in question. For more information on recompiling MOF files see I’m getting an error regarding provider registration. If the connection to the Win32_Process class fails, that suggests more serious problems. In that case, try stopping and restarting the WMI service (see I’ve verified that the namespace, class, and property names are correct, yet my script still doesn’t work) and then proceed from there.

You can also run the following command from the command prompt to try connecting to the Win32_Process class:

wmic path "Win32_Process" get Name

If the connection succeeds a list of all the processes currently running on the computer will be displayed in the command window. If the connection fails you will get an “Invalid class” error.

I’m getting an error (0x800A01B6) that says a property or method is not supported

On occasion you might run a script and receive an error message similar to this:

Generally speaking this error crops up in one of two instances. In many cases you have simply typed in an incorrect property or method name; in the example shown above, we are trying to return information about a non-existent property named Namex rather than a property named Name. Use the information that appears in the dialog box when troubleshooting this problem: the dialog box will typically tell you the line of code where the error occurred (here, line 5) as well as the invalid property or method name (Namex). You can then use either the [Scriptomatic](https://technet.microsoft.com/en-us/scriptcenter/dd939957.aspx) or [Wbemtest.exe](ee692770(v=technet.10).md) to verify the actual property name.

You might also encounter this problem when working with computers running different versions of Windows. For example, on Windows XP and Windows Server 2003 the Win32_UserAccount class includes a property named LocalAccount. The Win32_UserAccount class is also found on Windows 2000; however, the version of WMI installed on Windows 2000 does not include the LocalAccount property. If you are working with different versions of Windows, use the Scriptomatic to compare the properties found on one computer with the properties found on the other computer.

Note. Suppose the two versions of WMI are different. Is there any way to upgrade Windows 2000 so that it has the same classes, properties, and methods found on Windows XP? Unfortunately, no: there is no upgrade path for WMI.

If the property name is correct but your script still fails, see the next section of this document: I’ve verified that the namespace, class, and property names are correct, yet my script still doesn’t work.

You can also type the following command from the command prompt in order to get an XML listing of all the properties and methods for a WMI class:

wmic class "win32_useraccount"

I’ve verified that the namespace, class, and property names are correct, yet my script still doesn’t work

Typically the WMI service (winmgmt) is always running: the service starts at the same time the computer starts and does not stop until the computer shuts down. The service can be stopped; however, it is designed to automatically restart any time you connect to a WMI namespace using a tool (such as Wbemtest.exe) or a WMI script.

Although unlikely, it is possible for the service to stop and then fail to restart itself when you run a script; alternatively, if you are having problems with your scripts you might be able to solve those problems by explicitly stopping and restarting the service. You should always try stopping and restarting the service before taking more drastic measures, such as rebuilding the WMI Repository.

Restarting the WMI Service

You can restart the WMI service by typing the following command from the command prompt:

net start winmgmt

If the service fails to restart or if this fails to solve your problem, try the steps listed in the following section.

Stopping and Starting the WMI Service

If you are experiencing problems with the WMI service you might need to manually stop and restart the service. Before doing so you should enable WMI’s verbose logging option. This provides additional information in the WMI error logs that might be useful in diagnosing the problem. To enable verbose logging using the WMI control, do the following:

  1. Open the Computer Management MMC snap-in and expand Services and Applications.

  2. Right-click WMI Control and click Properties.

  3. In the WMI Control Properties dialog box, on the Logging tab, select Verbose (includes extra information for Microsoft troubleshooting) and then click OK.

Alternatively, you can modify the following registry values:

  • Set HKEY_LOCAL_MACHINE\Software\Microsoft\WBEM\CIMOM\Logging to 2.

  • Set HKEY_LOCAL_MACHINE\Software\Microsoft\WBEM\CIMOM\Logging File Max Size to 4000000.

After enabling verbose logging try stopping the WMI service by typing the following at the command prompt:

net stop winmgmt

If the net stop command fails you can force the service to stop by typing this:

winmgmt /kill

Important. If you are running Windows XP or Windows Server 2003 the WMI service runs inside a process named Svchost; this process contains other services as well as WMI. Because of that, you should not try to stop Svchost; if you succeed, you’ll stop all the other services running in that process as well. Instead, use net stop winmgmt or winmgmt /kill in order to stop just the WMI service.

You can then restart the service by typing the following command:
net start winmgmt

If the service does not restart try rebooting the computer to see if that corrects the problem. If it does not, then continue reading.

I’m getting an 0x80041013 (“Provider not found”) or an 0x80041014 (“Component failed to initialize) error

To be honest, errors such as this are a bit more difficult to resolve. Error number 0x80041013 means that “COM cannot locate a provider referenced in the schema;” error number 0x80041014 means that a component (such as a WMI provider) “failed to initialize for internal reasons.” If you receive one of these two errors, you will likely need to re-register all the .DLL and .EXE files associated with WMI.

Note. If you are experiencing problems with a single class or namespace you might be able to fix the problem by re-registering only the .DLL files associated with that class or namespace. The one drawback to this approach: it’s not always obvious which .DLL files are associated with a particular namespace.

To begin with, you must re-register all the .DLL files found in the %windir%\System32\Wbem folder. Open a command window and use the cd command to change to the %windir%\System32\Wbem directory. From there, type the following at the command prompt and then press ENTER:

for %i in (*.dll) do RegSvr32 -s %i

After the .DLLs have been re-registered you will then need to re-register any .EXE files found in the Wbem folder, except for Mofcomp.exe and Wmic.exe. For example, to re-register the executable file Scrcons.exe type the following from the command prompt:

regsvr32 -s scrcons.exe

After re-registering the .EXE files try your script again. If it fails with error number 0x80041011, 0x80041012, or 0x80041085, then see the section of this document titled I’m getting an error regarding provider registration.

I’m getting an error regarding provider registration

Even after re-registering your WMI components (see I’m getting an 0x80041013 (“Provider not found”) or an 0x80041014 (“Component failed to initialize”) error) you might not be able to run your script; in particular, you might get one of the following errors:

Error Number Description
0x80041011 Provider referenced in the schema has an incorrect or incomplete registration.
0x80041012 Provider referenced in the schema does not have a corresponding registration.
0x80041085 Provider was not registered.

If you receive one of these errors you will need to recompile one or more of your .MOF files. A .MOF (Managed Object Format) file is the mechanism by which information about WMI classes is entered into the WMI Repository. It is possible that the class definitions currently in the Repository have somehow become corrupted; in that case, recompiling your .MOF files will cause those class definitions to be overwritten and replaced with the same, uncorrupted class definitions used when the operating system was originally installed.

Before you begin recompiling .MOF files note two things. First, most .MOF files can be found in the folder %windir%\System32\Wbem. However, there can be exceptions. You might want to search your hard disk for all .MOF files before beginning.

Second, there are a few applications that automatically populate the Repository during installation; these applications do not use .MOF files. If one of these applications is responsible for the problem with the WMI service (an admittedly difficult problem to diagnose) the only way to correct the class definitions in the Repository is by reinstalling the application.

The easiest way to recompile your .MOF and .MFL files (a .MOF file will often have a corresponding .MFL file which contains localized descriptions of classes, properties, and methods) is to open a command window and use the cd command to switch to the %windir%\System32\Wbem folder. From there type the following:

for %i in (*.mof, *.mfl) do Mofcomp %i

If you use a script or batch file to recompile .MOF files or if you manually call Mofcomp.exe make sure that you compile a .MOF file before you compile the corresponding .MFL file. In other words, compile items in this order:

Mofcomp.exe cimwin32.mof
Mofcomp.exe cimwin32.mfl

To be honest, it’s faster and easier to rebuild the WMI Repository than it is to recompile all the MOF and MFL files; for information on rebuilding the Repository, see the section of this document titled I have a script that I know is valid, the WMI service is running, and I’ve re-registered all the .dlls, yet my script still doesn’t work. Recompiling .MOF and .MFL files is useful if you have reason to believe that only a portion of the registry is corrupted; in that case, you can try recompiling just the affected MOF and MFL files without having to rebuild the entire Repository.

Of course, that leads to two questions. First, why not just rebuild the Repository? You can, but there are some risks involved in wiping out and replacing the Repository. For example, the WMI Repository is primarily a storehouse for meta-information about WMI itself. However, some static class data can be (and often is) stored in the Repository as well. If you rebuild the Repository all that data will be lost. (One such example: any permanent event consumers registered with the WMI service.) Admittedly, this will not cause problems for most people, but it is a possibility.

That leads us to question two: if you decide to rebuild just a portion of the Repository how do you know which MOF and MFL files to recompile? The easiest way to do that is to search the .MOF files (typically found in the folder %windir%\System32\Wbem) for the name of the class you are having difficulty with. Class names will be spelled out in the appropriate .MOF file because those files are responsible for adding information about classes to the WMI Repository.

I have a script that I know is valid, the WMI service is running, and I’ve re-registered all the .dlls, yet my script still doesn’t work

The WMI Repository (%windir%\System32\Wbem\Repository) is the database that stores meta-information and definitions for WMI classes; in some cases, the Repository also stores static class data as well. If the Repository becomes corrupted then the WMI service will not be able to function correctly. If you have tried everything else up to this point – from verifying the namespace to recompiling individual .MOF files – you might have a corrupted Repository. Fortunately, you might be able to repair the Repository; the steps you need to take to do so depend on the version of Windows you are running.

Important. Before you rebuild the Repository make sure you have tried the other remedies in this document; rebuilding the Repository should only be done as a last resort. If you are experiencing problems with the WMI service on a remote computer try your script or application locally on that machine before rebuilding the Repository; as noted earlier, network connectivity is far more likely to be the source of problems than the WMI service itself. Also, use the WMI Control to verify that permissions have been correctly set on the WMI namespaces before you resort to rebuilding the Repository.

Windows Server 2003, Service Pack 1

If you are experiencing problems on a computer running Windows Server 2003, Service Pack 1, you should first run a consistency check by typing the following from the command prompt:

rundll32 wbemupgd, CheckWMISetup

Important. The parameter CheckWMISetup is case-sensitive: it must be typed in exactly as shown. If you type in something else, say, checkwmisetup, the consistency check will fail with the message “Missing entry: checkwmisetup”.

After issuing this command, check the WMI Setup log (%windir%\System32\Wbem\Logs\Setup.log). If you see entries similar to this, then the consistency check has failed:

(Wed Oct 12 14:17:14 2005): Failing Connecting to Namespace [root\default] with result [80041002]

Note. If there are no entries for the date on which you ran Wbemupgd that means that no inconsistencies were found.

If an inconsistency is discovered, that is indicative of a corrupt Repository. You can then try to repair the Repository by typing the following command from the command prompt (again, the parameter RepairWMISetup is case-sensitive):

rundll32 wbemupgd, RepairWMISetup

If the repair command succeeds, you should see an entry similar to this in the Setup log:

(Wed Oct 12 14:21:24 2005): ERROR: wbemupgd.dll. The WMI repository has failed to upgrade.
The repository has been
backed up to C:\Windows\System32\Wbem\Repository.001 and a new one created.

If the repair fails or if your script still does not work then you will need to contact Microsoft Product Support Services.

Microsoft Windows XP, Service Pack 2

If you are running Windows XP, Service Pack 2 you can use a single command to detect and repair a corrupted WMI Repository. To do so, type the following from the command prompt (note that the parameter UpgradeRepository is case-sensitive and must be typed exactly as shown):

rundll32 wbemupgd, UpgradeRepository

After running UpgradeRepository you can verify the results by looking ay the Setup log. If inconsistencies are detected and if the operating system was able to rebuild the Repository you should see information in Setup.log similar to this:

(Wed Oct 12 13:46:36 2005): ===========================================================================
(Wed Oct 12 13:46:36 2005): Beginning WBEM Service Pack Installation
(Wed Oct 12 13:46:36 2005): Current build of wbemupgd.dll is 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)
(Wed Oct 12 13:46:36 2005): Current build of wbemcore.dll is 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)
(Wed Oct 12 13:46:52 2005): Inconsistent repository detected; it will be recreated

-
-

(Wed Oct 12 13:47:33 2005): Wbemupgd.dll Service Security upgrade succeeded (XP SP update).
(Wed Oct 12 13:47:33 2005): WBEM Service Pack Installation completed.
(Wed Oct 12 13:47:33 2005): ===========================================================================

Note. There will probably be other entries in the log as well, but you should specifically look for the ones shown above.

If the repair fails or if your script still does not work then you will need to contact Microsoft Product Support Services.

Other Versions of Windows

Only Windows Server 2003, Service Pack 1 and Windows XP, Service Pack 2 include built-in commands for rebuilding the WMI Repository. On other versions of Windows you can rebuild the Repository by doing the following:

  1. Stop the WMI service. (Type net stop winmgmt) from the command prompt.)
  2. Rename the folder %windir%\System32\Wbem\Repository. (For example, %windir%\System32\Wbem\Repository_bad.) By renaming the folder the operating system will no longer be able to find the WMI Repository. As a result, it will automatically rebuild the Repository the next time it needs to access WMI information.
  3. Restart the WMI service (net start winmgmt) and try your script again.

If your script still fails, try manually rebuilding the repository using the steps described in the section of this document titled I’m getting an error regarding provider registration.

Suppose this fixes the problem?

If your have rebuilt the Repository and your script now works, you might consider the following. Stop the WMI service and rename the current Repository folder (for example, Repository_good), then make Repository_bad the Repository once more (by renaming it back to Repository). Restart the WMI service and see if the script works. If it does not, then simply make Repository_good the WMI Repository once more.

Why would you do something like this? Well, as we noted, there are some risks inherent in rebuilding the Repository. For example, you might have applications that only update the Repository during installation; these applications do not have or use MOF files. If you rebuild the Repository then WMI data for those applications will be lost, at least until you re-install the programs. Likewise, you might have permanent event consumers or other types of data that are stored in the Repository; when the Repository is rebuilt that data will be lost. If you can use the old Repository you will save yourself from data loss like this.

I’ve rebuilt the WMI Repository and my script still doesn’t work

What if you’ve tried all the steps in this document and WMI still does not work? In that case, you will need to contact Microsoft Product Support Services (PSS). Please make sure you know:

  • The operating system on which the problem occurred.
  • The latest service pack installed on the computer.
  • Whether or not the operating system is the client or server version (e.g., Windows 2000 Professional vs. Windows 2000 Server).
  • The type of hard drive (IDE or SCSI) on which the operating system is installed.

For more information, go to https://support.microsoft.com/default.aspx.