Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When WMI is corrupted it will fail in the strangest ways, certain queries (most of them) will work, some will throw exceptions, others will time out and a few will simply return no (or partial/erroneous) results.

As I have a complicated important WMI system monitoring job I would like to be able to spot a corrupted WMI repository before I run the script. Determining it from the script behaviour is hard (due to the many ways WMI might fail) and often one can spend considerable time figuring out if its a system or WMI error.

I am essentially looking for a method tI can execute in the beginning of from my PowerShell script to determine beforehand if WMI is corrupted.

share|improve this question
up vote 4 down vote accepted

There is a script given away by Microsoft's Product Support Services team that's specifically designed to spot and diagnose corrupted WMI databases, the WMI Diagnostics Utility.

More info on how to use this at Troubleshooting WMI With WMIDiag.

Unfortunately I'm not too sure how useful this is going to be for you if you want to run this at the start of running a job, it's more the sort of thing that people tend to set to automatically run across their estate on a regular basis to report back on machines that need looking at.

share|improve this answer

One way to do it (if you set your script failure behaviour to 'ignore') would be to assign the gwmi statement to a variable, then check the variable of that variable.

$connectToWMI = gwmi win32_service -computername [computername]

then check the status or value of the variable (using write-host to see what to expect on a successful connection and a failure)

It also looks like you may be able to set Traps for error checking, but I've not used it. It goes something like this:

trap [Exception] {continue}
share|improve this answer

I don't have an answer for the specific question, but why does it matter? You get a notification from your script that it failed, and you then have to manually fix it. This notification is happening because the script failed. If you added extra code into the script to first check for corrupted WMI, the workflow would still be exactly the same.

/edit - OK - so you have different, potentially unknown ways that WMI can fail if it's corrupted? And you're asking for a single method to check if it's corrupted? Then you're SOL. I will notice that you say

"(and the afterwords spending time figuring out if it failed for important system reasons or if its simply due to corrupted WMI)"

Well, then you need better return codes and perhaps better functional design in your script. If your script isn't telling you why it failed, fix it. gWaldo has a good suggestion below about trapping. At this point, I think you'd do better to re-think what you're doing and then spend some time on StackOverflow.

share|improve this answer
I see your point and had our script been simpler I would have agreed. The problem is that we do allot of checks via WMI and it would be nice to determine up front if running them is going to be possible rather than having the script fail (and the afterwords spending time figuring out if it failed for important system reasons or if its simply due to corrupted WMI) – Lars Tackmann Oct 29 '10 at 11:46
Then find something simply to check, that will fail if WMI is corrupted. I imagine any single query would work, right? And if that fails, exit the script right then and return a different error code or message than an overall failure of the script. If you're not sure how to do that, go over to Stack Overflow. And tell them what language you're writing in, you haven't mentioned it. – mfinni Oct 29 '10 at 12:44
Unfortunately not - I have updated the question to better describe the problem with WMI. – Lars Tackmann Oct 29 '10 at 12:56
Why would this not work? In your script, run a simple query against WMI. If it fails, let you know that it failed because of corrupted WMI and don't continue any WMI actions against that machine. – mfinni Oct 29 '10 at 12:59
Check my updated question, WMI can fail in strange ways. – Lars Tackmann Oct 29 '10 at 13:05

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.