none
How to specify a PDH Counter Path using PID instead of instance index?

    Question

  • Hi, I have been using the C++ PDH API in order to get performance counters for specific processes. The AddCounter API states that an Instance Index must be included along with the process name in order to get counters for a specific process instance, like this:

    \\Computer\PerfObject(ParentInstance/ObjectInstance#InstanceIndex)\Counter

    So for example, if I have 4 instances of iexplore and I want to get counters from one particular instance, I need to specify something like this, where "2" is the Instance Index:

    \\Process(iexplore#2)\\% Processor Time

    However, the problem is that I don't know the Instance Index at the time of adding the Counter Path using PdhAddCounter(). What I know at the time of adding a path to the query is the Process ID, but the API doesn't support (or I can't figure out how) a query by PID. Is there a way of specifying a specific Process ID (instead of instance index) when adding a counter path to the query?

    Thanks in advance for your help.


    • Edited by GmanCrid Tuesday, May 29, 2018 4:50 PM
    Tuesday, May 29, 2018 4:49 PM

All replies

  • Hi,

    thanks for posting here.

    >>However, the problem is that I don't know the Instance Index at the time of adding the Counter Path using PdhAddCounter().

    As far as I know, you couldn't set the process ID when you adding a counter path to the query. The possible formats are listed as below.

    \\computer\object(parent/instance#index)\counter
    \\computer\object(parent/instance)\counter
    \\computer\object(instance#index)\counter
    \\computer\object(instance)\counter
    \\computer\object\counter
    \object(parent/instance#index)\counter
    \object(parent/instance)\counter
    \object(instance#index)\counter
    \object(instance)\counter
    \object\counter

    However, you could use PdhEnumObjectItems method to retrieve a list of counters and instances for a performance object before you call PdhAddCounter.

    For more information, please refer to this document below.

    https://msdn.microsoft.com/en-us/library/windows/desktop/aa372164(v=vs.85).aspx

    Best Regards,

    Baron Bi


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, May 30, 2018 1:50 AM
  • Hi,

    Thanks for your answer. Yes, I'm currently using the workaround you propose. I'm pulling the list of counters and instances, going through the list comparing against the relevant process and finally calling PdhAddCounter. However, this approach is very inefficient (takes several concatenated calls and comparisons) considering I need to run it all the time (i.e. for every new process created in the system). Using VS Performance Profiler, I have noticed that this workaround takes more than 55% of my entire application time/resources. Also, using a cache strategy wouldn't help here since I need to figure out instances indexes for newly created processes.

    Therefore, I was hoping I could find a more efficient way of doing this. The particular reason I believe this is important is because I'm using ETW and PDH at the same time. So while ETW works with PIDs, PDH works with instance indexes. Thus, when I need to correlate the data/events collected through both APIs, I find myself with this PID vs Instance Index inconsistency.

    Any other thought is more than welcome.

    Thanks,

    German


    Wednesday, May 30, 2018 4:01 PM
  • Maybe you can examine the next counter: “\Process(iexplore:index)\ID Process”. Increase index in a loop until you find the process by ID. Then use the found index in your other counters. This is probably more efficient, but not more reliable.


    Wednesday, May 30, 2018 5:25 PM
  • Right, that would save some time/resources - although as you said, not very reliable. I might need to add some limits and checks so I don't run into problems (i.e. if the process dies in the meantime).
    Wednesday, May 30, 2018 8:46 PM