PerfView — .NET Performance Analysis

Yes, PerfView is completely safe to download. It is an official Microsoft open-source project hosted on GitHub under the MIT license, developed and maintained by the .NET runtime team at Microsoft. The source code is publicly auditable at github.com/microsoft/perfview, and every release binary is built through Microsoft’s official CI/CD pipeline.

The PerfView.exe file (approximately 12 MB for version 3.1.30) has been scanned by major antivirus engines including Windows Defender, Norton, and Malwarebytes with zero detections. Because PerfView ships as a single standalone executable with no installer, there is no bundled adware, toolbars, or third-party software included in the download. The tool collects performance data using ETW (Event Tracing for Windows), which is a built-in Windows diagnostic facility, so it does not inject code into your applications or modify system files.

• Download only from the official GitHub releases page or via the aka.ms/perfview/latest redirect maintained by Microsoft
• Verify the file hash against the checksum published on the GitHub release page
• Avoid third-party download aggregator sites that may repackage the executable with unwanted software
• Windows SmartScreen may show a warning on first run because PerfView is not installed through a traditional installer – click “More info” then “Run anyway”

Pro tip: If your corporate security policy blocks unsigned executables, you can build PerfView from source using Visual Studio 2022 with the .NET desktop development workload. The build process takes about 3-5 minutes on a modern machine.

For the verified official download, visit our Download section.

The official PerfView download lives on Microsoft’s GitHub repository at github.com/microsoft/perfview/releases. Microsoft also keeps the shortcut aka.ms/perfview/latest pointed at the newest stable release.

Version 3.1.30 came out February 20, 2026. The download is a single PerfView.exe file, roughly 12 MB. No installer, no registry entries – download it, run it, delete it when you are done. If you prefer package managers, Chocolatey has it (choco install perfview) and WinGet works too (winget install Microsoft.PerfView).

1. Go to the GitHub releases page or use the aka.ms/perfview/latest shortcut
2. Download PerfView.exe from the Assets section of the latest release
3. Save it to a convenient folder like C:\Tools or your Desktop
4. Right-click the file and select “Run as administrator” for full ETW collection capabilities

Pro tip: Pin PerfView to your taskbar or add its folder to your PATH environment variable. This way you can launch it from any command prompt by typing PerfView, which is handy when you need to quickly start a trace on a production server.

You can grab the latest verified download from our Download section on this page.

Yes, PerfView runs on Windows 11 and all current Windows Server editions including Server 2019 and Server 2022. It supports every Windows version from Vista onward, though Microsoft recommends Windows 10 21H2 or later for the best experience with modern .NET workloads.

PerfView v3.1.30 requires .NET Framework 4.7.2 or later to launch. Windows 10 and 11 ship with .NET Framework 4.8 pre-installed, so most users do not need to install anything extra. On older Windows Server builds (particularly Server 2016 at its initial patch level), you may need to update .NET Framework to 4.7.2+ before PerfView will start. Some hardened Azure VM images or corporate group-policy-managed machines may restrict ETW provider access, which can prevent trace collection even though the tool itself runs fine.

• Windows 10/11: Fully supported out of the box. Run as Administrator for complete ETW access
• Windows Server 2019/2022: Fully supported. Common in production profiling scenarios
• Windows Server 2016: Supported after updating to .NET Framework 4.7.2+
• ARM64 Windows: PerfView runs under x86 emulation on ARM devices. Native ARM builds are not yet available

Pro tip: On production servers where you cannot install software, copy PerfView.exe to a temporary folder and run it directly. Because it requires no installation, it leaves zero footprint after you delete the file – ideal for one-off investigations.

Check our System Requirements section for complete hardware and software specifications.

PerfView is a Windows-only application. It cannot run natively on macOS or Linux because it depends on the Windows Forms UI framework and Windows-specific ETW infrastructure for collecting traces.

That said, PerfView can analyze trace files collected on Linux. If you are running .NET applications on Linux, you can use the dotnet-trace command-line tool to capture a .nettrace file on your Linux server, then transfer that file to a Windows machine and open it in PerfView for full CPU and allocation analysis. This cross-platform workflow is the standard approach recommended by the .NET team for profiling Linux-hosted .NET applications. The dotnet-trace tool ships with the .NET SDK and works on Linux, macOS, and Windows.

1. On Linux, install the dotnet-trace tool: dotnet tool install -g dotnet-trace
2. Collect a trace: dotnet-trace collect –process-id [PID] –duration 00:00:30
3. Copy the resulting .nettrace file to a Windows machine using scp or similar
4. Open the .nettrace file in PerfView on Windows for CPU stacks, GC analysis, and flame graph views

Pro tip: For macOS developers targeting .NET, JetBrains dotTrace (included with a Rider license) offers native macOS profiling. For Linux-native profiling without PerfView, consider dotnet-counters for real-time metrics or speedscope.app to visualize traces in a browser.

See our Features section to learn about PerfView’s EventPipe support for cross-platform trace analysis.

PerfView runs on pretty much any Windows machine with .NET Framework 4.7.2 installed. Hardware requirements are minimal for the tool itself.

The executable is about 12 MB – disk space for PerfView itself is a non-issue. What eats disk is the trace data. A 30-second CPU sampling trace produces 10-50 MB. Run a multi-minute trace with verbose GC and allocation tracking, and you can hit 500 MB to several gigabytes. Vance Morrison (PerfView’s original author) suggests keeping at least 2 GB free on the collection drive.

• OS: Windows Vista or later (Windows 10/11 recommended)
• Runtime: .NET Framework 4.7.2+ (ships pre-installed on Windows 10/11)
• RAM: 4 GB minimum for small traces, 8 GB+ recommended for heap dumps over 1 GB
• Disk: 12 MB for PerfView.exe plus 2-10 GB free space for trace files
• Privileges: Administrator rights required for full ETW collection. Non-admin users can analyze existing trace files but cannot collect new ones

Pro tip: If you are analyzing very large heap dumps (10+ GB), consider running PerfView on a machine with 16 GB or more RAM. PerfView loads trace data into memory during analysis, and running out of memory on a massive dump will cause truncated results or crashes.

Full hardware specifications are available in our System Requirements section.

Yes, PerfView is 100% free. It is released under the MIT license, which means you can use it for any purpose – personal projects, commercial development, enterprise production servers – without paying anything or registering an account.

There is no “free tier” with limited features or a paid premium version. Every capability in PerfView, from CPU sampling and GC heap analysis to flame graphs and trace differencing, is available to all users at no cost. The MIT license also permits you to modify the source code and redistribute your own builds. This makes PerfView unique among .NET profilers: competing tools like JetBrains dotTrace start at $299/year for an individual license, and even Visual Studio’s built-in profiling tools require a Visual Studio Professional or Enterprise subscription ($45-250/month) for the full feature set.

• License: MIT (open source, no restrictions on commercial use)
• Cost: $0 – no subscription, no one-time fee, no freemium model
• Enterprise use: Fully permitted. Many Fortune 500 companies use PerfView in production
• Source code: Available at github.com/microsoft/perfview for inspection, contribution, or forking

Pro tip: Because PerfView is free and portable, keep a copy on a USB drive or shared network folder. When a production performance issue hits at 2 AM, having PerfView immediately accessible without needing to download or install anything can save valuable debugging time.

Grab your free copy from the Download section below.

PerfView goes deep on ETW-based tracing with minimal overhead. Paid profilers like dotTrace and dotMemory trade some of that depth for a polished UI and IDE integration.

The real trade-off is convenience versus raw power. dotTrace ($299/year) gives you a visual timeline, automatic hotspot detection, and one-click Visual Studio integration. PerfView gives you the same underlying ETW data but expects you to do the filtering and interpretation yourself. Where PerfView pulls ahead: GC and memory analysis. It exposes GC event logs, generation-level allocation tracking, and heap snapshot diffing at the allocation-stack level – things dotMemory simply does not do. The Visual Studio Performance Profiler sits somewhere in the middle: decent UI, but limited to processes attached to the IDE with no support for production trace files.

• PerfView: Free, portable, production-safe, steep learning curve, deepest ETW access, no IDE dependency
• dotTrace: $299/year, polished UI, IDE integration, automatic analysis hints, no ETW raw access
• Visual Studio Profiler: Included with VS Pro/Enterprise, IDE-only, limited to development scenarios, cannot analyze .etl files
• dotnet-trace: Free CLI tool, collects .nettrace files, minimal analysis UI, works cross-platform

Pro tip: Many experienced .NET developers use dotTrace for day-to-day development profiling and PerfView for production investigations and deep GC analysis. The two tools complement each other well rather than being direct replacements.

Explore what PerfView offers in our Features section.

There is nothing to install. You download one .exe file and double-click it. The whole process takes under a minute.

PerfView v3.1.30 ships as a standalone PerfView.exe (about 12 MB). No MSI, no setup wizard, no manual dependency installs on Windows 10/11. Microsoft designed it this way on purpose – you copy PerfView.exe onto a production server, run your investigation, and delete it. No footprint left behind. The .exe bundles everything it needs internally, including the TraceEvent library for ETW parsing.

1. Visit the Download section on this page and click “Download PerfView”
2. Save PerfView.exe to a folder like C:\Tools\PerfView or your Desktop
3. If Windows SmartScreen appears, click “More info” then “Run anyway” – this is normal for unsigned portable executables
4. Right-click PerfView.exe and select “Run as administrator” for full trace collection capabilities
5. On first launch, PerfView extracts some supporting files to a PerfView subfolder next to the .exe – this is expected behavior

Pro tip: Add PerfView’s folder to your system PATH variable. Then you can open any command prompt or PowerShell window and type PerfView collect to start a trace immediately without navigating to the folder first.

For a complete walkthrough of first-time setup, see our Getting Started guide.

PerfView works without administrator privileges for analyzing existing trace files, but it requires administrator rights to collect new ETW traces. Most users will want to run it elevated.

The reason is technical: ETW (Event Tracing for Windows) is a kernel-level facility, and starting an ETW session requires elevated privileges. Without admin rights, PerfView cannot enable the CPU sampling provider, the .NET runtime provider, or any other kernel-mode event source. You will see “access denied” errors in the collection dialog if you try to start a trace as a standard user. However, if someone else has already collected a trace file (.etl or .nettrace) and shared it with you, PerfView can open and analyze that file without any elevation.

• Collecting traces: Requires “Run as administrator” – right-click PerfView.exe and select this option
• Analyzing trace files: No admin rights needed. Anyone can open and explore .etl, .nettrace, and .etlx files
• GC heap snapshots: Requires admin rights because PerfView needs to attach to the target process
• Command-line usage: Launch your elevated command prompt first, then run PerfView commands from it

Pro tip: On locked-down production servers where requesting admin access requires a change ticket, ask your operations team to collect the trace for you. Send them a one-liner: PerfView.exe collect /AcceptEULA /NoGui /MaxCollectSec:30. They run it, send you the .etl file, and you analyze it on your own machine without admin access.

Learn more about PerfView’s capabilities in our Features section.

Yes – PerfView has a full command-line interface. Same .exe, no GUI window needed. This is how most people use it on production servers and in CI/CD pipelines.

You pass subcommands and flags to control collection. The three commands you will use most: collect (general tracing), run (trace a specific program start-to-finish), and GCCollectOnly (lightweight GC data only). Run PerfView.exe -help to see every available flag.

1. Open an elevated command prompt or PowerShell window
2. Navigate to the folder containing PerfView.exe, or add it to your PATH
3. Collect a 30-second trace: PerfView.exe collect /AcceptEULA /NoGui /MaxCollectSec:30
4. Profile a specific application: PerfView.exe run /AcceptEULA “MyApp.exe arg1 arg2”
5. Collect GC data only (low overhead): PerfView.exe GCCollectOnly /AcceptEULA /NoGui /MaxCollectSec:60

Pro tip: The /AcceptEULA flag suppresses the first-run license dialog, and /NoGui prevents the GUI window from appearing. These two flags are essential for headless collection on servers. Add /Zip:true to compress the output .etl file for easier transfer off the server.

Our Getting Started guide covers additional command-line scenarios in detail.

PerfView startup failures are almost always caused by a missing .NET Framework version or corrupted extracted support files. The fix is straightforward in both cases.

PerfView v3.1.30 requires .NET Framework 4.7.2 or later. On Windows 10 version 1803+ and Windows 11, this ships pre-installed. Older Windows 7 or Server 2016 machines may need a manual .NET Framework update from Microsoft’s download center. The second common cause is corrupted extraction files: when PerfView first runs, it unpacks supporting DLLs and configuration files into a subfolder. If that extraction was interrupted (power loss, disk full, antivirus quarantine), subsequent launches will fail with obscure errors.

1. Verify .NET Framework 4.7.2+ is installed: open a command prompt and run reg query “HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full” /v Release. A value of 461808 or higher means 4.7.2+
2. Delete the PerfView subfolder next to PerfView.exe (this forces a clean re-extraction on next launch)
3. Make sure antivirus is not quarantining PerfView’s extracted DLLs – add an exclusion for the PerfView folder
4. Try running as administrator – some systems block non-elevated applications from writing to certain directories
5. Download a fresh copy of PerfView.exe from the Download section in case the file is corrupted

Pro tip: If PerfView crashes during analysis (not startup), the cause is usually an out-of-memory condition when loading a very large trace. Close other applications to free RAM, or try opening the trace with the /MaxNodeCountK:100 flag to limit memory consumption at the cost of some detail.

Check our System Requirements to confirm your machine meets all prerequisites.

Those “?!?” entries mean PerfView could not figure out which function was running at that sample point. It is the single most complained-about issue in PerfView’s GitHub issues.

The causes vary. High CPU load during collection creates “unwind contention” – the OS cannot walk the call stack fast enough before it changes. VMs (Azure, Hyper-V with nested virtualization) make this worse. Laptop power-saving C-states can corrupt samples too. For native (non-.NET) code, missing .pdb symbol files are usually the culprit. On a healthy system, ?!? frames stay below 5%. If you are seeing 10-15% or more, something is actively interfering with trace collection.

1. Reduce system load during collection – close unnecessary applications to give ETW more CPU budget for stack walking
2. Shorten trace duration to 30-60 seconds instead of minutes, which reduces the chance of contention
3. On VMs, check if nested virtualization or CPU hot-add is enabled – both can increase ?!? rates
4. For native code frames, configure symbol paths: go to File > Set Symbol Path and add Microsoft’s public symbol server (https://msdl.microsoft.com/download/symbols)
5. Use the “bottom-up” (By Name) view instead of call-tree view – it aggregates resolved frames and is less affected by individual corrupted stacks

Pro tip: If you consistently see high ?!? rates on a specific machine, try the /CpuSampleMSec:10 flag to reduce the sampling frequency from the default 1 ms to 10 ms. This gives the OS more time to walk each stack, dramatically reducing unresolved frames at the cost of fewer total samples.

Learn more about PerfView’s stack analysis capabilities in our Features section.

Large .etl files (1 GB+) happen when you collect too many ETW providers for too long. You have two options: collect less data next time, or filter what you load from the existing file.

Here is the problem: PerfView loads trace data into memory. A 5 GB .etl file needs 10-15 GB of RAM to process. If your machine runs out, PerfView hangs or crashes. Heap dumps are even worse – a process using 10 GB of managed memory produces a 10 GB snapshot. Vance Morrison’s rule of thumb: keep traces under 500 MB if you have 8 GB of RAM.

1. Reduce collection duration: Use /MaxCollectSec:30 instead of collecting for minutes. 30 seconds is enough for most CPU profiling scenarios
2. Limit providers: Uncheck providers you do not need in the Collect dialog. Disabling OS kernel events (file I/O, registry, network) dramatically reduces file size
3. Use GCCollectOnly: If you only need GC data, use the GCCollectOnly command which collects minimal events (typically 1-5 MB per minute)
4. Filter on open: When opening a large .etl, use Process Filter to load only your target process. This avoids parsing events from every running process on the machine
5. Convert to .etlx: PerfView can convert .etl to a smaller .etlx format that strips raw event payloads while preserving stack analysis data

Pro tip: For production monitoring where you need long-duration collection, use /CircularMB:500 to create a circular buffer. PerfView will overwrite old events when the file reaches 500 MB, keeping only the most recent data. This is ideal for capturing intermittent issues without filling up the disk.

See our Getting Started guide for recommended collection settings.

Download the new PerfView.exe and replace the old one. That is the entire update process. There is no built-in auto-update.

Since PerfView is just a standalone .exe with no registry entries, updating means replacing one file. Current version: v3.1.30 (February 2026). New releases come out every 2-4 months with bug fixes and support for newer .NET versions. Check what you are running by looking at the title bar, or run PerfView.exe -help which prints the version number.

1. Check the GitHub releases page (github.com/microsoft/perfview/releases) for new versions
2. Download the new PerfView.exe from the latest release Assets section
3. Close any running instance of PerfView
4. Replace the old PerfView.exe with the new one in the same folder
5. Delete the PerfView subfolder (extracted support files) to ensure a clean extraction of the new version’s dependencies

Pro tip: Subscribe to the GitHub repository’s “Releases only” notifications (Watch > Custom > Releases) to get an email whenever a new version drops. This keeps you informed without flooding your inbox with issue and PR notifications.

Download the latest version from our Download section.

Yes, PerfView fully supports profiling .NET 8 and .NET 9 applications. It has been updated to recognize the runtime event providers and GC changes introduced in these newer .NET versions.

PerfView v3.1.30 supports all .NET runtime versions from .NET Framework 4.x through .NET 9. Each major .NET release sometimes renames or adds ETW providers, so using an up-to-date PerfView version is important when profiling modern runtimes. For .NET Core and .NET 5+ applications, PerfView supports both traditional ETW collection (Windows-only) and EventPipe-based collection via .nettrace files. EventPipe traces can be collected cross-platform using dotnet-trace and then analyzed in PerfView on Windows.

• .NET Framework 4.x: Full support for CPU, GC, memory, and ETW events
• .NET Core 3.1: Supported via both ETW and EventPipe
• .NET 5/6/7: Full support including the new GC regions feature introduced in .NET 7
• .NET 8/9: Supported with updated event definitions. Make sure you are using PerfView v3.1.x or later for best compatibility
• ASP.NET Core: PerfView can profile request pipelines, middleware execution, and Kestrel internals

Pro tip: When profiling .NET 8/9 apps, enable the Microsoft-DotNETCore-SampleProfiler provider in addition to the default providers. This gives you managed-code-only CPU stacks without any kernel-mode noise, which is often more useful than the default mixed-mode stacks for pure .NET applications.

Read about all supported analysis types in our Features section.

PerfView wins for production diagnostics and deep ETW analysis. dotTrace wins for everyday development profiling with a modern UI. They solve different problems.

PerfView handles things dotTrace cannot: zero-install production profiling, GC heap analysis with allocation stacks, ETW event correlation, and trace differencing for before/after comparisons. dotTrace ($299/year, or bundled in dotUltimate at $649/year) gives you a visual timeline, automatic hotspot detection, and tight Visual Studio/Rider integration. If you want quick answers during development with minimal setup, dotTrace is faster. If you are investigating a production issue at 3 AM on a server you cannot install software on, PerfView is the tool the .NET community reaches for.

• Cost: PerfView is free (MIT license). dotTrace starts at $299/year
• Learning curve: dotTrace has an intuitive UI – usable within minutes. PerfView requires watching Vance Morrison’s tutorial series (about 2 hours) to become productive
• Production use: PerfView is designed for production. dotTrace attaches to running processes and adds measurable overhead, making it less suitable for production servers
• Cross-platform: dotTrace works on Windows, macOS, and Linux. PerfView is Windows-only (though it can analyze Linux traces)
• GC analysis: PerfView provides deeper GC diagnostics including per-generation allocation tracking, pinning analysis, and GC pause attribution. dotMemory handles memory but with less GC-level detail

Pro tip: Many senior .NET developers keep both tools available. Use dotTrace for quick profiling during development, and switch to PerfView when you hit a complex production issue that requires raw ETW data or GC-level investigation.

See our detailed Features section for everything PerfView offers.

PerfView finds managed memory leaks by diffing two GC heap snapshots. Take one at baseline, run your workload, take another, and the diff shows you exactly what grew and which code allocated it.

This works differently from dotMemory. PerfView captures heap snapshots as .gcdump files and diffs them rather than showing a live object graph. When you enable .NET Alloc tracking during collection, you get allocation call stacks – so you see both what is leaking and where in the code the allocation happens. Real-world example: your ASP.NET service balloons from 200 MB to 2 GB over 24 hours. Two snapshots taken 10 minutes apart will show the specific types piling up and the exact code paths responsible.

1. In PerfView, go to Memory > Take Heap Snapshot and select your target process. Save as baseline.gcdump
2. Run your application’s workload for a representative period (5-10 minutes for most leak scenarios)
3. Take a second heap snapshot. Save as after-workload.gcdump
4. Open both files in PerfView. Select the after-workload dump and choose Diff with Baseline
5. Sort by “Exc Size Diff” to see which types grew the most. Click into the growing types to see their allocation stacks

Pro tip: Before taking snapshots, force a full GC by calling GC.Collect(2, GCCollectionMode.Forced, true, true) in your app (or via a diagnostic endpoint). This clears short-lived objects and makes the diff cleaner, showing only genuinely retained objects rather than normal generational garbage.

Get started with memory analysis using our Getting Started guide.

A flame graph shows CPU time as stacked colored bars. Wider bars = more CPU time. Your job is to find the wide bars (hot functions) and trace them back to the callers responsible.

To get there: double-click an .etl file in PerfView, select “CPU Stacks” from the tree, and click the “Flame Graph” tab. The bottom bar is the root of all call stacks (usually your app’s main thread). Each layer above goes one level deeper into the call stack. Bar width matches the percentage of CPU samples for that function. The colors are random – they just help you tell adjacent bars apart, they do not encode any performance data.

1. Open your trace file in PerfView and navigate to CPU Stacks for your target process
2. Apply a process filter if multiple processes were captured (type the process name in the filter box)
3. Switch to the Flame Graph tab in the stack viewer
4. Look for the widest bars near the top of the graph – these are the leaf functions consuming the most CPU directly
5. Click on any bar to zoom in and see its callers (below) and callees (above) in detail
6. Use the “Exc %” column in the accompanying table to see exact percentages

Pro tip: If the flame graph is too busy, use PerfView’s GroupPats feature to fold framework code (like System.* and Microsoft.*) into summary groups. This makes your application code stand out clearly against the collapsed runtime internals. A good starting pattern is [group framework] System.*=>FRAMEWORK;Microsoft.*=>FRAMEWORK.

Explore PerfView’s visualization capabilities in our Features section.