Windows Performance Monitor (PerfMon): A Practical Guide to Counters and Logs

Updated on Oct 8, 2026

11 min read

Windows Performance Monitor, usually called PerfMon, helps Windows users and administrators turn resource activity into evidence they can analyze over time. It can display live performance counters, record them for a repeatable test, and help narrow down whether a slowdown coincides with CPU, memory, disk, or network pressure. PerfMon measures system behavior; it does not automatically optimize a PC or prove the root cause by itself.

What Is Windows Performance Monitor?

Performance Monitor is a Windows management console snap-in for viewing and collecting performance counter data. A counter is a metric exposed by Windows or an installed application, such as processor time, available memory, or bytes transferred by a network adapter. Counters can be graphed live or recorded to a log for later comparison.

Open the console by running perfmon or perfmon.msc. Its main uses are:

Live inspection: Plot selected counters while reproducing a problem.
Data Collector Sets: Record counters on a schedule or for a defined period.
Reports: Review collected data after a run.
Repeatable diagnosis: Compare the same workload across a normal and slow period.

Performance Monitor is different from Task Manager and Resource Monitor. Those tools are useful for a quick view of current activity; PerfMon is better suited to selecting counters and retaining a time series. The Microsoft perfmon command reference documents how to start the utility.

Why Use Performance Monitor?

A brief slowdown is difficult to diagnose from a single screenshot. A graph or log preserves the relationship between a symptom and the resource activity around it. This helps answer practical questions: Was the processor busy throughout the slowdown, did memory pressure build up, or did storage latency rise only when a particular operation ran?

The useful comparison is usually a representative baseline against a repeatable problem period, not a counter value against a universal threshold. Workload, hardware, virtualization, storage design, and the duration of a spike all affect interpretation. A busy processor can be normal during a batch job; a momentary queue can be harmless; and high throughput does not necessarily mean a network is healthy.

PerfMon is most useful when you already have a question to investigate. Choose a small set of counters that can help answer it, record the workload and time window, and correlate the measurements with application behavior, event logs, deployments, and other changes.

How Performance Monitor Works

Windows and installed applications expose counters through performance counter providers. PerfMon, PowerShell, and collection tools read those counters at sample intervals. The resulting samples can be graphed immediately or written to a log and reviewed later.

Typical flow: Windows or application counter provider -> PerfMon, Get-Counter, or a Data Collector Set -> sampled counter values -> live graph or .blg log -> compare with a baseline and correlate with the observed symptom.

Counters are organized into objects, instances, and counters. For example, Processor is an object, _Total is an instance representing all processors, and % Processor Time is a counter. Other instances might represent individual logical processors, disks, network adapters, or processes. Selecting the right instance matters: an aggregate can hide one saturated core or one busy device.

Some displayed values are calculated from readings over time rather than being a simple snapshot. The interval affects what a graph reveals: a long interval can smooth short spikes, while frequent sampling creates more data and some additional overhead. Use a consistent interval when comparing runs, and collect only enough counters to answer the question. Microsoft’s Windows performance counters overview explains how Windows counter providers expose this data.

Components, Counter Sets, and Alternatives

Tool or component	What it collects or displays	Best fit	Main limitation
Performance Monitor	Live charts of selected counters	Watching a focused set of metrics while reproducing a symptom	A live graph is temporary unless the data is logged
Data Collector Sets	Counter samples saved over time, commonly as `.blg` files	Scheduled collection, repeatable tests, and later review	Requires planning for sample frequency, log size, permissions, and retention
PowerShell `Get-Counter`	Counter samples that scripts can filter or export	Repeatable, finite captures and automation	Counter paths, permissions, and remote connectivity must be valid
Resource Monitor	Current per-process CPU, memory, disk, and network activity	Quickly identifying active processes and resources	Less suited to keeping a reusable time-series log
Windows Performance Recorder (WPR)	Short, detailed event-tracing captures	Investigating timing-sensitive or low-level activity beyond a counter trend	Trace files can be large and require more specialized analysis

Start with broad counters, then add per-process or per-device instances if the first capture narrows the problem. Counter names can differ with Windows language, available providers, and installed hardware. Use Get-Counter -ListSet * or the PerfMon counter browser to discover the sets available on the target computer.

Question	Useful counters to consider	Interpretation guardrail
Is CPU activity related to the slowdown?	`\Processor(_Total)\% Processor Time`, per-core `% Processor Time`, and `\Process(*)\% Processor Time`	High total usage shows the processor is busy, not which work is responsible; inspect per-core and process instances and match them to the symptom. A process value can exceed 100% when it uses multiple cores.
Is the system under memory pressure?	`\Memory\Available MBytes`, `\Memory\Pages/sec`, and `\Memory\Committed Bytes`	Low available memory alone is not proof of a problem. Interpret paging activity with the workload, commit level, and observed pauses.
Is storage delaying requests?	`\PhysicalDisk(*)\Avg. Disk sec/Read`, `Avg. Disk sec/Write`, `Current Disk Queue Length`, and `Disk Bytes/sec`	Relate latency and queues to the device, request pattern, workload, and application response; a fixed queue-length cutoff is not a general diagnosis.
Is a network adapter busy?	`\Network Interface(*)\Bytes Total/sec`	Compare traffic over the same interval with link capacity and application behavior; throughput alone does not measure end-to-end latency.

Use the instance that matches the affected resource: for example, inspect individual disks when an aggregate could hide one busy volume. Windows Performance Recorder is a separate, event-tracing tool for short, more detailed captures; see Microsoft’s Windows Performance Recorder documentation when counter trends are not detailed enough.

Real-World Use Cases

Investigating a desktop slowdown: Collect processor, memory, disk, and relevant process counters while repeating the action that feels slow. Compare the slow run with ordinary use, then investigate the resource and process whose activity aligns with the delay.
Checking a server workload: Record a representative business cycle before changing hardware or configuration. For a shared Windows Server workload, the Windows Terminal Server optimization guide provides additional session-host context.
Verifying a change: Capture the same counters and workload before and after a driver, application, or configuration change. Keep the sample interval, duration, and test conditions consistent.
Supporting a fleet investigation: Use PerfMon on a specific endpoint to gather evidence, then combine it with centralized telemetry and endpoint-management practices. Infrastructure monitoring with Prometheus covers broader monitoring, while Intune MDM for Windows devices addresses managed-device administration.

Practical Guide: Capture and Interpret Performance Data

View counters during a focused test

Run perfmon and select Performance Monitor.
Select Add Counters and browse to the relevant object, instance, and counter. Start with a few measurements tied to the symptom.
Set a sampling interval that can show the event without collecting excessive data.
Reproduce the workload and note its start and end times, along with any relevant user-visible symptom.
Compare counters that changed during the symptom with the same counters during a representative baseline. Add detail only when it helps distinguish likely causes.

Collect a finite sample with PowerShell

Get-Counter can capture a short, repeatable sample and export its values for later comparison. Run this in PowerShell on the Windows computer being investigated:

$counterPaths = @(
    '\Processor(_Total)\% Processor Time',
    '\Memory\Available MBytes'
)
$outputPath = Join-Path $env:TEMP 'perfmon-samples.csv'

Get-Counter -Counter $counterPaths -SampleInterval 5 -MaxSamples 12 |
    ForEach-Object { $_.CounterSamples } |
    Select-Object Timestamp, Path,
        @{ Name = 'Value'; Expression = { [math]::Round($_.CookedValue, 2) } } |
    Export-Csv -LiteralPath $outputPath -NoTypeInformation

Write-Output "Samples saved to $outputPath"

This requests twelve samples at five-second intervals. Counter names and paths can vary by language and installed providers; discover local counter sets with Get-Counter -ListSet * if a path is unavailable. The Microsoft Get-Counter reference describes sampling options and returned counter data. For longer or scheduled captures, create a Data Collector Set in PerfMon; the logman command reference covers command-line collection.

Log a longer or recurring investigation

In PerfMon, expand Data Collector Sets, create a set under User Defined, and choose a manual counter set. Add only the counters needed, choose an interval and output location, then start the set before the test and stop it afterward. Confirm that the account can write to the chosen directory and that the disk has room for the planned collection period.

Keep the .blg file with notes describing the machine, workload, counter instances, interval, and relevant timestamps. Review the graph or report for sustained patterns, not just the largest value. If you export or share a log, consider whether its machine and process details are sensitive.

Turn measurements into a diagnosis

First confirm that the sample window actually covers the reported slowdown. Then compare the relevant counters with a baseline and inspect more specific instances only where needed. A high CPU counter, for example, is more actionable when a process or core can be tied to the workload; a memory trend becomes more meaningful when paging and application pauses overlap.

Use logs and monitoring as evidence, not as automatic remediation. Event timestamps can explain what happened around the same time, so compare counter captures with the Windows Event Log analysis guide. For repeatable counter collection in a script, see the Windows PowerShell automation guide; for running an approved script on a schedule, use the Windows Task Scheduler automation guide.

Common Misconceptions

“A counter above a fixed number proves a bottleneck”

No single CPU, memory, disk-queue, or network threshold applies to every computer and workload. Look for a sustained change that overlaps the symptom, compare it with a representative baseline, and investigate the relevant process or device.

“A high counter identifies the root cause”

A counter describes activity, not intent or causation. A busy disk may be handling expected work, while a low-throughput disk can still be slow if requests wait on latency. Correlate measurements with the affected application, workload, event logs, and configuration changes.

“PerfMon automatically improves system performance”

PerfMon measures and records. A person or diagnostic process must interpret the results and choose a safe change, then capture data again to see whether the change helped.

“More counters and faster sampling always produce a better answer”

Collecting every available counter can make a log harder to interpret and increase its size. Very short intervals can add overhead and create noisy graphs. Begin with the smallest useful set and adjust the interval to the duration of the behavior being investigated.

“Performance Monitor and Windows Performance Recorder are interchangeable”

PerfMon samples named counters and is well suited to longer trend comparisons. WPR records event traces for detailed, usually shorter investigations. Choose the tool based on the question and the amount of detail needed.

By collecting a small, relevant set of counters around a reproducible workload, Windows Performance Monitor can replace guesswork with evidence. Interpret each value in context, compare it with a useful baseline, and verify any change with another measurement.

Windows Event Log analysis and monitoring explains how to correlate system events with performance symptoms.
Windows automation with PowerShell covers scripting and repeatable Windows administration.
Windows Task Scheduler automation explains how to schedule approved scripts and recurring checks.
Windows Terminal Server optimization discusses performance considerations for shared Windows sessions.
Infrastructure monitoring with Prometheus covers centralized metrics beyond a single Windows host.