PerfView is basically the Swiss-army knife for .NET performance—CPU, GC, memory, thread time, and arbitrary ETW events—all in one (slightly ugly but insanely powerful) tool. Let’s turn this into the one-stop, end-to-end tutorial you asked for.

---

1. What is PerfView?

PerfView is a free Windows performance-analysis tool from Microsoft that focuses on:

• CPU usage (sampled stacks, call trees, wall-clock vs CPU time)
• Managed memory & GC (GC stats, allocation hotspots, heap snapshots)
• Thread behavior (thread time, context switches, blocking)
• General ETW/EventPipe events (including app-specific providers)

It:

• Runs on Windows and requires .NET Framework 4.7.2+. ()
• Is distributed as a single EXE (PerfView.exe)—no install wizard, just download and run.
• Is built on Microsoft.Diagnostics.Tracing.TraceEvent, so it can parse ETW and .NET EventPipe traces (.nettrace). ()

Microsoft’s own docs recommend PerfView for analyzing CPU, memory, GC, performance events, and wall-clock time in .NET apps. ()

---

2. Why do we need PerfView?

You reach for PerfView when you want deep, low-level truth about your .NET application, especially in production-like scenarios.

Typical problems PerfView is great at:

1. High CPU
   • Identify hot methods, inefficient loops, excessive JSON parsing, etc.
   • CPU Stacks + CallTree views make it clear where time is actually spent. ()
2. High GC / memory pressure
   • GCStats for % Time in GC, collection counts, heap size growth. ()
   • Heap snapshots and heap diffs to find which object graphs grow over time. ()
3. Memory leaks / managed leaks
   • Capture multiple heap snapshots, diff them, and see which types grew and who’s holding them alive. ()
4. Intermittent production issues
   • “Flight recorder” style: collect ETW data in a ring buffer and stop when a trigger fires:
     • Perf counter threshold (CPU, GC, memory)
     • Long HTTP request
     • Long GC
     • Particular exception type or Event Log message ()
5. Custom ETW analysis
   • For example, Business Central, IIS, Visual Studio, or your own EventSource providers. ()

PerfView trades pretty UI for power, low overhead, and precise control over what you collect and when.

---

3. Installing PerfView

3.1. Download

The official way to get PerfView:

• Go to GitHub Releases: (PerfView repo) → Releases. ()
• Or directly download the latest via the shortcut link documented by Microsoft (aka.ms/perfview/latest). ()

You usually only need one file:

PerfView.exe
Code language: CSS (css)

Optional but recommended: verify the digital signature of PerfView.exe (right-click → Properties → Digital Signatures) to be sure it’s the genuine Microsoft-signed binary. ()

3.2. Prerequisites

• OS: Supported Windows version (Windows 10+ / Server equivalents).
• Runtime: .NET Framework 4.7.2+ must be installed on the machine where you run PerfView. ()
• Admin rights:
  • PerfView can collect some data without admin, but for full ETW (kernel + runtime) you should run it as Administrator. ()

3.3. Running PerfView

• Put PerfView.exe into some tools folder, e.g. C:\tools\PerfView.
• Right-click → Run as administrator (especially on servers). ()

No installation, no registry entries—just xcopy.

---

4. Key Terminology (PerfView & ETW)

Understanding PerfView’s vocabulary makes everything easier.

4.1. ETW, ETL, ETLX, and .etl.zip

• ETW (Event Tracing for Windows)
  OS-level event pipeline used by PerfView. Kernel, .NET runtime, and many applications log events here. ()
• ETL
  Raw ETW Event Trace Log file (*.etl). PerfView uses ETW sessions to write these. ()
• ETLX
  PerfView’s indexed/processed version of ETL that speeds up viewing. When you open a trace, PerfView converts *.etl → *.etlx. ()
• PerfViewData.etl.zip
  A zipped bundle that usually contains:
  • PerfViewData.etl
  • Possibly auxiliary ETL files and symbol/PDB data
    Used for sharing traces between machines. ()
• Merge
  Operation that merges kernel ETL with main ETL and grabs system-specific metadata into a single file for offline analysis. ()
• Zip
  Optional step that compresses the merged trace and bundles relevant NGen PDBs. ()

4.2. Providers, Keywords, Levels

• Provider
  Source of events (e.g., Microsoft-Windows-Kernel-Process, Microsoft-Windows-DotNETRuntime, Business Central’s Microsoft-DynamicsNAV-Server). ()
• Keywords
  Bitmask controlling which categories of events are enabled for a provider (e.g. GC, loader, JIT, etc.). In Business Central docs you see things like Microsoft-DynamicsNAV-Server:0x4 or :0xC to pick event classes. ()
• Level
  Verbosity level (Critical, Error, Warning, Informational, Verbose).

PerfView’s /Providers qualifier or “Additional Providers” GUI textbox lets you specify provider:keywords:level. ()

4.3. CPU sampling, Inclusive/Exclusive time

PerfView’s CPU analysis is built on sampling:

• Every ~1 ms per CPU, ETW grabs a stack trace of the currently running thread. ()
• Each sample counts as ~1 ms of CPU.

Terminology:

• Exclusive metric: samples taken in a method itself.
• Inclusive metric: samples taken in a method or anything it calls (the whole subtree). ()

You normally optimize the inclusive heavy nodes in CPU Stacks / CallTree, then drill into them.

PerfView also explains statistical error: you generally want 1000+ samples, ideally ~5000, to reduce noise. ()

4.4. GC, Generations, Heap, Allocation

• Generations (Gen 0 / 1 / 2, LOH): tiers of the managed heap; Gen 0 is short-lived, LOH is for large objects.
• GCStats: PerfView’s view that summarizes GC counts, pause durations, heap size, % Time in GC, etc. ()
• GC Heap Snapshot (.gcDump): a snapshot of managed heap, whose “Heap Stacks” view tells you:
  • Types using the most space
  • How many instances
  • Who’s holding references to them ()

---

5. Getting Started – GUI, Step by Step

Let’s walk through a simple CPU + GC investigation of a .NET app called Orders.Api.exe.

5.1. Prepare

1. Download PerfView.exe to C:\tools\PerfView. ()
2. Create a working folder, e.g. C:\perf-traces.
3. Run PerfView as Administrator.
4. In PerfView, set Current Directory (top text box) to C:\perf-traces.

5.2. Quick CPU trace using Collect → Run

Best for short-lived EXEs or repeatable console scenarios. ()

1. In PerfView menu: Collect → Run.
2. For Command: C:\MyApp\Orders.Api.exe (or your app).
3. Click Start.
4. PerfView:
   • Starts ETW capture
   • Launches your command
   • Stops when the process exits
   • Automatically opens the stack viewer

This is ideal for development-time profiling of small repros.

5.3. CPU trace on a long-running service – Collect → Collect

For ASP.NET/Windows services, you can’t easily “wrap” the process, so use Collect. ()

1. Menu: Collect → Collect.
2. In the dialog:
   • Collect:
     • Check CPU Samples.
     • Check ThreadTime if you want wall-clock per thread.
   • Zip, Merge:
     • Check both if you plan to send the trace to someone else. ()
   • Optionally, click Advanced Options:
     • Add extra providers (e.g. Business Central Microsoft-DynamicsNAV-Server:0xC). ()
3. Click Start Collection.
4. Exercise your scenario (e.g., hit /api/orders with load).
5. Click Stop Collection.

PerfView creates PerfViewData.etl and, if zipped, PerfViewData.etl.zip in current directory. ()

5.4. Analyzing CPU Stacks

1. In the left tree, expand PerfViewData.etl.zip → PerfViewData.etl.
2. Double-click CPU Stacks.
3. In the Process dialog:
   • Choose Orders.Api (or your process).
4. You now see:
   • By Name view: methods sorted by inclusive CPU cost.
   • Columns: Inc %, Exc %, Calls, etc.

Recommended first actions (from User’s Guide): ()

• Check there are at least 1000–5000 samples for your process.
• Confirm your process is actually CPU-bound (look at the “When” column).
• Ensure symbol resolution is working (no ? names for important frames).

Then:

• Use GroupPats and Fold % (F7) to collapse uninteresting modules and small nodes to focus on major costs. ()
• Double-click a method or right-click → Drill Into to zoom into only the samples involving that method. ()

5.5. Quick GC Overview

From the same trace:

• Double-click GCStats under the trace node. ()
• Look for:
  • Total % Time in GC.
  • Number and duration of Gen 2 & LOH collections.
  • Trend of heap size over time.

This quickly shows whether GC is a big part of your problem.

---

6. Step-by-Step: Memory Leak / High Memory

Scenario: Orders.Api uses more and more memory until the process is huge.

6.1. Taking heap snapshots from a running process (GUI)

Workflow summarized from well-known PerfView memory leak tutorials: ()

1. In PerfView menu: Memory → Take Heap Snapshot.
2. Select Orders.Api from the process list.
3. Click Dump GC Heap.
4. Wait while PerfView captures the GC heap → a .gcDump file appears in the tree.
5. Double-click the .gcDump → Heap Stacks.

In Heap Stacks:

• By default you see types sorted by total size, e.g. System.String, MyApp.OrderCache, etc.
• You can switch between:
  • By Name (grouped by type)
  • By Size Stack (grouped by allocation roots / owners)

6.2. Compare two heap snapshots (diff)

1. Let the app run; memory grows.
2. Take a second heap snapshot the same way.
3. With both heap stacks open, use Diff:
   • Choose first snapshot as baseline.
   • Generate a diff view.

Diff columns show how much each type changed between snapshots (bytes & percentage). ()

Typical interpretation:

• Types with large positive growth are likely leak candidates.
• Drill into their stacks to see who is holding references.

6.3. Heap snapshot from a dump (Windows or Linux)

If you have a dump / core dump:

• Memory → Take Heap Snapshot From Dump
  • Input: dump file (e.g. core.1234 or app.dmp)
  • Output: .gcDump file
• Then analyze it with Heap Stacks exactly like live snapshot. ()

This is useful for production crash dumps or Linux .core files.

---

7. Command-Line Usage – Basics to Advanced

PerfView has a powerful CLI for automation and headless collection. Most of it boils down to:

• Commands: run, collect, start, stop, abort, HeapSnapshot, etc.
• Qualifiers: /LogFile, /MaxCollectSec, /StopOnPerfCounter, /GCOnly, etc.

PerfView’s User’s Guide has a dedicated section on Collecting Data from the Command Line and a Command Line Reference. ()

7.1. PerfView run – wrap an executable

PerfView run C:\MyApp\Orders.Api.exe
Code language: CSS (css)

• Starts collection, runs the EXE, and opens the viewer as soon as app exits. ()
• Great for development-time profiling of small, repeatable scenarios.

Common variation (headless, scripted):

PerfView /LogFile=PerfViewRun.log /AcceptEula /NoView run C:\MyApp\Orders.Api.exe

• /LogFile=... → no GUI; log messages to file. ()
• /AcceptEula → auto-accept license on first run (important for CI). ()
• /NoView → don’t open viewer after collection. ()

7.2. PerfView collect – system-wide logging

PerfView collect

• Starts system-wide logging and pops a small console so you can stop collection manually.
• Typically used when profiling services / ASP.NET / server scenarios where you want to control start/stop. ()

Add useful qualifiers:

PerfView /LogFile=PerfViewCollect.log /AcceptEula /MaxCollectSec:10 collect

• Collect for 10 seconds max, then stop automatically. ()

7.3. start, stop, abort – multi-step scripts

Useful when you want to:

1. Start tracing.
2. Run some scenario via script.
3. Stop tracing afterwards.

PerfView start /AcceptEula /LogFile=PerfViewCollect.log
REM Run workload here…
PerfView stop /AcceptEula /LogFile=PerfViewCollect.log

• start begins logging.
• stop stops logging and writes ETL.
• abort can be used to ensure no PerfView session remains running (cleanup). ()

Use with care: if the script fails between start and stop, logging could remain on, so abort is your safety net.

7.4. Heap snapshot from CLI

From the maintainers’ discussion: ()

PerfView HeapSnapshot Orders.Api
Code language: CSS (css)

or

PerfView HeapSnapshot 12345 OrdersApiLeak.gcdump
Code language: CSS (css)

• First parameter: process ID or process name (without .exe).
• Optional second parameter: output file name.

7.5. GC-focused collection: /GCOnly and /GCCollectOnly

PerfView has special modes for long-term GC monitoring:

• GC Only – GC allocations plus some memory info, but not all other events. Good for hour-long traces. ()

PerfView /GCOnly collect

• GC Collect Only – only GC collection events (no allocation sampling). Good for day-long traces. ()

PerfView /GCCollectOnly collect

These drastically reduce trace size, letting you monitor GC behavior over long periods (hours/days).

7.6. .NET allocation and call events: /DotNetAlloc, /DotNetAllocSampled, /DotNetCalls

From the User’s Guide: ()

• /DotNetAlloc
  • Log an event for every managed allocation.
  • High overhead, can lose events under heavy load.
• /DotNetAllocSampled
  • Sampled allocations (much lower overhead).
  • Recommended over full allocation logging.
• /DotNetCalls
  • Event on every .NET method entry (no inlined methods).
• /DotNetCallsSampled
  • Sampled version (1 in ~997 calls).
• /DisableInlining
  • Turn off JIT inlining so you see every call (again, high overhead).

Example: sample allocation-heavy parts of your app:

PerfView /DotNetAllocSampled /GCOnly /MaxCollectSec:30 collect

7.7. Kernel and .NET event selection: /KernelEvents, /ClrEvents

You can tune ETW data volume by adjusting kernel and CLR event sets. ()

Examples:

• Disable most kernel events except minimal base:

PerfView /KernelEvents=None collect

• Turn on kernel memory and VirtualAlloc events:

PerfView /KernelEvents=default+Memory+VirtualAlloc+VAMap collect
Code language: JavaScript (javascript)

• Disable all .NET runtime events:

PerfView /ClrEvents=None collect

Or start with GC events only:

PerfView /ClrEvents=GC+Stack collect

7.8. Production “flight recorder” triggers

PerfView has /StopOn* and /MonitorPerfCounter qualifiers that turn it into a smart flight recorder. ()

Stop when a perf counter crosses a threshold – /StopOnPerfCounter

Syntax (similar to PerfMon):

PerfView collect "/StopOnPerfCounter:CATEGORY:COUNTER:INSTANCE OP NUM"
Code language: JavaScript (javascript)

Example: stop when global % Time in GC > 20%:

PerfView collect "/StopOnPerfCounter:.NET CLR Memory:% Time in GC:_Global_>20"
Code language: JavaScript (javascript)

Example: stop when machine committed bytes > 50 GB:

PerfView collect "/StopOnPerfCounter:Memory:Committed Bytes:>50000000000"
Code language: JavaScript (javascript)

Log perf counters into ETL – /MonitorPerfCounter

PerfView "/MonitorPerfCounter=Memory:Available MBytes:@10" collect
Code language: JavaScript (javascript)

• Logs Available MBytes every 10 seconds as events in the trace. ()

Stop on long HTTP request – /StopOnRequestOverMSec

PerfView collect "/StopOnRequestOverMSec:2000"
Code language: JavaScript (javascript)

• Stops when any IIS/ASP.NET request takes longer than 2000 ms. ()

Add /CollectMultiple:N to capture multiple slow cases:

PerfView collect "/StopOnRequestOverMSec:2000" /CollectMultiple:3
Code language: JavaScript (javascript)

Stop on Event Log message – /StopOnEventLogMessage

PerfView collect "/StopOnEventLogMessage:MyErrorPattern"
Code language: JavaScript (javascript)

• Stops when a Windows Application log message matches the regex MyErrorPattern. ()

Stop on exception – /StopOnException

PerfView collect "/StopOnException:ApplicationException" /Process:Orders.Api /ThreadTime
Code language: JavaScript (javascript)

or more specific:

PerfView collect "/StopOnException:FileNotFound.*Foo.dll" /ThreadTime
Code language: JavaScript (javascript)

• Uses .NET regex to match exception type/message. ()

Multiple triggers and multiple captures

• /CollectMultiple:N → keep collecting until N triggers hit, generating files PerfViewData.etl.zip, PerfViewData.1.etl.zip, etc. ()

---

8. PerfViewCollect and Containers / NanoServer

For Windows Server Core / containers / NanoServer, PerfView supports:

• Running normal PerfView.exe in Windows Server Core containers (with caveats) using CLI only. ()
• A special PerfViewCollect tool (no GUI, .NET Core self-contained) which you build from source and run like:

PerfViewCollect.exe /LogFile=log.txt /MaxCollectSec=30 collect

It uses the same CLI as PerfView.exe but works where the full desktop runtime isn’t available. ()

---

9. Advanced Workflows & Best Practices

9.1. General CPU optimization workflow (summary of User’s Guide) ()

1. Confirm CPU is the bottleneck (not I/O or waiting).
2. Ensure you have enough samples (1000+).
3. Start with ByName bottom-up view, group modules into “Just My Code” vs framework.
4. Use Fold % and manual folding to hide noise.
5. Identify top inclusive methods; drill into them.
6. Apply optimizations; re-collect and compare.

9.2. Memory / GC optimization workflow ()

1. Run a GCOnly or normal trace to check if GC is actually expensive.
2. If GC is high or memory grows:
   • Capture heap snapshots over time (live or from dumps).
3. Use Heap Stacks in diff mode to find growing types.
4. Examine their reference chains to find leak roots (e.g. static caches, event handlers).

9.3. Using PerfView with ASP.NET Core on Linux

• On Linux, you can use PerfCollect (bash script) + native tools (perf, LTTng) to collect traces that can be analyzed in PerfView on Windows. ()

Typical pattern:

1. On Linux: perfcollect collect mytrace.
2. Copy resulting trace to Windows.
3. Open in PerfView to inspect CPU & .NET events.

---

10. Quick Command Cheat Sheet

Here’s a condensed set you can turn into your own cheatsheet:

# Basic dev run
PerfView run C:\MyApp\Orders.Api.exe

# System-wide trace, 20 seconds, headless
PerfView /LogFile=collect.log /AcceptEula /MaxCollectSec:20 collect

# Heap snapshot from running process
PerfView HeapSnapshot Orders.Api OrdersApiLeak.gcdump

# GC only, 1-hour flight recorder, stop when % Time in GC > 20%
PerfView /GCOnly collect `
  "/StopOnPerfCounter:.NET CLR Memory:% Time in GC:_Global_>20" `
  /LogFile=gcflight.log /AcceptEula

# ASP.NET slow request > 5s (collect 3 examples)
PerfView collect "/StopOnRequestOverMSec:5000" /CollectMultiple:3

# Stop when ApplicationException thrown in MyService
PerfView collect "/StopOnException:ApplicationException" /Process:MyService /ThreadTime

# Log memory available every 10s
PerfView "/MonitorPerfCounter=Memory:Available MBytes:@10" collect

# Automated CLI-only run for profiling tutorial.exe
PerfView /LogFile=PerfViewRun.log /AcceptEula /NoView run tutorial.exe
Code language: PHP (php)

---

11. Final summary

If you remember only a few things:

• PerfView = serious .NET CPU + GC + ETW profiler, production-friendly, scriptable, and trusted by Microsoft’s own teams. ()
• Use Collect → Run or PerfView run for test apps, Collect → Collect or PerfView collect for services.
• Learn CPU Stacks, CallTree, GCStats, and Heap Stacks—those four views solve 80% of perf problems. ()
• For automation and production:
  • run, collect, HeapSnapshot, /LogFile, /MaxCollectSec, /StopOn* triggers, /GCOnly, /GCCollectOnly.