VMware ESXi and vSphere Cluster Management

.NET Performance Tab in Process Explorer

Learn how to use Process Explorer's .NET Performance tab to inspect AppDomains and .NET Framework runtime performance counters.

The .NET Performance tab in Process Explorer shows per-AppDomain performance information for the selected process. It is useful when investigating managed .NET Framework applications and the behavior of the Common Language Runtime (CLR).

This lesson covers how to open the tab, interpret its counter groups, understand refresh behavior, and use the data to guide further troubleshooting.

What the .NET Performance tab does

Process Explorer is a Windows process-inspection utility that displays process properties and runtime information. Its general views show information such as CPU usage, memory, handles, threads, and I/O activity.

The .NET Performance tab serves a different purpose. It provides visibility into .NET Framework runtime performance data for the currently selected process, organized around the process's AppDomains and .NET performance-counter objects.

A performance counter is a runtime metric that can report a count, rate, percentage, total, or other measurement. These counters can reveal patterns such as frequent exceptions, increasing managed-memory activity, assembly loading, JIT compilation, or lock contention.

When the tab is available

Process Explorer must be running on a supported Windows environment with an applicable .NET Framework runtime, and it must be elevated with administrative rights. The selected process must also be using the .NET Framework. A process that is native, uses an unrelated runtime, or cannot be inspected may not expose this view.

Elevation means running a program with administrative privileges. To give Process Explorer the required access, start it using an account and launch method that provide administrative rights. Access may still be restricted for specially protected processes.

Why the .NET Performance tab may not be shown

Condition: Process Explorer is not elevated. Likely reason: The utility lacks permission to inspect the required runtime information. Check: Restart Process Explorer with administrative rights.

Condition: The selected process is not a .NET Framework process. Likely reason: The process is native or uses a runtime that does not provide the applicable view. Check: Confirm the executable and its runtime technology.

Condition: The operating-system or runtime environment does not support the view. Likely reason: Required Windows, .NET Framework, or compatibility conditions are absent. Check: Verify that the environment supports the Process Explorer feature.

Condition: The process cannot be fully inspected. Likely reason: Access restrictions or process protection prevent inspection. Check: Try an elevated session and compare with a process that is known to be inspectable.

Open the tab

  1. Start Process Explorer with administrative rights.
  2. Locate the managed process you want to investigate.
  3. Select the process and open its properties.
  4. Choose the .NET Performance tab if it is available.
  5. Review the AppDomain list, select the relevant performance object, and observe its counters.

The selected process matters. Counter data belongs to that process, and the selected AppDomain or performance object determines the context of the values you are viewing.

Understanding AppDomains

An AppDomain, or application domain, is an isolation boundary inside a .NET Framework process. A single process can contain one or more AppDomains.

AppDomains help separate application components for purposes including security, reliability, and assembly versioning. They also allow assemblies associated with an AppDomain to be unloaded without ending the entire process. This can be useful in hosts that load plugins or run multiple application components.

The .NET Performance tab lists the AppDomains detected in the selected process. The exact number and names depend on the application and the way it hosts managed code.

Selecting a .NET performance object

The AppDomain list provides the context for the performance display. Select an AppDomain or other listed performance object to view the counters associated with it.

Interpret every value in two contexts:

  • The selected object: The value may describe one AppDomain rather than the entire process.
  • The counter category: A memory counter, exception counter, or JIT counter measures a different type of activity and may use different units.

If an application contains several AppDomains, select each relevant object when comparing activity. A quiet AppDomain should not be used as evidence that another active AppDomain is healthy.

Refresh interval and counter meaning

The displayed values update according to Process Explorer's configured refresh interval. The refresh interval is the frequency at which Process Explorer refreshes displayed information.

  • A shorter interval makes the display more responsive during brief activity.
  • A longer interval can make broad trends easier to observe, but short-lived events may be missed.
  • Rapid updates can also make transient changes harder to interpret if readings are not recorded or compared systematically.

Do not assume that every counter is an instantaneous measurement. Depending on the individual counter, a value may be a cumulative total, an instantaneous value, a rate, or a percentage. Compare multiple readings and confirm the counter's semantics before drawing conclusions.

To change the observation behavior, configure Process Explorer's refresh interval, reproduce the workload, and compare readings across several refresh cycles.

The nine .NET runtime counter sets

The tab presents nine groups of .NET runtime performance counters. These groups represent different areas of common language runtime behavior. The exact counters and availability can vary with the installed .NET Framework or runtime version.

.NET runtime counter sets shown in the tab

Counter set: Exceptions. What it measures: Exception-related activity. Typical diagnostic use: Detect unusually frequent errors or exception-driven control flow.

Counter set: Interop. What it measures: Interaction between managed code and unmanaged components. Typical diagnostic use: Investigate native-library calls, COM interaction, or managed/unmanaged boundary activity.

Counter set: JIT. What it measures: Just-in-time compilation activity. Typical diagnostic use: Examine compilation during startup, first use, or dynamic code execution.

Counter set: Loading. What it measures: Loading of assemblies and related runtime components. Typical diagnostic use: Investigate startup delays, plugin loading, or unexpected load activity.

Counter set: LocksAndThreads. What it measures: Managed thread and synchronization-related activity. Typical diagnostic use: Look for contention or unusual thread behavior.

Counter set: Memory. What it measures: Managed-runtime memory behavior and related activity. Typical diagnostic use: Identify possible allocation pressure or unusual managed-memory trends.

Counter set: Networking. What it measures: Managed networking activity. Typical diagnostic use: Correlate runtime network behavior with application workload.

Counter set: Remoting. What it measures: .NET remoting activity where that technology is used. Typical diagnostic use: Investigate managed communication across remoting boundaries.

Counter set: Security. What it measures: Runtime security-related activity. Typical diagnostic use: Examine security checks or related managed-runtime overhead.

A practical diagnostic workflow

  1. Identify the process that owns the workload or user-visible problem.
  2. Open its properties and confirm that the .NET Performance tab is available.
  3. List the process's AppDomains and select the object associated with the workload.
  4. Choose a relevant counter group, such as Memory, Exceptions, Loading, JIT, or LocksAndThreads.
  5. Reproduce the problem while watching several refresh cycles.
  6. Record whether values remain high, increase steadily, occur in bursts, or remain unchanged.
  7. Use the pattern to choose a deeper diagnostic method, such as logs, tracing, a memory dump, or a profiler.

Counter trends can narrow an investigation toward allocation pressure, exception activity, assembly loading, lock contention, JIT compilation, or managed communication. They are symptoms and investigative clues, not proof of root cause.

Example: growing memory use

  1. Select the suspected managed process and open its properties.
  2. Confirm that the .NET Performance tab is present.
  3. Identify the active AppDomain or AppDomains.
  4. Observe the Memory counter group across several refreshes while the workload continues.
  5. If the values suggest managed-memory pressure, continue with managed-memory diagnostics or capture a memory dump as appropriate.

The tab can reveal unusual runtime memory behavior, but it does not replace a memory dump or a memory profiler. Process-level memory growth can also involve native allocations, mapped files, or other resources outside the managed heap.

Example: frequent application errors

  1. Locate the managed process and open its properties.
  2. Select each relevant AppDomain in turn.
  3. Watch the Exceptions counters across multiple refreshes while the error occurs.
  4. Compare the observed timing with application logs and user reports.

Elevated exception activity can indicate that the application is encountering frequent errors even when the process remains running. The counter does not explain why the exceptions occur, so logs and application diagnostics are needed for cause analysis.

Example: startup or plugin-loading delays

  1. Open the process properties shortly after startup or during the slow operation.
  2. Review the Loading and JIT counter groups.
  3. Observe whether activity occurs during the delay or only during normal initialization.
  4. Open the .NET Assemblies tab to correlate runtime activity with managed assemblies loaded by the process.

JIT compilation is the runtime conversion of managed code into native machine code. JIT activity can be relevant during startup, first-use operations, and extension loading. Assembly loading can likewise explain work performed when a plugin or feature is first activated.

Locating the correct process first

Correct process selection is a prerequisite for meaningful AppDomain and counter data. When a visible application window is involved, use Process Explorer's window-identification capability to identify the process associated with that window.

  1. Use the window-identification feature on the target application window.
  2. Confirm the resulting process selection.
  3. Open the selected process's properties.
  4. Continue to the .NET Performance tab if the process meets the privilege and runtime requirements.

Relationship to other Process Explorer views

Related Process Explorer views

View or feature: .NET Assemblies tab. Information provided: Managed assemblies loaded by the process. How it complements this tab: Helps correlate AppDomain and counter activity with the assemblies present in the process.

View or feature: General process performance information. Information provided: Process CPU, memory, handles, threads, and I/O activity. How it complements this tab: Shows whether managed-runtime symptoms coincide with broader process-level resource use.

View or feature: Process/window identification feature. Information provided: The process associated with a visible application window. How it complements this tab: Helps ensure that the correct process is inspected before reading AppDomains and counters.

Troubleshooting the tab

The .NET Performance tab does not appear

  • Verify that Process Explorer is running with administrative privileges.
  • Confirm that the selected executable is a managed .NET Framework process.
  • Check whether the operating-system and runtime environment support the feature.
  • Consider whether access restrictions or process protection prevent inspection.
  • Test with another known .NET Framework process to distinguish a target-specific issue from an environment issue.

No useful changes are visible

  • The application may be idle; reproduce the workload while observing the tab.
  • The refresh interval may be too long for brief activity; adjust the interval for the investigation.
  • The selected AppDomain may not own the workload; compare the relevant AppDomains.
  • The metric may be cumulative, so compare readings over time instead of looking at one value.

Counter values are difficult to interpret

  • Determine whether each metric is a total, rate, percentage, or instantaneous value.
  • Record several readings rather than treating one reading as a trend.
  • Correlate counter changes with workload timing, logs, and process-level views.
  • Use tracing, dumps, or profiling when runtime counters cannot provide sufficient detail.

Key points

  • The .NET Performance tab provides per-AppDomain visibility into .NET Framework and CLR runtime performance data.
  • It is distinct from general CPU, memory, handle, thread, and I/O views.
  • Elevation and a supported .NET Framework process are required for the tab to be useful and available.
  • Select the relevant AppDomain or performance object before interpreting counter values.
  • Use multiple refreshes and understand each counter's semantics.
  • The nine groups cover exceptions, interop, JIT, loading, locks and threads, memory, networking, remoting, and security.
  • Use the tab to narrow an investigation, then apply deeper diagnostic tools when root-cause evidence is required.