PromQL: Need to Correlate windows_netframework_clrmemory_gc_time_percent to Process ID (PID) for IIS Worker Process Troubleshooting

[sanjanarampurkottur01]

Current Behavior

We are monitoring the garbage collection (GC) performance of our IIS Application Pools using the windows_netframework_clrmemory_gc_time_percent metric. When an issue occurs, this metric correctly shows the problematic process instance via the process label (e.g., process=AgentService or process=w3wp#1). However, we cannot directly obtain the actual Windows Process ID (PID) of this specific instance from this metric's label set. This prevents quick correlation with OS-level tools (like Task Manager) or targeted process debugging (like taking a memory dump with procdump).

To be more specific:

The problem is that this instance name (w3wp#1) does not correspond to the actual Process ID (PID) visible in Windows Task Manager. It is an index assigned by the operating system for performance counters. Example of the problem: If the metric fires an alert for process=w3wp#1, an operator viewing the Windows Task Manager will see multiple w3wp.exe processes, but has no quick way to know which PID (e.g., 12345, 23456, or 34567) belongs to the w3wp#1 instance. This prevents immediate troubleshooting, such as:Targeting the correct process for a memory dump: (e.g., procdump -accepteula )Isolating CPU/Memory usage in Task Manager or Resource Monitor.

Expected Behavior

We expect the monitoring system to seamlessly provide the actual Windows Process ID (PID) of the IIS worker process that is reporting high GC activity.

When a performance issue is identified, the problematic process is labeled using the Windows Performance Counter Instance Name (e.g., process=w3wp#1, process=w3wp#2). We cannot reliably or immediately determine which live w3wp.exe process (PID) in Task Manager corresponds to the indexed instance name w3wp#X. This critical ambiguity blocks fast troubleshooting.Therefore, when querying the windows_netframework_clrmemory_gc_time_percent metric, the resulting time series must include a label (e.g., pid) containing the corresponding Process ID.

Steps To Reproduce

1. Enable the netframework collector in windows_exporter.

2. Run an application in an IIS Application Pool (e.g., named "MyAppPool").

3. Load the application to intentionally cause high garbage collection activity (e.g., allocating and discarding many large objects rapidly).

4. Query the problematic metric in Prometheus/Grafana:

"windows_netframework_clrmemory_gc_time_percent{process="w3wp#1"}

Environment

• windows_exporter Version: 0.20.0
• Windows Server Version: Microsoft Windows Server 2019 Datacenter (Build 17763)
• Target Application: IIS (ASP.NET/CLR)

windows_exporter logs

10/16/2025 5:20:40 PM Warning          Collection timed out, still waiting for [netframework_clrexceptions
                                       netframework_clrmemory service netframework_clrlocksandthreads]

Anything else?

No response

[mcklugchr]

Agree. We run several application pools on the same IIS installation, and it makes it very hard to map metrics to app. pool in an easy to grasp way

[jmisaxobank]

The name of the IIS Application Pool is also extremely helpful to know, as this is the logical name of the application that each w3wp.exe worker process is running.

[jkroepke]

I have some serious issues to understand the IIS world. Do I understand it correctly, the goal would be the PID label on each windows_netframework_?

Thats might be tough. I had todo research as well and I do not have a test environment. (i have only an empty IIS on a test VM).

If you have idea, how windows_exporter can get the PID info, it would be great.

Access memory region of an running process isn't a big deal. The process collector did this already.

Aside from that, the process collector have some IIS features, include expose the App Pool Name of an process. https://github.com/prometheus-community/windows_exporter/blob/master/docs/collector.process.md

(--collector.process.iis) Could you explain, why this wont help here?

[jmisaxobank]

The reason we need the counters from the ".NET CLR *" categories (windows_netframework_) is that they contain information about memory managed by the CLR, including the size of the Gen 0/1/2 heaps and the large objects, and the number of promotions from one heap to another.

Having the PID label would be great, what would be even greater would be to have a label with the name of the application pool. (Specific for the "w3wp#<number>" instances.) The PID will change whenever the application pool is restarted, but the name will remain the same, so we can make long-term comparisons of how an application pool evolves over time.

I know of three different methods for getting the PID, but have ever only used the first one myself.

Method 1: The ".NET CLR Memory" category includes a counter (a gauge really) for exposing the Process ID.
See https://learn.microsoft.com/en-us/dotnet/framework/debug-trace-profile/performance-counters#memory-performance-counters.

Method 2: The "Process" category (not the V2 one) uses a similar "w3wp#<number>" naming and includes a counter called "ID Process" which is the PID.

Method 3: Set the registry value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PerfProc\Performance\ProcessNameFormat to the DWORD value of 2. This will change the naming of the instances to "w3wp_<pid>", but it is a global setting on the machine so it might interfere with other tools depending on the exact format.
See https://learn.microsoft.com/en-us/windows/win32/perfctrs/handling-duplicate-instance-names.