More on the mysterious case of accessing .NET Performance Counters using WMI

  • Article

Back in February I blogged about a strange case we had seen where a customer was having trouble seeing certain ASP.NET performance counters when using WMI to access them. If you start Perfmon with the /WMI switch then Perfmon uses WMI rather than the native performance counter APIs to read the data. This is the same method that is used by various system monitoring tools both from Microsoft and other companies. Therefore not being able to get this data via WMI can be a significant problem.

Well, we recently had a case where after installing a new ASP.NET hotfix that we developed for our customer they could see the counters listed but the values were showing as 0 in the case of non-instance counters and no instances were listed for instance based counters.

This caused us quite a headache and we could not reproduce the issue in-house. However in the end we did find a machine on which we reproduced the issue and did manage to figure out a workaround that worked for us and in turn for the customer. However I then stopped being able to reproduce the issue so I was not able to get to the root cause. Very frustrating.

The hotfix in question is this one which (as it happens) is for an ASP.NET performance counter related issue:

FIX: "ASP.NET Apps v2.0.50727(__Total__)Sessions Active" performance counter shows an unreasonably high value after Microsoft .NET Framework 3.5 Service Pack 1 is installed

Now although this fix was in the area of ASP.NET performance counters the minor code change it involved should not have affected the registration of the counters in any way. And in fact the WMI classes that are involved in provided performance counter data via WMI are dynamically generated by the WMI infrastructure of the operating system and not ASP.NET itself. So we could see no way that the fix that was done should cause this issue with the counters.

Just to check if it was some kind of one off packaging issue we also tried a later fix package:

FIX: Error message when you run an ASP.NET 2.0 Web application if the global resource file name contains the culture name "zh-Hant"

But the customer found the same problem happened.

What we found worked in the end was a slight variation of the steps that I talked about in my previous blog post. Here are the new steps:

1. Open Wbemtest.exe
2. Connect to the rootcimv2 namespace.
3. Delete the Win32_PerfRawData_ASPNET_2050727_ASPNETAppsv2050727 class.
4. Winmgmt /resyncperf
5. Net stop winmgmt
6. Net start winmgmt

After doing this the counters had values and instances as expected when accessed via WMI.

HTH

Doug