I just found out the following, which does not seem to be documented anywhere:

The Windows API has a function for displaying a dialog that lets the user select a specific performance counter from all counters available on the local or a remote computer. The dialog is used by perfmon.exe, for example, and looks like this:

This dialog is instantiated by calling the API function PdhBrowseCounters. This works well enough – the dialog displays all objects, counters and instances, the user is able to select a specific counter and clicks on “OK”.

The bad thing is that PdhBrowseCounters always returns an empty string instead of the counter path selected by the user. This happens if the application does not run elevated (i.e. with admin rights).

I have two problems with that:

It is documented nowhere that elevation is required for PdhBrowseCounters.

Why is elevation necessary? The user can see all objects, counters and their instances without elevation, so why not return the path selected?

For theses reasons I think this is a bug.

By the way, how does perfmon.exe work around this? It doesn’t. It requires elevation…

I have tested this on Windows 7 x64 German RTM with all patches till 10/27/2009.

You don’t need elevation, you can just set this flag to false and it should work:
bSingleCounterPerAdd = FALSE

Also, the flag ‘bWildCardInstances’ must ALWAYS be set to TRUE, otherwise it causes crashes in many cases. The first one would be nice to be able to use (unelevated), but you’ll just have to ignore any secondary counters that are selected if a user selects more than one.

Other bugs:
– You need to manually set the title, it no longer offers a default (NULL pointer).
– You can’t set an initial performance counter to be highlighted.
– Sometimes the Instances won’t show up on the bottom, depending on where you click on the top portion of the dialog box. This causes an invalid Counter path to be returned.
– PDH.DLL and 40 other DLL’s are loaded, and STAY loaded once PdhBrowseCounters is called. Manually unloading the DLL’s often causes crashes. This may or may not have something to do with .NET 4.0 being present.

Other general PDH bugs:
– PdhExpandWildCardPath will not recognize any new Processes (and probably other instances for other object types), unless PDH.DLL is unloaded and reloaded. This also poses a problem if you use PdhBrowseCounters, as it increases the PDH.DLL load-count by 2. Forcing an un-load may be dangerous, but seems the only option.