Understanding the Performance Tab in Process Explorer
Learn how to interpret CPU, memory, priority, I/O, and handle metrics for an individual process in Process Explorer.
What the Performance tab shows
The Performance tab presents performance-related statistics for one selected process. It helps you examine that process's CPU execution, memory consumption, scheduling priorities, I/O priority, and kernel-object handle usage.
These are primarily per-process values. They do not replace system-wide information such as total CPU utilization, available physical memory, disk activity, or overall system responsiveness. Use the process values to identify how one process behaves, then compare them with broader system evidence.
Opening the Performance tab
- Select the process you want to investigate in Process Explorer.
- Open the process's properties dialog.
- Select the Performance tab.
The displayed figures refresh according to the configured Process Explorer refresh interval, which is the period between information updates. A shorter interval can make changes easier to observe, while a longer interval can make slower trends easier to review.
For broader navigation guidance, see Process Properties and the Process Explorer Course.
Performance tab metrics at a glance
| Metric | What it represents | How to interpret it | Common investigation use |
|---|---|---|---|
| CPU Priority | A scheduling priority value for the process | Higher values can make the process more eligible for CPU time when processor demand is contested | Understanding scheduling context for CPU contention |
| Kernel Time | Accumulated processor time spent in kernel mode for the process | Shows execution performed by the operating system or drivers on the process's behalf | Separating kernel-mediated work from application computation |
| User Time | Accumulated processor time spent in user mode for the process | Shows execution of application code in user mode | Characterizing application computation |
| Private Bytes | Committed memory reserved for the process's exclusive use | Indicates private committed allocation, not the amount currently resident in physical RAM | Investigating memory growth and possible leaks |
| Peak Private Bytes | The highest private committed-memory amount reached since process start | Provides lifetime context for the current Private Bytes value | Comparing retained memory with temporary allocation |
| Memory Priority | The default priority associated with the process's physical memory pages | Provides context for which pages are favored or reclaimed under memory pressure | Understanding behavior during physical-memory contention |
| I/O Priority | The process priority used during I/O scheduling | Can influence how disk and other I/O requests are treated during contention; it is not throughput | Understanding responsiveness during I/O competition |
| Handles | References held by the process to kernel objects | A high or rising count can be evidence of a resource leak, but a high count alone is not necessarily abnormal | Investigating leaked files, events, mutexes, threads, or other objects |
CPU Priority
CPU Priority is a scheduling-related value that affects how readily a process receives processor time relative to competing work. The documented numeric levels span 0 through 31, where 0 is the lowest level and 31 is the highest.
When CPU demand is contested, a higher-priority process can receive more CPU time than lower-priority competing work. This does not guarantee constant CPU use. A process may still be waiting for I/O, blocked on a lock, waiting for another process, or simply have little work to perform.
Kernel Time and User Time
Kernel mode is the privileged execution mode used by Windows and drivers. User mode is the restricted execution mode in which ordinary application code runs.
Kernel Time is the accumulated processor execution time spent in kernel mode on behalf of the process. This can include operating-system services, driver work, device operations, and file or network activity associated with the process.
User Time is the accumulated processor execution time spent running the process's application code in user mode.
Both values are accumulated execution-time measures. They are not direct instantaneous CPU-percentage readings. To understand recent CPU behavior, observe how the values change across several refreshes or over a defined test interval.
Comparing the two can help characterize a workload. A predominance of User Time suggests more execution in application code. Substantial Kernel Time suggests that operating-system services, drivers, file operations, network operations, or device activity may be contributing significantly. Neither comparison identifies a root cause by itself.
Private Bytes
Private Bytes is committed memory allocated for the process's exclusive use. This committed private memory cannot be shared with other processes.
Committed memory is memory for which Windows has committed backing resources. Private Bytes is different from the process's current physical RAM residency: private memory may not all be resident in RAM at the instant you observe it, and the value does not directly tell you how much physical memory is currently being used.
A sustained rise in Private Bytes can be a useful sign of a possible memory leak or uncontrolled memory growth. Treat it as an investigation signal rather than proof. Some applications intentionally retain memory for caching or reuse.
Peak Private Bytes
Peak Private Bytes is the highest private committed-memory amount observed for the process since it started. It supplies historical context for the current Private Bytes value.
- If current Private Bytes is close to the peak, much of the process's maximum private allocation remains allocated.
- If current Private Bytes is well below the peak, the process may have released private committed memory after a temporary workload.
- If repeated workloads push both current and peak values upward, investigate whether memory is intentionally cached or improperly retained.
The peak is associated with the lifetime of that process instance. Restarting the process begins a new observation history.
Memory Priority
Memory Priority is the default priority assigned to physical memory pages used by the process. At a high level, it influences which pages are favored or reclaimed when the system is under physical-memory pressure.
Memory Priority is not a measure of memory quantity, memory speed, or CPU scheduling priority. Use Private Bytes and other memory measurements to assess allocation, and use Memory Priority as context for paging and reclamation behavior.
I/O Priority
I/O Priority is the priority applied to a process's input/output work when Windows schedules I/O activity. It can influence how disk and other I/O requests are treated when multiple sources compete for access.
I/O Priority is distinct from CPU Priority. CPU Priority concerns processor scheduling; I/O Priority concerns I/O scheduling. Neither value is the same as total I/O throughput. A process can have high I/O priority but low throughput if it is waiting on a remote service, blocked by storage latency, issuing little work, or limited by another part of the application.
Handles
A handle is a process-owned reference to an operating-system kernel object. Handles can refer to files, registry keys, events, mutexes, processes, threads, tokens, and many other system objects.
The Handles value is a count of references currently held by the process. A high count is not automatically a problem because legitimate applications may use many objects. A count that continuously increases during repeated normal operations, without returning toward a baseline, can indicate a resource leak.
When investigating a suspected leak, correlate handle growth with the action being repeated and with process behavior. Use additional Process Explorer resource-inspection views to identify the object types involved before drawing a conclusion.
Current, cumulative, and peak values
| Value type | Metrics | Interpretation caution |
|---|---|---|
| Cumulative | Kernel Time and User Time | These grow as the process executes and are not instantaneous CPU-utilization readings. |
| Current allocation or state | Private Bytes, priority settings, and Handles | Interpret them with the refresh interval and the workload occurring at the time of observation. |
| Peak lifetime value | Peak Private Bytes | This is the maximum reached since process launch, not necessarily current memory use. |
Accumulated times and peak values retain history for the lifetime of the process. Other displayed information, such as current allocation and priority settings, should generally be interpreted as the process's present state at the latest refresh.
Reading values over time
Do not base a diagnosis on one sample. Observe several refreshes, preferably while the process performs a repeatable workload and while it is idle afterward.
- Record an initial baseline.
- Repeat the action that causes the reported problem.
- Watch CPU-related times, Private Bytes, Peak Private Bytes, priorities, and Handles across multiple updates.
- Allow the workload to finish and check whether current values return toward an expected baseline.
- Correlate the pattern with system-wide CPU, memory, storage, network, and application evidence.
A time-based process graph or other performance visualization can make CPU activity and memory trends easier to compare with refresh updates. The key principle is to interpret direction and rate of change, not only the latest number.
Practical diagnostic interpretation
When a process appears CPU-intensive
- Open its properties and review CPU Priority, Kernel Time, and User Time.
- Observe the time values across a defined interval rather than treating their totals as current CPU percentage.
- Compare the change in User Time with the change in Kernel Time.
- Treat a predominance of User Time as evidence of more application-code execution.
- Treat substantial Kernel Time as a reason to investigate operating-system, driver, file, network, or device activity.
If the process is slow despite a high CPU priority, the bottleneck may instead be memory pressure, I/O, lock contention, external-service latency, or an application-level limitation. Avoid increasing priority further without identifying the bottleneck.
When investigating memory growth
- Record Private Bytes and Peak Private Bytes while the process is idle.
- Run the workload suspected of causing growth.
- Check whether current Private Bytes declines after the workload completes.
- Repeat the workload and compare the new values with the earlier baseline.
If Private Bytes rises after every repeated operation and does not return toward a baseline, the process may be retaining private committed memory or leaking memory. If current Private Bytes is substantially below Peak Private Bytes after the workload, some temporary allocation was released. If current and peak values remain close after repeated workloads, investigate whether the retained memory is intentional caching or improper retention.
When investigating a suspected resource leak
- Establish a Handles baseline shortly after startup or before the test action.
- Repeat the action suspected of leaking resources.
- Watch for a handle count that rises repeatedly without declining toward its earlier baseline.
- Inspect handle types with appropriate Process Explorer views.
Handle growth supports a resource-leak investigation, but it does not identify the cause by itself. Examine the types of objects and correlate them with the application's behavior.
When responsiveness is poor during contention
Review CPU Priority, Memory Priority, and I/O Priority as contextual settings. Then determine whether the system is primarily experiencing CPU competition, physical-memory pressure, or I/O contention using broader evidence. These priorities help explain scheduling context; they are not universal performance controls.
Troubleshooting patterns
| Symptom | Likely interpretation | Next checks |
|---|---|---|
| Private Bytes rises after every repeated operation | The process may be retaining private committed memory or leaking memory | Compare current and peak values after the workload, repeat the test, and correlate the pattern with application actions and system memory pressure |
| Handle count increases continuously during normal use | The process may be leaking references to kernel objects | Establish a startup baseline, repeat the triggering action, and inspect handle types |
| CPU use is high and User Time is not the only large accumulated value | The workload may include substantial kernel-mode activity | Compare Kernel Time and User Time over a defined interval; investigate file, network, driver, and device activity as appropriate |
| The application is slow despite high CPU priority | The bottleneck may be memory, I/O, lock contention, external latency, or application behavior | Review memory and I/O context, check system CPU contention, and avoid increasing priority without evidence |
Exam-relevant distinctions
- Private Bytes is not physical RAM residency: it describes committed private allocation, not the process's current resident memory.
- Peak Private Bytes is historical: it records the maximum since process start.
- Kernel Time and User Time are accumulated: neither is an instantaneous CPU percentage.
- CPU Priority and I/O Priority are different: one concerns processor scheduling and the other concerns I/O scheduling.
- Memory Priority is not memory size: it describes page-priority behavior under memory pressure.
- A high handle count is not automatically a leak: a continuously rising count correlated with repeated activity is stronger evidence.
- Per-process metrics are not system-wide metrics: use system information and other monitoring views to understand contention outside the selected process.