.NET performance counters missing when using WMI to access them
Windows Management Instrumentation (WMI) among other things exposes to WMI clients performance counters that are present on a system. This is useful because it makes performance counter data accessible to script based clients. It also offers a better way for remote clients to access performance counter data because (among other things) the “traditional” method of accessing performance counters relies on the remote registry service and can run into a variety of strange issues.
The standard performance monitoring tool PerfMon offers the option of accessing performance counter data via the WMI interface which is useful if you need to check that the counters you are interested in are being published correctly via that route. To do this just start PerfMon with the /wmi switch.
However the exposing of .NET performance counters via WMI is not without issues. Unfortunately in .NET 2.0 SP1 (which also ships as part of .NET 3.5) we introduced a bug whereby some ASP.NET counters were sometimes not available via WMI and a hotfix was produced:
This fix is also included in .NET 3.5 SP1 (which includes .NET 2.0 SP2).
Recently, I assisted my colleague Drew with a problem one of our customers had run into when installing the slipstreamed version of .NET 3.5 SP1 (that is to say, starting from a machine without a previous version of .NET present and installing 3.5 SP1 in one go). After installing this, the same symptom of missing counters when using a WMI client was present.
After much work by Drew and the customer, including having a repro environment set up in our support lab, the problem appeared to be narrowed down to a very particular “corner case” issue. What we found was that if you installed .NET 3.5 and then the fix – no problem. If you installed .NET 3.5 and then SP1 – no problem. But if you installed .NET 3.5 with SP1 as a slipstream install the counters were missing. And all this ONLY seemed to occur if all the following factors were in the mix -
OS: Windows Server 2003
Edition: R2
Bitness: x64
Hardware: dual core
And what’s more it seemed to have to be physical hardware to reproduce the issue; a virtualized environment wouldn’t do it!
If you are wondering what the “R2” edition of Windows Server 2003 is, it is a “second” release of Windows Server 2003 that added some new features, included service pack 1 out of the box and various other things. It is also one of the few (if not only) version of Windows that ships with .NET 2.0 included. Perhaps that is a factor at play in this problem.
Anyway, Drew and I were a bit stuck with this one so we had to get some help from one of the developers on the ASP.NET team to log onto the machine and take a look.
After some poking around he was able to resolve the situation on the lab machine with the following:
Winmgmt /resyncperf
Net stop winmgmt /y
Net start winmgmt
Net start ccmexec (this was a dependent service of winmgmt that was stopped as a result of stopping winmgmt)
This effectively told the WMI service to “look again” at what performance counters were available on the system and expose them via WMI. This “resynching” should have happened automatically but for some reason did not.
So far this is the only occurrence of this particular problem we have seen so I hope you never run into it but just in case, I hope this is useful.
If you are trying to follow these steps on your system be aware that you may not have a ccmexec service.
HTH
Doug