Thoughts from the EPS Windows Server Performance Team
Useful Microsoft Blogs
Good morning AskPerf blog readers! Subheet here from the Windows Performance Team. It’s been a while since I’ve written a BLOG, and am really excited about this one. This time, I’m back with our brand new, much anticipated, WMI troubleshooting tool, WMIDIAG 2.1.
The WMI Diagnosis Tool is a VBScript based-tool for testing, validating, and analyzing WMI installation/issues. The tool collects data from WMI installations on all Microsoft Operating Systems at any or no service pack level.
WMI Diagnostics 2.1 requires you to have Local Administrator rights as well as Windows Script Host (WSH) enabled.
To download this tool, please click here.
After you download WMIDiag.exe, run it and extract the files to a local folder. If you double-click WMIDiag.vbs, the following message will appear:
If you want to see its activity, then you would run “cscript WMIDiag.vbs” from the command prompt.
WMIDIAG can be run from Windows Explorer, or from the command line. Each time it runs, the WMI Diagnosis Tool creates the following three files in the %TEMP% directory:
When the WMI Diagnosis Tool terminates, the ERRORLEVEL environment variable is set to one of the following values:
0 = SUCCESS
1 = ERROR
2 = WARNING
3 = Command Line Parameter errors
4 = User Declined (Clicked the Cancel button when getting a consent prompt)
When you run the WMI Diagnosis Tool via command line:
The generated report “%TEMP%\WMIDIAG-V2.1_WIN7_.CLI.SP1.64_MYPC_2012.02.02_12.53.07-REPORT.TXT“ contains two types of figures:
WMI DIAG 2.1 FAQ:
The WMI Diagnosis Tool can be downloaded from the Microsoft Download Center at http://www.microsoft.com/download/en/details.aspx?id=7684. More information about the WMI Diagnosis Tool usage can be found in the document (WMIDiag.doc) which comes along with the download.
There is no official support for WMI Diagnosis Tool. However, feedback for the tool is welcome and can be sent to WMIDiag@microsoft.com.
The WMI Diagnosis Tool is not designed to diagnose remote computers. This is due to the fact that WMI remote access is mainly based on the WMI infrastructure. Because the aim of WMI Diagnosis Tool is to diagnose WMI, the WMI Diagnosis Tool does not use WMI to perform its core operations. That’s why the WMI Diagnosis Tool must be run locally. However, the WMI Diagnosis Tool can be deployed remotely using Group Policy, Systems Management Server (SMS), or Microsoft Operations Manager (MOM) via a Management Pack. With Windows Vista, the WMI Diagnosis Tool can also be remotely executed through WinRM/WinRS, provided you configure and enable these features (WinRM/WinRS are not enabled by default). Microsoft SysInternals tool PSEXEC.EXE can also be used.
No. The WMI Diagnosis Tool executes in read-only mode. Even though the WMI Diagnosis Tool diagnoses the situation and provides procedures to fix problems, at no time does the tool automatically fix a problem. This is by design, because the correct repair procedure depends on the context, the usage, and the list of applications installed on the computer.
I hope this new tool will help you identifying potential WMI issues in your environment. Don’t forget to read the support document (WMIDiag.doc) included in the WMIDIAG 2.1 download. Until my next post, take care!
Great tool......Like it
You said it was for MS Vista and higher, but, it seemed to run on XP SP3 just fine? Something I'm missing?
Bill, good point. I removed those lines. I was trying to state that 2.1 now officially works on Vista +, however 2.1 still works on XP/2003.
Great tool and great explanation....
This awesomely useful tool was long-awaited for Vista+ :-)
Wow, awesome tool. Great to have in my kit.
Great Job Guys.. it minimizes an admins job...I appreciate your support...
Hi Subheet, It does not work on Win 8.1, please suggest..
As @Taqui wrote, please release an update version for Win 8.1 ...
Update for 2012/2012R2?
I too am in need of a version that supports Server 2012. Really do not understand why they have to make WMI so cryptic in the first place. They have had years to implement proper error handling. Makes one wish that the group that decided to not make it
easier to diagnose WMI issues had to work for one month fixing a non-stop steam of WMI broken systems. And do it with the same tools we have, including no access to source code or WMI developers.
A quick fix to get it working for 8.1, 2012 and 2012 R2.Open the script and scroll down to line 10941. Change where is says GetOSVersion = cWindowsUnknown to say GetOSVersion = cWindows2008R2SP164 and comment out the two lines below it.You could also replace it with cWindows7SP164 or whatever makes sense for your OS.
unable to locate the 'The generated report “%TEMP%\WMIDIAG-V2.1,' as highlighted above, using XP SP3 PC, please can you attach an addendum to where we may find the resultant 'log, cvs, txt file. Thank you.
@Vijay L360: The created .LOG, .TXT, & .CSV files are located in the %TEMP% folder. If they are not there on your PC, then I might suggest capturing a Procmon log when you first run "cscript WMIDiag.vbs", and review it for where it might be storing these log files. Good luck!
it says 'The tool collects data from WMI installations on all Microsoft Operating Systems at any or no service pack level.', but running it on a Windows 2012 Failover cluster fails with 'unsupported OS version or build # - 64-Bit...
is there a version that will run on Windows 2012?