Skip to content
WindowsDeep Dive Published Updated 5 min readViews unavailable

Windows Performance Recorder and Analyzer: A Defensible Trace Workflow

Capture bounded ETW traces with WPR, preserve symbols and scenario context, then use WPA to move from a symptom interval to a testable Windows performance cause.

Windows Performance Recorder (WPR) and Windows Performance Analyzer (WPA) turn Event Tracing for Windows (ETW) data into a repeatable performance investigation. WPR records a chosen profile; WPA opens the resulting ETL file and lets an analyst correlate CPU, disk, networking, power, and application activity over the same time range. The useful result is not a large trace by itself. It is a bounded capture tied to a reproducible symptom, with enough symbols and notes to let another engineer validate the conclusion.

WPR is part of the Windows Performance Toolkit, distributed with the Windows Assessment and Deployment Kit (ADK). Built-in profiles cover common scenarios, while custom WPRP profiles can enable providers for a targeted investigation. Profiles are not interchangeable: a profile that captures stacks or detailed file I/O can create more overhead and larger files than a light timing trace. Start with the least intrusive profile that can answer the question, then expand capture detail only if the first trace is inconclusive.

Define the measurement before starting a trace

Write down the observable symptom, the exact action that reproduces it, and a success criterion. “The system is slow” is not a test. “Opening this project takes 12 seconds, and the delay occurs after the click but before the first window paints” gives the investigator a time interval and competing hypotheses. Record Windows build, hardware, power state, workload version, and whether the issue occurs on battery or AC. Capture one normal comparison run when possible; without a baseline, a busy CPU graph is not evidence that CPU saturation caused the regression.

WPR supports file and memory logging. File mode is appropriate for finite, predictable scenarios such as startup or a scripted operation and is required to capture across on/off power transitions. Memory mode uses circular buffers and is better suited to a symptom that may occur unpredictably after a longer wait. Do not leave a verbose, unbounded recording running on a production host. ETL files can contain process names, file paths, command lines, and other operationally sensitive data; handle them as diagnostic artifacts with access and retention controls.

Capture one reproducible interval

The following example records a short general performance scenario to a named ETL file. Check the installed WPR profile names on the actual host first; profiles and options may vary with the WPT version. Start and stop commands should run in an elevated terminal when the chosen providers require it.

$trace = Join-Path $env:TEMP 'incident-2026-10-03.etl'
wpr -status
wpr -start GeneralProfile -filemode
if ($LASTEXITCODE -ne 0) {
    throw "WPR could not start the requested profile (exit $LASTEXITCODE)."
}

try {
    # Reproduce one documented action here, once, and note its start/end time.
    Read-Host 'Reproduce the issue, then press Enter to stop the capture'
}
finally {
    wpr -stop $trace "single reproduction; ticket INC-0000"
    if ($LASTEXITCODE -ne 0) {
        throw "WPR did not successfully finalize the trace (exit $LASTEXITCODE)."
    }
}

Get-Item -LiteralPath $trace | Select-Object FullName, Length, LastWriteTimeUtc

This is a capture skeleton, not a recommendation to run an arbitrary profile on every workload. Use wpr -profiles and wpr -help start to inspect what the local installation supports. A stop failure can leave a session active or a partial file; inspect wpr -status, resolve the session state, and do not label the artifact complete merely because a file exists. For intermittent symptoms, choose an appropriately bounded memory recording and stop it as soon as the event is observed.

Analyze in WPA from the symptom, not from the loudest graph

Open the ETL in WPA, verify that symbols load, and set the analysis view to the timestamp interval where the symptom occurred. Begin with a high-level question: which resource was consumed, by which process and thread, during the delay? CPU Usage (Sampled) can show sampled stacks for CPU-bound work; CPU Usage (Precise) can help examine scheduling and waits when the relevant events were captured. Disk I/O and File I/O tables can distinguish slow storage completion from time spent before an I/O was issued. The exact graph set depends on the selected profile and available providers.

Use the same time selection across related tables. A process with the highest total CPU over a ten-minute trace may be unrelated to a two-second UI stall. Conversely, an apparently idle process can be waiting on a delayed disk request, a serialized lock, or a dependency outside the captured process. Inspect process, thread, stack, path, and event columns together; then narrow the table to the interval and activity that match the reproduction. If symbols are missing, resolve that first because unsymbolized addresses can conceal the call path that determines whether a stack is actionable.

Before claiming causation, test an alternative explanation. Compare a second run, correlate trace timestamps with application logs, and check whether instrumentation overhead changes the behavior. A trace can establish ordering and resource activity; it does not by itself prove why application code made a particular decision. Keep the original ETL immutable, save the WPA view separately, and document filters, symbol paths, and any custom profiles needed to reproduce the analysis.

Operational limits and handoff

ETW providers can emit high event volumes. Broad verbose capture increases storage use, can add measurement overhead, and may expose sensitive data. Use a short duration, a narrow provider set, and the smallest detail level that can answer the incident question. If a trace spans sleep or boot, use the WPR-supported on/off or boot scenario instead of assuming a normal user-session recording will capture that transition. Do not run two competing WPR sessions without understanding the profile and logger ownership model.

A useful handoff contains the ETL checksum, OS build, exact reproduction steps, capture profile and mode, wall-clock timestamps, symbol configuration, WPA version, selected time range, and the observation that supports the hypothesis. The next engineer should be able to reopen the same trace and reach the same table rows. This makes WPR/WPA a forensic performance tool rather than a screenshot generator.

Related:

Sources:

Comments