0

I am trying to get around the old "How do I get a Windows Performance Counter for the current process" issue. Basically I am enumerating Process Object instances to get a list of Process objects that I can then query for their process id and compare to my own.

Based on this I can build a performance counter path using the correct instance index (to create something similar to \Process(my_program#3)\<counter>) that I can then use to query whatever counter it is that I am interested in. But what happens if one or more of the other instances of my_program exit prior to the PdhAddCounter call? If I understand correctly, this would mean that my counter path now refers to a different process or is now invalid. They might even disappear while querying for the process id...

How do I prevent the counter path from becoming invalid before I can use it to get a counter handle?

Community
  • 1
  • 1
villintehaspam
  • 8,540
  • 6
  • 45
  • 76
  • I'm pretty sure the path of an existing counter is not going to change. Instances may come and go and end up recycle identifiers (and thus paths), but as long as your instance lives I'm pretty sure it will have the same identifier (and thus path). I would be shocked if this were not the case. – Luke Sep 28 '11 at 14:50
  • @Luke: Unfortunately paths do become invalid. This is easily proven by opening the program in the debugger when another instance has already been started, then stepping through to allow the program to determining the correct instance (#1), then manually closing the first instance, followed by stepping again to allow the program to query the counters - they won't work. – villintehaspam Sep 28 '11 at 15:15

1 Answers1

0

Wow, you are right. This seems like a major design flaw to me. Basically it is impossible to reliably monitor an instance if it's name is not unique. I did stumble across a workaround specifically for the Process and Thread objects, but that's a global setting that could affect other applications.

I think the safest way to do this would be to watch all process objects, and each time you collect the data go through and find the one with the desired Process Id.

Luke
  • 11,211
  • 2
  • 27
  • 38
  • The workaround might affect other applications, so that won't fly as you yourself point out. Would monitoring all processes help at all? As far as I can tell, there is no way of mapping an open counter to what process it belongs to. – villintehaspam Oct 06 '11 at 14:12
  • I don't think you can do this with PdhAddCounter. Maybe you can use the registry interface to collect multiple counters for all processes; in that case I believe the counters will be stored sequentially for each object and you can figure it out from there. I may be wrong, though; I am thinking about this from the perspective of a provider which I recently implemented. Haven't ever written consumer code. – Luke Oct 06 '11 at 20:19
  • MSDN states: "You should not use the registry functions to consume counter data." – villintehaspam Oct 06 '11 at 20:52
  • That's a recommendation, not a mandate. The PDH API is more straightforward to use, but the registry API is more capable at the expense of difficulty and tediousness. – Luke Oct 07 '11 at 01:45