Performance counters - pretty straight forward

The System Monitor is an important feature in Windows. It allows administrators to monitor various types of activity on machines to gauge performance and receive alerts when something is off. Windows comes with a set of base counters and applications can add their own counters to the mix through the LODCTR/UNLODCTR utilities or the LOADPERF API set.

You can find the base counters in a few files in %SystemRoot%\system32. The files are called perfcNNN.dat, perfdNNN.dat, perfhNNN.dat, and perfiNNN.dat. NNN represents the language of the file, so if you have a localized system you have two of each (e.g. perfc409.dat and perfc41d.dat). Perfc and perfd contain the display names of a bunch of counters, and perfh and perfi contain the corresponding descriptions. Perfc & perfd and perfh & perfi are initially identical, but during Windows setup and as you install application, perfc and perfh are updated. Perfd and perfi are used for servicing, so when you install a new Service pack, the base counters in perfc and perfh are replaced with the information in the updated perfd and perfi. As far as I'm concerned, perfd and perfi are not an issue. I just localize perfc and perfh.

All in all, you have about 600 base counters. They have helpful names such as "Demand Zero Faults/sec", "Pool Nonpaged Allocs", and "Sync Pin Reads/sec". As you can imagine, these names aren't always easy to translate - not only are they often cryptic to begin with, but ideally, whatever I come up with for translation should be well readable in this dialog box:

(Note to self: make the controls in this dialog wider in Longhorn)

The most important thing to keep in mind when translating performance counters is to never give two resources with different source the same translation. I have seen cases where this has been done (for sound linguistical reasons), but this has lead to bugs where the localized build contains too few entries - the second occurrence of the duplicated counter name is simply not shown. Luckily, it's fairly easy to make sure you haven't made this mistake - all you need is a reverse inconsistency check.

I mentioned that the counters typically have descriptions. The base counters often have pretty long descriptions, such as:

Pages/sec is the rate at which pages are read from or written to disk to resolve hard page faults. This counter is a primary indicator of the kinds of faults that cause system-wide delays.  It is the sum of Memory\\Pages Input/sec and Memory\\Pages Output/sec.  It is counted in numbers of pages, so it can be compared to other counts of pages, such as Memory\\Page Faults/sec, without conversion. It includes pages retrieved to satisfy faults in the file system cache (usually requested by applications) non-cached mapped memory files.

What's worth noting here is that this description contains names of other counters. This is similar to MFL files and ADM files, so if you're clever enough you can create a check that covers this issue in all three file types.

Apart from these points, localizing performance counters is pretty straight forward.

Note to developers - if you ever find yourself writing code that contains hard-coded counter names, you're writing broken code. Your code won't work across different language versions of Windows, and it might not even work on the same language across Service Packs. I can at any point decide to change my translations. Yup, I'm flexible like that.

This posting is provided "AS IS" with no warranties, and confers no rights.