Although I still haven’t figured out how to use some of the .NET PerformanceCounter types, I’ve made some progress. I finally broke out the SDK documentation, examples, and C header files in an attempt to decipher the .NET documentation. The header file that I located (winperf.h) dates back to 1995. Comments in that file describe the performance counter registry interface in some detail, and I was able to glean some very interesting, although not terribly useful, information from that. It turns out, though, that the registry interface is only one of four (that I know of) Windows performance monitoring interfaces.
The Performance Data Helper library is a Windows DLL that wraps the registry interface to make things a bit easier for programmers who want to monitor performance data. If you’re building your own performance counters you still have to write to the registry interface. I think. The PDH library documentation is voluminous and predictably confusing. In reading through it, I found some interesting mistranslations of information from the winperf.h header file. Where the header file comments say, for example, “this counter could be used to…”, the PDH documentation says “this counter is used for…” The PDH documentation implies that the counter has built-in functionality that does not in fact exist.
Windows Management and Instrumentation (WMI) includes a performance counter interface that appears to have been intended to replace PDH, although from my reading of the documentation, PDH can interface either with WMI or with the original registry interface. Things get kind of confusing there, and if you thought the PDH documentation was large, you do not want to look at the WMI documentation. Not surprisingly, much of the information in the WMI documentation is poorly adapted from the PDH documentation, which appears to have been written by somebody who didn’t quite understand what the whole thing was about. The descriptions of using existing Windows performance counters are approachable, just barely, if you have some sample code to look at. But the descriptions of how to create your own performance counters—especially counter types that aren’t used anywhere else in Windows—are confusing, contradictory, and just plain wrong in some places. It’s a nightmare.
All of which brings us to the fourth and (for now) final version of Windows performance counters: the .NET PerformanceCounter and related classes. It’s a much simplified interface than any of the others, and using it to monitor built-in counters and to create instances of simple counters is quite nice. But, again, stepping away from the handful of common performance counter types is very difficult. Even more difficult than with WMI or the registry interface, because there is even less information on the inner workings. From looking at it more closely, I’d say that the .NET implementation talks to WMI in the background, but I can’t say for sure without a bit more research.
You know, I used to get paid for figuring stuff like this out and writing about it. I had thought, though, that things were better documented these days and the market for those skills had dried up. Perhaps it’s time to rethink that.