microsoft/perfview: reading ETW and EventPipe traces on Windows

What PerfView actually does with a trace

The README describes PerfView as a free tool for isolating CPU and memory performance issues, and it is precise about the platform: a Windows tool that also has some support for analyzing data collected on Linux machines. That last clause matters more than it sounds, because Linux support is about reading traces produced elsewhere rather than about collecting them.

The collection side is Event Tracing for Windows, and the parsing side also understands EventPipe, which is the .NET Core trace format. Once a trace is loaded, the usual view is a stack tree, so the workflow is collect, open, sort by cost, read down the tree until a method looks wrong. Memory work is in the same tool, which matters because a lot of .NET performance problems turn out to be allocation rather than CPU.

The repository topics say the same thing in shorthand: dotnet, dotnet-core, performance, performance-analysis and windows. The C# implementation and the MIT license also mean you can read the source of the tool you are relying on when the tool does not explain itself.

TraceEvent is the piece most people actually want

A README section titled Are you here about the TraceEvent Library tells you where the maintainers think the interesting boundary is. PerfView is built on Microsoft.Diagnostics.Tracing.TraceEvent, a library that knows how to collect and parse both ETW and EventPipe data. The question the README asks is whether you want to manipulate something PerfView collected yourself, and if the answer is yes, the library is the entry point.

There is also a separate document for the case where you have not decided, called scenarios, which exists to compare PerfView against TraceEvent for a given job. That is a rarer courtesy than it sounds. Most tools of this kind force the choice implicitly, and the reader ends up automating a GUI by mistake.

The practical dividing line: use PerfView when a person is going to look at the result, use TraceEvent when code is. TraceEvent is published as a NuGet package and is where any CI-side or service-side trace analysis belongs.

Building it means installing Visual Studio 2026 workloads

The build section is unusually explicit about the toolchain, and the list is worth reading before you start because the surprises are all in the optional checkboxes. The stated requirement is Visual Studio 2026, with the .NET desktop development workload and the Desktop development with C++ workload, and the README notes that the Windows 10 SDK is not enabled by default in that second workload so you have to tick it yourself.

Two further components are named by full identifier: MSVC v145 for x64 and x86 build tools, and MSVC v145 Spectre-mitigated libraries, the latter of which has to be found under the Individual Components tab. The README says PerfView intentionally uses the latest installed MSVC v145 toolset, which explains why an older Visual Studio install will not do even though the solution file would probably open.

The repository helps here. A `.vsconfig` file sits in the root, so opening `PerfView.sln` prompts Visual Studio to install whatever is missing, and the same file can be imported into the Visual Studio Installer directly. The solution is `PerfView.sln`, and the README also points at `build.cmd` in the base of the repository for a command-line build of the non-debug version.

ETWClrProfiler failures have one usual cause

The README closes the build section with a troubleshooting note that saves an hour if you know it. If compiling the ETWClrProfiler projects produces errors, the cause is almost certainly a missing Windows 10 SDK or missing Spectre-mitigated libraries, and the README sends you to a troubleshooting section rather than leaving you to bisect the problem.

That is the shape of the whole troubleshooting story, honestly. There is one symptom, one likely cause, and one documented fix. For a project with this much surface area, that is a thin troubleshooting section, and if you hit something outside it you are in issue-reporting territory rather than documentation territory.

The repository root reinforces the Windows-only framing for contributors. Alongside the solution file sit `build.cmd`, `Nuget.config`, `.editorconfig`, `SECURITY.md` and pipeline definitions in `.azuredev/` and `.pipelines/`, plus codecov configuration. Every one of those is a Windows build artefact, which is the clearest signal in the tree about who is expected to build this.

The documentation is one HTML file, and that has consequences

The User's Guide is part of the application itself, reachable from the Help menu, and the README also links a rendered version of the same file at `src/PerfView/SupportFiles/UsersGuide.htm`. It describes the documentation as pretty much just one file, and it means something practical: there is no separate manual to fall back on, and searching the web for an answer means searching inside that page.

The README handles the question-asking process with unusual specificity, because a profiler's usefulness depends on the quality of the trace attached to a bug report. It asks you to search the Users Guide first, then open an issue with a succinct title and the `question` tag if it is a question rather than a bug. If the question is about a specific trace, you can drag the `*.ETL.ZIP` file onto the issue and GitHub will upload it, which lets the people watching reproduce your environment.

The same section asks contributors to fold answers back into that single guide file through a pull request. The documentation directory also holds `Downloading.md`, `Scenarios.md`, `TraceEvent/TraceEventLibrary.md` and `OpenSourceGitWorkflow.md`, so the one-file claim is about the user guide rather than about the whole documentation set.

Recent releases read like a hardening pass

The version history says more about where the project is than the README does. Version 3.2.6 came out on 2026-08-19 and its notes are dominated by parser hardening: a stack overflow on a malformed EventPipe object type length, an access violation on a malformed MethodILToNativeMap entry count, and an infinite loop in the Linux perf script event parser on truncated sched_switch lines. Alongside those sit accessibility fixes, including keyboard focus order and a label for the directory search field.

Version 3.2.4, from 2026-06-16, is the interesting one. Its security section describes bounds checking for malformed event payloads, malformed metadata in several parsers including GCDynamic and EventPipe V3, and PE CodeView entries, plus path containment hardening for PDB extraction, DiagSession resource extraction and dynamic manifest writes, and hardening for Source Server lookups. A tool that parses binary trace files produced by other software is a parser, and this one treats that as a security responsibility.

Two smaller notes from 3.2.5 are worth knowing if you work with Linux data or symbols: spurious broken frames on musl-based Linux stacks were fixed, and embedded portable PDBs are supported for managed symbol resolution. GitHub reports the last push on 2026-09-18, and the repository is not archived.

Editorial conclusion

PerfView rewards the assumption that most people open it under time pressure and want a stack, a flame chart and an answer rather than a metrics pipeline. For a .NET service that slowed down after a framework upgrade, collecting a trace and reading it in PerfView is a short path to a named method. For anything that is not .NET on Windows, the tool still works but you give up the parts that make it distinctive. The repository is at version 3.2.6 with a push on 2026-09-18, and the 3.2.4 release shows a project that treats malformed trace input as a security surface rather than a curiosity. Start with the download page in `documentation/Downloading.md`, read the Users Guide inside the app rather than hunting the web, and reach for TraceEvent only once you know you want the trace data in your own program.

Frequently asked questions

Official sources

1. License: MIT
2. microsoft/perfview on GitHub
3. Project website
4. README
5. Releases