WPR/WPA in Practice — An Introduction to System-Wide Performance Investigation for "the Whole PC Is Slow"

“They said the whole PC got slow after they installed a new app. But when I look at Task Manager, both CPU and memory have headroom.” “There is one PC that takes 3 minutes to start. I have no idea what is wrong.” — Performance consultations really do come in this shape a lot. What they have in common is that looking at a specific process does not give you an answer.

Process-level tools are in place. File and registry access can be seen with Process Monitor, and a .NET app’s CPU and GC can be followed with PerfView. But a symptom such as “the whole PC is slow” or “CPU is idle and it is still slow” starts from not even knowing which process is the culprit. App A may be slow because of an antivirus scan, or because another service is writing heavily to disk, or because of a lock chain that spans several processes. What you need is data that recorded not the inside of a process but the OS as a whole on a single timeline.

The tools for capturing and reading that are Windows Performance Recorder (WPR) and Windows Performance Analyzer (WPA). WPR records OS-wide activity on an ETW (Event Tracing for Windows) base, and WPA analyzes that recording in graphs and tables. Who used CPU on which stack, who a thread was waiting for, which process issued disk I/O to which file — facts a step or two below Task Manager all remain, with timestamps.

Aimed at IT staff in small and medium businesses and at Windows app developers, this article organizes the practice of capturing with WPR and how to read WPA — especially the difference between investigating “when CPU is high” and “when CPU is low and it is still slow” — grounded in primary sources as of August 2026.

1. The Bottom Line First

• The first choice for a “the whole PC is slow” investigation is WPR/WPA, which captures and reads an OS-wide ETW trace. Problems that process-level tools (Task Manager, Procmon, PerfView) cannot pin down can be followed if you look at every process and the kernel on a single timeline.¹²
• The capture tool wpr.exe ships with Windows 8.1 and later. You can use it with no extra install. The GUI edition (WPRUI) and the analysis tool WPA are included in the Windows ADK.¹²
• The basic procedure is three lines. As administrator, wpr -start GeneralProfile -filemode → reproduce the issue → wpr -stop C:\temp\trace.etl. Remember just that and you can start capturing.³
• The field baseline is a split of “in the customer environment, only capture with wpr.exe; reading is WPA on your own machine”. You can capture even on a server where you cannot install software. It is the same idea as packet capture’s “capture with a standard tool, read in Wireshark”.¹
• Reading WPA starts by classifying “CPU, wait, or I/O”. If CPU is burning, CPU Usage (Sampled); if CPU is idle and it is still slow, wait analysis in CPU Usage (Precise); if disk is suspected, Disk Usage — the path splits at the start.⁴⁵
• CPU Usage (Sampled) shows “which function used CPU” from sampling about every 1 millisecond. You can walk the breakdown of Task Manager’s “50%” from process → thread → stack → function.⁶
• CPU Usage (Precise) is a complete record of context switches, and tells you “who a thread was waiting for”. Walking Waits (wait time), ReadyingProcess (who woke it), and ReadyThreadStack (the waker’s stack) is the technique this article most wants to convey.⁴⁷
• Reading a stack requires symbol configuration. WPA refers to Microsoft’s public symbol server by default. To see function names in your own app, add the path to your own PDBs.⁸
• An ETL file contains internal system information such as process names and file paths. Keep the capture to the minimum needed, and decide how it will be handled if it leaves the company before you capture.

2. Where the Tools Sit — WPR Captures, WPA Reads

Windows Performance Toolkit (WPT) is the performance-investigation toolset included in the Windows ADK (Windows Assessment and Deployment Kit); the center is the pair of WPR and WPA.² The roles are clearly split.

• WPR (Windows Performance Recorder) = capture. It bundles groups of ETW providers into a unit called a “profile”, starts and stops recording, and produces an ETL file. The command-line edition, wpr.exe, ships with Windows 8.1 and later, with no extra install. The GUI edition (WPRUI.exe) is included in the ADK.¹
• WPA (Windows Performance Analyzer) = analysis. It opens an ETL file and analyzes it in graphs and tables. An ADK install is required.²

In other words, there is nothing you need to place in the customer environment. Capture with the OS-standard wpr.exe, take the ETL file home, and read it in WPA on your own PC — the same split as packet capture’s “capture with pktmon, read in Wireshark” holds.

flowchart TB
    accTitle: The split of capturing with WPR and reading with WPA
    accDescr: In the customer environment, record with the OS-standard wpr.exe and produce an ETL file; take it home and analyze it in WPA installed via the ADK on your own PC
    subgraph customer["Customer PC (no extra install)"]
        wpr["wpr start → reproduce → stop"] --> etl["ETL file"]
    end
    subgraph office["Your PC (WPA via ADK)"]
        wpa["Analyze graphs and tables"]
    end
    etl -->|"Take home"| wpa

How it differs from similar tools is also worth organizing first.

If Procmon is an operation log of “what it did” and PerfView is “what happened inside .NET”, WPA is a tool that audits “where time disappeared” across every process. The mechanics of ETW itself, and how to instrument your own app with ETW, are covered in “An Introduction to Windows Event Log and ETW”. If your own app emits ETW events, your app’s checkpoints are recorded in the same trace and lining them up becomes much easier. WPR, however, records only events from providers enabled by the recording profile you chose. GeneralProfile does not include your own providers, so if you want them mixed in, prepare a custom recording profile (.wprp) that enables your providers and combine it as wpr -start GeneralProfile -start MyApp.wprp!MyAppProfile, specifying the profile name inside the .wprp file with !³.

3. Capture in Practice (WPR) — start, Reproduce, stop

The basic procedure in an administrator terminal.

:: List of built-in profiles you can use
wpr -profiles

:: 1. Start capture (general-purpose profile, file mode)
wpr -start GeneralProfile -filemode

:: 2. Reproduce the issue (check capture status with wpr -status)

:: 3. Stop and save (you can attach a description of the problem).
::    Create the destination folder in advance (without it, -stop fails to save)
mkdir C:\temp 2>nul
wpr -stop C:\temp\slow-pc.etl "Reproduced the issue where the whole PC becomes slow while starting App X"

:: To abandon without saving
wpr -cancel

What you pass to -start is a profile, a bundle of the ETW providers that investigation needs.³ Remembering only the ones you use often is enough.⁹

You can specify several profiles at once by lining up -start (for example wpr -start GeneralProfile -start FileIO -filemode).³

flowchart TB
    accTitle: WPR capture flow and how to choose a mode
    accDescr: An issue you can reproduce on the spot is captured short and reliably in file mode; an issue whose timing you do not know is waited out in the default memory-mode ring buffer. An issue during boot or logon uses a boot trace. In every case the start / reproduce / stop procedure is the same
    q{"When does it occur?"}
    q -->|"On the spot"| file["File mode: short capture"]
    q -->|"Timing unknown"| mem["Memory mode: wait (3.1)"]
    q -->|"Boot or logon"| boot["Boot trace (Ch. 8)"]
    file --> s1["start → reproduce → stop"]
    mem --> s1

3.1. Memory mode and File mode — can you reproduce, or do you wait

WPR has two recording-destination modes; the default is Memory mode (an in-memory circular buffer). It is a ring buffer that overwrites from the oldest events, so it is suited to leaving capture running while you wait for an issue whose timing you do not know, and stopping when it happens. Adding -filemode switches to File mode, and everything is recorded to a continuous file. This is not overwritten away; the only ceiling is free disk space, and the file grows without bound.¹⁰

flowchart TB
    accTitle: How Memory mode and File mode record
    accDescr: Memory mode records to an in-memory circular buffer; older events are overwritten and only the most recent remain, so it is suited to waiting. File mode keeps everything in a file, but the only ceiling is free disk space, so it is suited to a short, reliable reproduction
    ev["ETW events"] --> ring["Memory mode: ring buffer"]
    ev --> filem["File mode: grow a file"]
    ring -.-> use1["Wait for unknown timing"]
    filem -.-> use2["Short, reliable reproduce"]

A rule of thumb for choosing is as follows.

• Reproducible on the spot → File mode. Start just before reproduction, stop just after, and keep the capture within a few minutes
• Timing unknown → Wait in Memory mode (the default). As soon as it occurs, wpr -stop
• Even a few minutes of GeneralProfile can produce an ETL in the hundreds of MB to GB class. A file that is too large can become unanalyzable in WPA, so “the longer you capture, the better” is counterproductive¹⁰¹¹

To capture from the GUI, start WPRUI, pick a profile and Logging mode, and Start/Save. The official How-to summarizes the procedure.¹¹ If you ask a customer-site contact to capture, the three commands above can go into a procedure as-is.

4. The Basics of Reading WPA — Graphs, the Golden Rule of Tables, and Narrowing Time

When you open a captured ETL in WPA, the left-hand Graph Explorer lists graph thumbnails in categories such as System Activity, Computation, Storage, and Memory.¹² Drag a graph you want to see onto the Analysis tab on the right, and a graph appears above and a table below. The first three things to take on board are these.

1. The golden rule of tables — column order decides grouping. A WPA table has two vertical bars, gold and blue, and columns to the left of the gold bar hierarchize (group) the data in that order, and columns to the right of the blue bar are aggregates.¹³ Arrange them Process → Stack and you get a per-process stack aggregation; Stack → Process and you get an aggregation of every process that uses the same stack — dragging columns to reorder them is itself an analysis operation. Understand this one point and every WPA table is read the same way.

flowchart TB
    accTitle: The golden rule of tables — the two bars and the role of columns
    accDescr: Columns to the left of the gold bar hierarchize the data in that order; columns between the gold and blue bars are display columns; columns to the right of the blue bar are aggregates. Dragging columns to reorder them is itself an analysis operation
    left["Left of gold: grouping"] --> gold["Gold bar"]
    gold --> mid["Between bars: display"]
    mid --> blue["Blue bar"]
    blue --> right["Right of blue: aggregates"]
    left -.-> op["Drag columns to analyze"]

1. Narrow the time range. Drag on the graph to select a range, then right-click and “Zoom”, and the aggregation switches to that interval only. Performance investigation is always, in principle, looking only at “the interval when the issue was happening” (Chapter 9).
2. Configure symbols. To read a stack by function name, run Trace > Load Symbols from the menu.¹⁴ By default it refers to Microsoft’s public symbol server (msdl.microsoft.com), so Windows’s own stacks can be resolved if you have an Internet connection. To see function names in your own app, add the folder of your app’s PDBs in Trace > Configure Symbol Paths.⁸ What a PDB is, and why you should always keep it even for a Release build, is summarized in “What Is a PDB (Program Database)?”. For .NET Framework NGen native images, WPR generates NGen PDBs (.ngenpdb) at capture time and places them in a folder next to the trace, and WPA refers to them automatically.⁸ This is a mechanism for NGen images only, and ordinary JIT .NET app code of your own is out of scope. The mapping from a JIT-code address to a function name is resolved from JIT events the CLR emits, so when you investigate a .NET app, prepare a recording profile (.wprp) that enables the CLR providers (Microsoft-Windows-DotNETRuntime and the matching Rundown) and combine it the same way as your own providers in Chapter 3, wpr -start GeneralProfile -start MyDotNet.wprp!profile-name, so that CLR events are included in the trace (you can check which built-in profiles your local WPR offers with wpr -profiles). On top of that, keep the PDBs generated by the build for mapping to source lines, and add them to the symbol path above.

flowchart TB
    accTitle: Symbol resolution for reading a stack by function name
    accDescr: Running Trace Load Symbols resolves Windows itself from Microsoft's public symbol server, and your own app from build PDBs added to the symbol path. NGen images use NGen PDBs that WPR generates; JIT .NET code is resolved from CLR JIT events in the trace plus build PDBs
    load["Trace > Load Symbols"] --> ms["Windows: public symbols"]
    load --> own["Own app: build PDBs"]
    ms -.-> ngen["NGen: WPR .ngenpdb"]
    own -.-> jit["JIT: CLR events + PDBs"]

Once you are prepared, you enter from the next branch. In that interval, was CPU high, or low? If high, Chapter 5 (Sampled); if low and still slow, Chapter 6 (Precise).

flowchart TB
    accTitle: Branch for choosing a WPA graph from the symptom
    accDescr: Zoom to the issue interval; if CPU is high go to CPU Usage Sampled; if low and still slow, check for a single-core / single-thread pin and then wait analysis in CPU Usage Precise; if disk is suspected, Disk Usage and File IO
    zoom["Zoom to the issue interval"] --> cpu{"CPU in that interval?"}
    cpu -->|"High"| sampled["Ch. 5: Sampled"]
    cpu -->|"Low, still slow"| core{"1-core / 1-thread pin?"}
    core -->|"Yes"| sampled
    core -->|"No"| precise["Ch. 6: Precise"]
    cpu -->|"Disk suspected"| disk["Ch. 7: Disk / File I/O"]

5. When CPU Is High — “Who Is Burning Which Function” with CPU Usage (Sampled)

If CPU is pinned, what you look at is CPU Usage (Sampled). This is sampling data that recorded, about every 1 millisecond on every CPU, “which process’s which stack is running now”, and the ratio of sample counts is the breakdown of CPU time as-is.⁶

flowchart TB
    accTitle: How CPU Usage Sampled works
    accDescr: About every 1 millisecond, the stack running on every CPU is recorded, and the aggregated sample ratio is the breakdown of CPU time. Read from process to thread, stack, and function. Short activity that finishes between samples does not appear
    tick["Interrupt about every 1 ms"] --> snap["Record the running stack"]
    snap --> agg["Sample ratio = CPU breakdown"]
    agg --> drill["Process → Thread → Stack"]
    snap -.-> miss["Activity between samples is missed"]

1. From Graph Explorer’s Computation, place CPU Usage (Sampled) on the Analysis tab and pick the Utilization by Process, Stack preset.⁵
2. Look at processes in descending order of Weight (or Count). The identity of what was “50%” in Task Manager becomes clear first at the process level.
3. Expand the culprit process’s Stack column. Stacks are aggregated as a tree, and walking the path where the number does not drop much at a branch lands you on the function that is burning CPU. If symbols are resolved, it is a straight line to which function in your own code.
4. If expanding the tree is tedious, switch the graph display to Flame. It is drawn with width = share of CPU time, so which call path dominates is obvious at a glance. CPU Usage (Sampled) also has a Flame by Process, Stack preset.¹³

There is one caveat. Because it is sampling, short activity that finishes between samples does not appear.⁶ Remember it as a tool for seeing “where CPU was used in aggregate”, not a tool for measuring exact per-invocation duration.

6. When CPU Is Low and It Is Still Slow — CPU Usage (Precise) and Wait Analysis

This is the core of the article. Before you proceed to wait analysis, though, there is one thing to confirm. “Overall CPU usage is low” does not mean “CPU is not the bottleneck”. On a 16-core PC, serial work pinned to one core (a single UI thread running flat out) only looks like about 6% overall. First check in Chapter 5’s Sampled (or CPU Usage (Precise)’s Utilization by CPU) that there is no pin on a specific core or thread, and if there is not, come to this chapter — the work is not unable to run, it is waiting. What tells you what it is waiting for is CPU Usage (Precise).

Where Sampled is sampling, Precise is a complete record of context switches (thread switches). A thread enters a wait, is woken by someone (Ready), and lands on a CPU — that round trip remains one row at a time, and you can read the following columns.⁷⁴

flowchart TB
    accTitle: One wait round trip and how the columns correspond
    accDescr: A thread enters a wait on the stack that remains in NewThreadStack, and waits for the Waits time. When someone wakes it, that party remains in ReadyingProcess and ReadyThreadStack; it waits the Ready time for CPU contention and then runs again
    run1["Running"] -->|"Enter wait"| waitst["Wait (Waits us)"]
    waitst -->|"Someone wakes it"| ready["Ready (CPU contention)"]
    ready -->|"Lands on a CPU"| run2["Running again"]
    waitst -.-> col["NewThreadStack / ReadyingProcess"]

The reading pattern is as follows.⁴

1. Apply the Utilization by Process, Thread preset and add NewThreadStack and ReadyThreadStack to the columns.
2. First identify the thread that was executing the delayed operation (the UI thread, the thread handling the request in question). Looking only in descending order of total Waits is confusing, because threads that are “intentionally waiting the whole time”, such as a message pump or a timer, occupy the top. Once you have found the target thread, if its CPU Usage (ms) is large it is a Chapter 5 CPU problem; if Waits dominate it is a wait problem.
3. Expand NewThreadStack and see what it was doing when it stopped. WaitForSingleObject or EnterCriticalSection is a lock wait; inside synchronous I/O such as ReadFile it is an I/O wait; inside a socket receive it is waiting for the peer to respond.
4. Next see who released the wait. Expand ReadyThreadStack and check ReadyingProcess / ReadyingThreadId. If it was woken from the kernel’s KiTimerExpiration it was a timer (= it slept until a timeout); if it was woken from I/O completion handling, that confirms it was an I/O wait.⁴
5. If the party that woke it is another thread or another process, investigate that thread with the same procedure. “A was waiting for B to release a lock, B was waiting for C’s RPC response, C was waiting for disk I/O” — what you have when you have walked this chain to the root is the delay’s critical path.⁷

flowchart TB
    accTitle: The critical-path chain you walk in wait analysis
    accDescr: See in delayed thread A's NewThreadStack what it was doing when it stopped, identify the waker B from ReadyThreadStack and ReadyingProcess, and investigate B with the same procedure down to the root disk I/O
    a["Thread A (delayed work)"] -->|"Lock wait"| b["Thread B (holds lock)"]
    b -->|"RPC wait"| c["Process C"]
    c -->|"Sync I/O wait"| d["Disk I/O (root)"]
    d -.->|"Completion wakes C"| c
    c -.->|"Response wakes B"| b
    b -.->|"Lock release wakes A"| a

In a case such as “we multithreaded it and it did not get faster”, this procedure shows every worker lined up on a single lock as-is. Avoiding lock contention by design is covered in “Practical Multithreading Best Practices: .NET Edition”, and the Windows mechanism that runs on a completion notification instead of waiting in synchronous I/O is covered in “I/O Completion Ports (IOCP) and the .NET Thread Pool”. Pinning down “who it was waiting for” in WPA and fixing it with those design arguments is one continuous flow.

7. Disk and File I/O — Identifying “Someone Is Scanning the Disk”

A classic culprit of “the whole PC is slow” is not CPU but disk. You investigate with Disk Usage and File I/O in the Storage category.¹⁵

Disk Usage is a record of disk I/O, and two columns matter. Disk Service Time is the time the disk device actually spent processing that I/O; IO Time is the time from the I/O entering the OS queue until it completed. IO Time is always at least Service Time by the amount of queueing, so if IO Time is much longer than Service Time, that I/O was “waiting in the queue”.⁶ That alone, however, does not decide whether the culprit that made the queue is another process, or only that process’s own heavy I/O lined up on a slow device. Do not draw the conclusion here; settle it with Service Time (the device’s own response) and the next breakdown by process, path, and stack.

Then, with the Utilization by Process, Path Name, Stack preset, look at which process issued I/O to which file from which stack, in descending order of IO Time or Size.¹⁵ The answers that come up often in the field are these two.

• Antivirus was scanning every file. In the window when the app was slow to start, the antivirus process is seen issuing a large volume of reads. Process name, path, and volume are evidence as-is for a discussion of exclusions.
• Another process was writing heavily. Backup, the indexer, logs written too much, and the like. When a write reaches the disk involves the cache manager, so the fact that “the moment you wrote” and “the moment the disk is busy” can diverge is also covered in “Cache Manager — When Does Your WriteFile Actually Reach the Disk?”.

File I/O is one layer up, a record of file operations the app issued (Create/Read/Write and the like), and presets such as Duration by Process, Thread, Type can aggregate time per file name and per operation.¹⁵ A case that spends time in the file system or a filter driver before reaching the disk does not appear in Disk Usage, so the mismatch itself — “Disk Usage is peaceful but File I/O is slow” — is a clue. If you want to start from the mechanics of synchronous and asynchronous I/O, see “Synchronous and Asynchronous I/O — What OVERLAPPED Really Means”.

flowchart TB
    accTitle: The different layers File IO and Disk Usage see
    accDescr: An app's file operation travels through the file system and filter drivers from the OS I/O queue to the disk device. File IO records operations at the upper layer; Disk Usage records I/O that reached the disk; the difference between IO Time and Disk Service Time is queue time
    app["App: ReadFile / WriteFile"] --> fio["FS and filters (File I/O)"]
    fio --> queue["OS I/O queue"]
    queue --> dev["Disk device (Disk Usage)"]
    fio -.-> n1["Missed by Disk Usage"]
    queue -.-> n2["IO Time − Service Time"]
    dev -.-> n3["Service Time = device"]

The line of thought “maybe it is short of memory and swapping” can be given a first isolation in Task Manager and Resource Monitor before you go to WPA. Do not, however, dismiss it from committed memory alone — even with commit headroom, a situation where physical-memory pressure trims the working set and hard faults continue is possible. Also check available physical memory and Resource Monitor’s “Hard Faults/sec”. How to read them is in “What Does Windows’ "Memory Usage" Actually Mean?”.

8. Slow Boot and Logon — The Entrance to a Boot Trace

A “it takes 3 minutes to start” type finishes before you can hand-run wpr -start. WPR has a boot trace, and you can arrange for the OS to start recording automatically on the next boot.³

:: 1. Arrange automatic recording on the next boot
wpr -boottrace -addboot GeneralProfile -filemode

:: 2. Restart (reproduce the slow boot)

:: 3. After boot, stop recording and save (the arrangement is also cleared)
mkdir C:\temp 2>nul
wpr -boottrace -stopboot C:\temp\boot.etl "Issue where boot takes 3 minutes"

flowchart TB
    accTitle: Boot-trace flow
    accDescr: After you arrange automatic recording on the next boot with addboot and restart, the OS starts recording automatically at boot. Saving with stopboot after logon also clears the arrangement. To abandon, clear it with cancelboot
    add["wpr -boottrace -addboot"] --> rebootpc["Restart (slow boot)"]
    rebootpc --> auto["OS records at boot"]
    auto --> stop2["After logon: -stopboot"]
    add -.-> cancel["Abandon: -cancelboot"]

The boot and shutdown measurement that xbootmgr used to own can also be run in current WPR with options such as -onoffscenario Boot.³ A captured trace is read with the same toolkit as the previous chapters. Look at which process was born when on a timeline in the Processes graph, zoom to the window where boot is stuck, and classify CPU, wait, or disk — a startup app waiting for something in series, a service start stuck on a specific I/O, and the like become visible. Boot analysis is a deep specialty in its own right, so this article only goes as far as the entrance: “an issue you cannot catch by hand can still be captured with WPR”. Start by grasping the overall picture with a GeneralProfile boot trace.

9. A Working Pattern — Classify → Zoom → Stack, Repeated

Now that the tools are clear, here is the pattern for the investigation as a whole.

1. Pin down the time of the phenomenon. Not “it was slow”, but “10:23:40–10:24:10 was slow”. App logs, the event log, a note from the person who operated it — anything will do. If your own app writes checkpoints to ETW or the event log, events inside the trace become time stakes as-is.
2. Zoom to that interval only. An aggregation of the whole trace is averaged out, and the anomaly that matters is diluted. WPA analysis is always a comparison of “the interval that was abnormal” versus “the interval that was normal”.
3. Classify “CPU, wait, or I/O” first. Look at CPU Usage (Sampled); if it is burning, Chapter 5. If it is not burning, Waits in CPU Usage (Precise) (Chapter 6). If Disk Usage IO Time is inflated, Chapter 7. Taking this three-way fork first keeps you from getting lost.
4. Repeat hypothesis → zoom → stack. If you think “antivirus?”, narrow to that process and back it with the stack. If it does not hold, the next hypothesis. Not drawing a conclusion before you have walked to the stack and backed it is the discipline of this kind of investigation.

flowchart TB
    accTitle: The iterative loop of a performance investigation
    accDescr: Pin down the time of the phenomenon, zoom to the interval, classify CPU / wait / I/O, form a hypothesis and narrow, and back it with the stack. If it holds, the cause is confirmed; if it does not, repeat with the next hypothesis
    time["Pin down the time"] --> zoomstep["Zoom to that interval"]
    zoomstep --> triage["Classify CPU / wait / I/O"]
    triage --> hypo["Hypothesis and narrow"]
    hypo --> stack["Back it with the stack"]
    stack -->|"Holds"| fix["Cause confirmed"]
    stack -->|"Does not"| hypo

Finally, handling of the capture file. An ETL file widely reflects the inside of the system: the names of every process, paths of files that were opened, modules that were loaded, and (depending on the profile) registry key names. A standard GeneralProfile capture does not include data bodies such as communication contents, but if you enabled a custom provider, that event’s payload (strings the app recorded, and the like) goes in as-is. After confirming what the providers you enabled emit, treat it as a file confidential enough to leave the company. As with packet capture, fold the minimum needed capture, agreement with the party you hand it to, and a retention period and deletion into the procedure.

flowchart TB
    accTitle: What an ETL file reflects, and how to handle it
    accDescr: An ETL reflects every process name, paths of files that were opened, modules, and depending on the profile registry key names; enabling a custom provider also includes its payload. Treat it as confidential: the minimum needed capture, agreement with the other party, and a retention period and deletion
    etl["ETL file"] --> a1["Names, paths, modules"]
    a1 --> a2["Registry keys (some)"]
    a2 --> a3["Custom payload"]
    a3 -.-> rule["Treat as confidential"]

10. Summary

• A “the whole PC is slow” that Task Manager cannot explain is investigated with an OS-wide ETW trace — capture with WPR, read with WPA. wpr.exe ships with Windows 8.1 and later, so a split of capturing in the customer environment, taking the ETL home, and reading it in WPA on your own machine holds.
• Capture is the three steps wpr -start GeneralProfile -filemode → reproduce → wpr -stop trace.etl. If you can reproduce, File mode within a few minutes; if you wait, Memory mode (ring buffer). Longer is not better.
• WPA can be started once you have taken on board three points: the golden rule of tables (left of the gold bar = grouping), zooming the time range, and symbol configuration (your own app needs PDBs).
• If CPU is high, walk process → stack → function in CPU Usage (Sampled). If CPU is low and it is still slow, walk the chain NewThreadStack (what it was doing when it stopped) → Waits (how long it waited) → ReadyingProcess and ReadyThreadStack (who woke it) to the root in CPU Usage (Precise).
• For disk, see “time spent in the queue” from the difference between Disk Usage IO Time and Service Time, and identify the cause (whether the device itself is slow, or who made the queue) from Service Time and the breakdown by process, path, and stack. Slow boot can be captured with wpr -boottrace.
• The working pattern is (1) pin down the time (2) zoom to the interval (3) classify CPU, wait, or I/O (4) repeat hypothesis → zoom → stack. Treat an ETL as confidential because it contains internal information.

WPA’s screen is intimidating, and everyone gets lost in the first hour. Once the two backbones — “left of the gold bar is grouping” and “Sampled is where it burned, Precise is who it waited for” — are in, though, the rest is the same operation repeated. The next time a consultation comes in that “CPU has headroom and it is still slow”, close Task Manager and capture a trace.

Related Articles

• Pinpointing “Slow” with PerfView and dotnet-trace — A Practical Introduction to .NET Performance Investigation
• A Practical Guide to Process Monitor (ProcMon) — Pinpointing “Settings Not Applied” and “ACCESS DENIED” in 10 Minutes
• An Introduction to Windows Event Log and ETW — Putting Your Business App’s Logs on the OS’s Standard Mechanisms
• What Does Windows’ “Memory Usage” Actually Mean? — Correctly Reading Working Set, Private Bytes, Commit, and the Page File
• Windows Processor Scheduling Settings - Background Services and P/E Cores
• What Is a PDB (Program Database)? — Understanding Debug Information, Symbols, and Source Link

Related Consulting Areas

KomuraSoft LLC handles investigation of system-wide performance problems such as “the whole PC got slow and I don’t know why”, “CPU has headroom and the app is still slow”, and “only a specific environment is extremely slow to start”. We handle as one continuous engagement the capture design with WPR/WPA (in which environment, which profile, how much to capture), trace analysis, and the resulting fix on the app side and the settings side.

• Windows Application Development
• Bug Investigation & Root-Cause Analysis
• Technical Consulting & Design Review
• Contact Us

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

Where do I get WPR and WPA? Can I use them in a customer environment where I cannot install software?

The capture tool wpr.exe (the command-line edition) ships with Windows 8.1 and later, so you can use it with no extra install. The GUI edition, WPRUI, and the analysis tool WPA (Windows Performance Analyzer) are included in the Windows ADK (Windows Assessment and Deployment Kit) and do require a separate install. In practice, if you split the work as "in the customer environment capture an ETL file with the OS-standard wpr.exe only, take it home, and analyze it in WPA on your own machine", you can investigate system-wide performance even at a site where you cannot add software.

Why is it slow when Task Manager shows CPU to spare? What can I see in WPA?

When CPU usage is low and it is still slow, the work is not unable to use the CPU — it is stopped "waiting for something". Lock contention, waiting for synchronous I/O to complete, and waiting for another process to respond are typical. Task Manager only shows the result, usage; WPA's CPU Usage (Precise) shows, from a per-context-switch record, where the thread started waiting (NewThreadStack), how long it waited (Waits), and who woke it (ReadyingProcess, ReadyThreadStack). By walking the party that made it wait, you can identify "the culprit of the slowness" down to the function.

How long should I capture a trace? Won't the file become huge?

If you can reproduce the issue, the baseline is to start just before reproduction, stop just after, and keep it within a few minutes. WPR's default is Memory mode, which records to an in-memory circular buffer; older events are overwritten, so it is suited to waiting for an issue whose timing you do not know. File mode, with -filemode, keeps everything in a continuous file, but the only ceiling is free disk space, and a file that is too large can become unanalyzable in WPA. Use Memory mode for a long wait, File mode for a short, reliable reproduction.

How should I choose between PerfView and WPA?

Both tools handle ETW traces, but their strengths differ. PerfView has a deep understanding of the .NET runtime and is strong at managed-app-specific investigation such as GC, allocation, and JIT. WPA is suited to reading OS-wide CPU, disk, file I/O, power, and the like across graphs and tables, and is the first choice when "it is not a specific app but the whole PC that is slow", "multiple processes are involved", or "something outside the app (antivirus, a driver, another process) is suspected". A rule of thumb is PerfView for slowness of your own .NET app alone, WPR/WPA for slowness of the whole system.

Is it all right to run WPR in a customer's production environment?

A short capture is common in practice, but it is not unconditionally safe. ETW is lightweight, but recording a large volume of events with stacks does consume a certain amount of CPU and memory. Fold considerations such as starting just before the reproduction step and stopping just after, keeping the capture within a few minutes, and running it at a time with little business impact into the same approval process as any ordinary change. Also, an ETL file contains internal system information such as process names, file paths, and executable information, so you should decide in advance how it will be handled if it leaves the company (minimization, retention period, deletion).

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.