Detect corrupted WMI

Question

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.

Answer 1

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.

Answer 2

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}

Answer 3

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.