Thoughts from the EPS Windows Server Performance Team
Useful Microsoft Blogs
Hello AskPerf! My name is Jeffrey Worline and I wanted to let you know that I will be writing several troubleshooting WMI blog posts over the next few days. These will not be your typical Blog post, but more around the KB/Technet format.
There has been a lot of internal discussions here at Microsoft with Product Group, Developers, and myself concerning the high amount of WMI issues that have come into Support. Whenever there is an issue with WMI itself, or suspected issue with WMI, the first words that always seem to come out is that “WMI is corrupted”. Oh no, say it isn’t so. What do we do? Grab the “Big Hammer” and rebuild the repository! Excuse my humor as we have a little fun, as the upcoming blogs are going to be more straight forward and dry.
While rebuilding the repository may seem like a good idea and a quick fix at times, what most do not realize is that if you suspect WMI or repository corruption, rebuilding repository is the last thing you should do without verifying this is truly the case. Deleting and rebuilding the repository can cause damage to Windows and/or to your installed applications. That last sentence is worth repeating; “Deleting and rebuilding the repository can cause damage to Windows and/or to your installed applications.” When it becomes necessary to rebuild the repository and this has been verified, there are right and wrong ways to go about it.
Other steps should be taken first to eliminate other possibilities or to confirm we have repository corruption before taking such actions as rebuilding the repository. There are also other proactive steps that can be taken as alternatives to rebuilding the repository if such an occasion arises.
So, the following blog posts will address various scenarios surrounding WMI, how to troubleshoot them, and the data we should collect to help resolve WMI related issues. These posts will equip you with the information you need to address WMI issues in the correct manner, and to help prevent you from causing more damage by just using the proverbial “Big Hammer” approach.
With that, here is a list of the Posts/Topics you will see in the coming days:
We are also asking that you reference the following TAG if you open up a Support Incident regarding these topics.
TAG = WMITBLOG
I am super excited about this series, Jeff! Thank you for putting it together!
Isn't a shame that WMI has so many problems that it requires significant support effort? Am I the only one who sees this? I'm sure its complicated but WMI has been around for over 10 years now. It should be rock solid, I would think.
WMI: How to troubleshoot High CPU Usage by WMI Components:
Lets see if my method to troubleshoot this issue is the same like yours:
This will be very welcome as I have been continuously struggling with WMI 'out of memory' issues on our domain controllers with the SCOM 2012 AD monitors, from their 2003 incarnations to their 2008R2 replacements and now with the 2012R2 re-replacements.
Supposedly the May 2014 2012R2 update rollup fixed the WMI issues, but it was just a placebo I think and was more likely due to the reboot after patching.