Process Explorer course

Using the .NET Performance Tab in Process Explorer

Learn how to use Process Explorer's .NET Performance tab to inspect AppDomains, CLR performance counters, managed runtime activity, and troubleshooting data.

Process Explorer's .NET Performance tab exposes managed-runtime performance information for the currently selected process. It organizes information around .NET performance objects and AppDomains, rather than only showing operating-system metrics such as CPU, memory, disk, or network usage.

This view is especially useful when a single managed process hosts several applications, plug-ins, or components. It can show activity involving exceptions, garbage collection, JIT compilation, assembly loading, threads, locks, networking, and other CLR services.

What the .NET Performance Tab Shows

The Common Language Runtime (CLR) is the execution environment that provides services such as garbage collection, JIT compilation, exception handling, and managed thread support. The .NET Performance tab exposes performance-counter data produced by that runtime for the selected process.

A performance counter is a measured value, such as a count, total, percentage, or rate. A performance object is a logical grouping or instance that exposes related counters. In this tab, you select an AppDomain and a performance object, then inspect the associated counter names and current values.

This is different from Process Explorer's general process views. The normal process list and other property tabs help you examine operating-system-level behavior, including CPU consumption, working-set memory, handles, threads, network connections, and loaded modules. The .NET Performance tab instead focuses on managed-runtime activity within the process.

When the Tab Is Available

The tab applies to processes using the .NET Framework, Microsoft's managed runtime platform targeted by this historical functionality. Under the described Process Explorer behavior, the feature is available on Windows Vista and later systems when Process Explorer is running with administrative rights.

Requirement — Why It Matters — What Happens If Missing

Windows Vista or later — The tab's supported operating-system behavior begins with these systems — The tab may not be available on older Windows versions.

Process Explorer running elevated — Administrative access is needed to inspect eligible managed processes and their runtime data — The .NET Performance tab may not appear.

Selected process uses the .NET Framework — The counters describe CLR-managed execution — Unmanaged processes do not expose this view.

Accessible runtime performance-counter information — Process Explorer needs the relevant registered runtime data — Some counters or values may be absent.

Elevation means running Process Explorer with administrative privileges. Start it using an administrative account or choose Run as administrator. User Account Control may display a confirmation prompt.

An unmanaged process, or a process that does not contain a qualifying .NET Framework runtime, does not expose this tab. A process that merely has a similar name to a managed application is not sufficient; verify that you selected the actual managed process.

Opening the Tab

  1. Select the target process in the Process Explorer process list.
  2. Open the selected process's properties window. You can use the process context menu or the appropriate properties command.
  3. Choose the .NET Performance tab.
  4. Verify that the selected process is the managed application of interest before interpreting its values.

If the application launches helper processes, services, or worker processes, inspect each relevant process. The process containing the user interface may not be the process doing the managed work you are investigating.

For background on opening a properties dialog, see Process Properties. If elevation is unfamiliar, see Run As Administrator.

Understanding AppDomains

An AppDomain is a .NET Framework execution and isolation boundary inside a process. It can separate loaded code and configuration boundaries while allowing multiple managed applications or components to run in one operating-system process.

AppDomains support several runtime goals:

  • Isolation: code and configuration can be separated from other hosted components.
  • Security: older .NET Framework hosting models could apply different security boundaries.
  • Reliability: a host can isolate components so that failures or unloading operations are more contained.
  • Assembly versioning: components with different assembly versions can sometimes coexist in separate domains.
  • Unloading: an AppDomain can be unloaded, which provides a way to remove its loaded assemblies without unloading the entire process.

One process can host more than one AppDomain. This makes AppDomain-level inspection useful for services, plug-in hosts, test runners, web applications, and other programs that load multiple managed applications or components.

Selecting Objects and Reading Counters

  1. Review the AppDomain entries shown for the selected process.
  2. Select the AppDomain relevant to the workload you are examining.
  3. Select a listed .NET performance object.
  4. Read the associated counter names and current values.
  5. Repeat the observation during representative application activity.

Process Explorer refreshes displayed values according to its configured refresh interval, the time between measurement updates. A shorter interval can make brief activity easier to see; a longer interval can make broad trends easier to follow.

Do not interpret a rate-based counter from one sample. Observe several refresh cycles and compare the values with the workload, timestamps, CPU use, memory behavior, and application response time. A cumulative counter may increase only when a particular event occurs, while a rate may require multiple samples before its meaning is clear.

Use Process Explorer's refresh settings to choose an interval suitable for the test. Short intervals can increase observational detail, but they may also produce more transient readings and more data to interpret.

CLR Performance-Counter Categories

The tab represents CLR performance-counter groups. The exact counters available, and their usefulness, can vary with the installed .NET Framework version and the runtime features used by the process.

Category — What It Measures — Typical Investigation Use

Exceptions — Exception activity, including the rate at which exceptions are thrown — Investigate error-driven control flow, unexpected failures, or high exception activity.

Interop — Communication between managed code and unmanaged code or COM components, including platform invocation behavior — Examine native boundaries and managed-to-unmanaged overhead.

JIT — Just-in-time compilation of intermediate-language methods into native machine code and related compilation activity — Investigate startup or dynamic-loading compilation cost.

Loading — Assembly, class, and AppDomain loading or unloading activity — Examine initialization, add-in loading, and dynamic assembly behavior.

Locks and Threads — Managed thread counts, synchronization, contention, and lock-related behavior — Investigate thread growth, blocked work, and synchronization bottlenecks.

Memory — Garbage collection, managed heap usage, allocation activity, and generation-related metrics — Investigate allocation pressure and possible retention problems.

Networking — Managed network activity generated through relevant .NET networking components — Correlate managed network use with request or service activity.

Remoting — Legacy .NET Remoting activity where that technology is used — Examine older distributed managed applications.

Security — Runtime security checks and related managed security activity — Investigate security-related runtime overhead in applicable applications.

Exceptions

An elevated exception rate can indicate expensive error-driven control flow, especially if exceptions occur during normal successful work. It is not automatically proof of a defect: some applications intentionally use exceptions for boundary conditions or expected operations. Compare the rate with logs, workload phases, CPU usage, and response delays.

Interop

Interop is communication between managed .NET code and unmanaged code, including COM components and native functions called through platform invocation. Activity here can help identify work crossing the managed/native boundary, but it does not by itself show which native function is responsible.

JIT

JIT compilation converts intermediate-language methods into native machine code during execution. High JIT activity during startup, plug-in discovery, or dynamic loading can contribute to startup overhead. A burst during initialization may be normal; sustained activity during steady-state work deserves further investigation.

Loading

Loading counters help show assembly, class, and AppDomain activity. They are useful when an application initializes add-ins, loads assemblies dynamically, or repeatedly creates and unloads domains. Correlate unusual loading activity with the .NET Assemblies tab and application startup timing.

Locks and Threads

These counters can reveal managed thread growth, synchronization activity, and lock contention. Lock contention is delay caused when multiple threads compete for the same synchronization resource. High contention or unexpected thread growth can indicate a bottleneck, but the counters do not identify the exact source line.

Memory

The managed heap is memory managed by the CLR garbage collector. Garbage collection reclaims memory occupied by objects that are no longer reachable. Increasing allocation activity, frequent collections, or growing managed-memory measurements can indicate allocation pressure or possible retention. These observations do not identify object types or retention roots; use a profiler for that level of detail.

Networking

Networking counters describe activity produced through relevant managed .NET networking components. Use them with request rates, network connection views, timestamps, and application logs. They are not a complete replacement for Process Explorer's operating-system network views or packet-level tools.

Remoting

.NET Remoting is a legacy communication technology. Remoting counters are relevant only when the application uses that technology. Empty or unavailable Remoting data is not evidence of a problem in an application that uses another communication mechanism.

Security

Security counters represent applicable runtime security checks and related managed activity. Their meaning depends heavily on the .NET Framework version, application configuration, and security features in use.

Interpreting the Data in Context

Use the tab to form a performance hypothesis, not to declare a root cause from one value. A useful investigation compares counter changes with a known workload and with other process details.

  • Frequent exceptions may indicate expensive error handling or an unusual input condition. Confirm the pattern in application logs or a debugger.
  • Growing managed-memory and garbage-collection activity may indicate allocation pressure or retained objects. Additional profiling is needed to identify the objects involved.
  • High JIT activity during startup or dynamic loading may explain part of startup-time overhead.
  • Lock contention and thread growth may point to synchronization bottlenecks or thread-management issues.
  • Loading activity may correspond to initialization, add-in loading, or dynamic assembly behavior.
  • Counter changes should be correlated with workload, timestamps, CPU use, memory use, response delays, and other Process Explorer process details.

Practical Investigation Examples

Investigating Frequent Managed Exceptions

  1. Select the affected managed process and open its properties.
  2. Open the .NET Performance tab and select the Exceptions performance object.
  3. Reproduce the workload and watch exception-related counters across several refresh cycles.
  4. Compare periods of high exception activity with CPU usage and application response delays.

A sustained increase identifies a workload period worth investigating in application logs or a debugger. It does not, by itself, prove that every exception represents an application failure.

Checking Allocation and Garbage-Collection Pressure

  1. Select the relevant AppDomain and choose the Memory performance object.
  2. Observe managed-memory and garbage-collection counters while the application is idle.
  3. Repeat the observation during an active workload.
  4. Look for increasing allocation-related activity or repeated collections that coincide with degraded responsiveness.

The counters can indicate memory pressure, but a managed profiler is needed to identify object types, allocation sites, or retention roots.

Diagnosing Slow Startup

  1. Start or restart the managed application.
  2. Observe the JIT and Loading performance objects during startup.
  3. Use the .NET Assemblies tab to inspect assemblies loaded by the process.
  4. Compare loading and JIT activity with the period when the application is unresponsive.

Heavy assembly loading or compilation can contribute to startup cost. Confirm the relationship with timing data rather than assuming that either category is the sole cause.

Investigating a Busy Multithreaded Service

  1. Select the service process and locate its AppDomain entries.
  2. Inspect Locks and Threads counters while the service is under load.
  3. Compare thread counts and contention indicators with throughput, CPU usage, and response time.

This can establish whether managed synchronization or thread behavior merits deeper analysis with tracing, a debugger, or a profiler.

.NET Assemblies Versus .NET Performance

The two tabs answer different questions. The .NET Assemblies tab is used to inspect assemblies loaded by the managed process. The .NET Performance tab is used to inspect runtime counter data and AppDomain-oriented activity.

Question — .NET Assemblies Tab — .NET Performance Tab

Which managed assemblies are loaded? — Shows loaded assembly information — Not its primary purpose.

Which AppDomains are present? — Provides supporting assembly context — Organizes performance inspection around AppDomains.

Is managed runtime activity changing under load? — Not its primary purpose — Shows applicable CLR counter values and trends.

Is assembly loading or JIT activity associated with startup? — Identifies assemblies involved — Shows Loading and JIT activity to correlate with startup timing.

For example, if the Loading object shows activity during startup, use the assemblies view to see which assemblies were loaded and whether the timing matches the application's initialization period. The two views complement one another: one describes loaded code, while the other describes runtime activity.

Troubleshooting a Missing or Incomplete View

The .NET Performance Tab Is Missing

  • Process Explorer may not be elevated.
  • The selected process may not use the .NET Framework.
  • The operating system or runtime environment may not meet the tab's historical requirements.
  • Required performance-counter data may be unavailable.
  1. Restart Process Explorer with administrative rights.
  2. Confirm that the selected executable is a managed .NET Framework process.
  3. Check the .NET Assemblies tab as supporting evidence that managed assemblies are loaded.
  4. If the application launches multiple processes, select the correct child or host process.

Expected Counters or Values Are Absent

The runtime feature represented by a category may not be in use. Counter sets can also differ by .NET Framework version, and runtime performance counters may be unavailable or malfunctioning. Select each listed AppDomain and applicable performance object, then generate representative activity and observe multiple refreshes.

Treat an unavailable category as an environment or runtime-support issue, not as proof that the application has no activity.

Values Appear Unchanged

  • The workload may be idle.
  • The refresh interval may be too long for a short-lived event.
  • The counter may be cumulative or may change only when a particular runtime event occurs.

Exercise the application while observing the tab, use a shorter refresh interval when appropriate, and compare trends or deltas over time. Do not expect every counter to change on every refresh.

A High Value Has No Clear Cause

A counter is generally an aggregate symptom rather than source-level attribution. A high value may also be normal for the current workload. Correlate it with CPU utilization, memory behavior, logs, timing, and application activity. Use a managed profiler, debugger, tracing tool, or application instrumentation for root-cause analysis.

Limitations and Diagnostic Scope

  • These counters are primarily .NET Framework-era diagnostics and should not be assumed to cover all modern .NET runtimes.
  • Counters are indicators, not complete call traces, allocation stacks, or proof of a root cause.
  • Permissions, runtime support, counter registration, and process architecture can affect visibility.
  • Counter usefulness depends on which runtime features and libraries the application actually uses.
  • Values should be interpreted over time and in relation to a controlled workload.

Exam-Relevant Notes

  • The .NET Performance tab is for managed-runtime performance information, not general process CPU, memory, disk, or network metrics.
  • It is associated with .NET Framework processes and, under the described behavior, requires Windows Vista or later and an elevated Process Explorer instance.
  • An AppDomain is a .NET Framework execution and isolation boundary inside a process; one process can contain multiple AppDomains.
  • Selecting a performance object reveals its associated counters and current values.
  • Rate-based counters should be observed over multiple refresh cycles.
  • The main categories are Exceptions, Interop, JIT, Loading, Locks and Threads, Memory, Networking, Remoting, and Security.
  • The .NET Assemblies tab shows loaded assemblies; the .NET Performance tab shows runtime counter activity.
  • Counter readings guide further investigation but do not replace profiling, tracing, debugging, or application instrumentation.

For related Process Explorer views, see Performance Tab, Threads Tab, and Process Properties.