If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/microsoft/perfview shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 2w ago
• 15 active contributors
• Distributed ownership (top contributor 43% of recent commits)
• MIT licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live microsoft/perfview repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/microsoft/perfview.

What it runs against: a local clone of microsoft/perfview — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in microsoft/perfview | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 46 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of microsoft/perfview. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/microsoft/perfview.git
#   cd perfview
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of microsoft/perfview and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "microsoft/perfview(\\.git)?\\b" \\
  && ok "origin remote is microsoft/perfview" \\
  || miss "origin remote is not microsoft/perfview (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "src/CSVReader/ETLStackBrowse/Trace.cs" \\
  && ok "src/CSVReader/ETLStackBrowse/Trace.cs" \\
  || miss "missing critical file: src/CSVReader/ETLStackBrowse/Trace.cs"
test -f "src/CSVReader/ETLStackBrowse/TraceInterface.cs" \\
  && ok "src/CSVReader/ETLStackBrowse/TraceInterface.cs" \\
  || miss "missing critical file: src/CSVReader/ETLStackBrowse/TraceInterface.cs"
test -f "src/EtwClrProfiler/ETWClrProfiler.h" \\
  && ok "src/EtwClrProfiler/ETWClrProfiler.h" \\
  || miss "missing critical file: src/EtwClrProfiler/ETWClrProfiler.h"
test -f "src/EtwHeapDump/DotNetHeapDumper.cs" \\
  && ok "src/EtwHeapDump/DotNetHeapDumper.cs" \\
  || miss "missing critical file: src/EtwHeapDump/DotNetHeapDumper.cs"
test -f "PerfView.sln" \\
  && ok "PerfView.sln" \\
  || miss "missing critical file: PerfView.sln"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 46 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~16d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/microsoft/perfview"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

PerfView is a free Windows performance-analysis tool built on the Microsoft.Diagnostics.Tracing.TraceEvent library that collects and analyzes CPU and memory profiling data from Event Tracing for Windows (ETW) and .NET EventPipe traces. It specializes in diagnosing performance issues in .NET applications by parsing trace data and presenting actionable insights through a Windows UI and programmatic APIs. Monorepo structure with src/PerfView as the main UI application, src/CSVReader containing trace parsing and ETLStackBrowse with low-level compression (ZL/ deflate codec) and trace event handling. TraceEvent library documentation lives in documentation/TraceEvent/, and build artifacts are controlled via PerfView.sln and build.cmd.

.NET developers and performance engineers who need to diagnose CPU hotspots, memory leaks, and allocation patterns in production or development .NET applications; also used by framework maintainers and platform teams analyzing system-wide performance across Windows and Linux trace data.

Production-ready and actively maintained by Microsoft. The codebase is substantial (15MB+ C#), has comprehensive CI/CD pipelines (.azuredevops and GitHub Actions workflows), official documentation, and user tutorials. Updates appear regular with Azure DevOps mirror and dependabot automation in place.

Low risk for core functionality but medium risk for customization: the tool requires .NET Framework 4.7.2+ (legacy constraint), has complex ETW/EventPipe parsing logic in ETLStackBrowse/ that could break with OS updates, and trace format changes. Single-repo dependency on TraceEvent library means upstream breaking changes could impact stability.

Active development with dependabot automation (.azuredevops/dependabot.yml), stale issue management (.github/workflows/stale.yml), and Copilot integration setup (.github/copilot-instructions.md). Build pipelines for perfcollect-job and perfview-job indicate ongoing CI/CD refinement and cross-platform trace collection work.

git clone https://github.com/microsoft/perfview.git
cd perfview
.\build.cmd

Then open PerfView.sln in Visual Studio 2019+. Requires .NET Framework 4.7.2 or later and Windows (with some Linux trace analysis support).

Daily commands: After building with build.cmd, PerfView.exe is the main application (launch from bin/). For programmatic access, reference the TraceEvent NuGet package. Collect traces via: PerfView.exe Collect or use perfcollect on Linux systems. Analyze via File → Open trace file in the GUI.

• src/CSVReader/ETLStackBrowse/Trace.cs — Core ETW trace data model and parsing logic; foundational for all trace analysis features in PerfView.
• src/CSVReader/ETLStackBrowse/TraceInterface.cs — Public API contract for trace abstraction; defines how all trace consumers interact with trace data.
• src/EtwClrProfiler/ETWClrProfiler.h — COM-based ETW profiler interface; critical native-code instrumentation entry point for CLR event collection.
• src/EtwHeapDump/DotNetHeapDumper.cs — Heap dump parsing and memory analysis engine; essential for memory-profiling workflows.
• PerfView.sln — Solution file; defines all projects and dependencies for building the entire PerfView suite.
• src/Directory.Build.props — Centralized build configuration; all projects inherit from here (version, SDK, common props).
• documentation/TraceEvent/TraceEventLibrary.md — Architecture and usage guide for the TraceEvent library that underpins PerfView's trace collection and parsing.

Add a New Trace Event Type Handler

1. Define the event schema in ETW manifest (src/EtwClrProfiler/ETWClrProfiler.man)
2. Add event parsing logic in the trace parser (src/CSVReader/ETLStackBrowse/Trace.cs)
3. Expose via TraceInterface for consumers (src/CSVReader/ETLStackBrowse/TraceInterface.cs)
4. Write integration tests to verify parsing (src/FastSerialization.Tests/SerializerTests.cs)

Add a New Memory Analysis Feature

1. Implement analysis logic in heap dump engine (src/EtwHeapDump/DotNetHeapDumper.cs)
2. Add graph traversal helpers as needed (src/EtwHeapDump/DotNetHeapDumpGraphReader.cs)
3. Expose metrics through Memory class (src/CSVReader/ETLStackBrowse/Memory.cs)
4. Export results in CSV format if needed (src/CSVReader/CsvReader.cs)

Add a New Native Profiler Hook

1. Define profiler callback in the CLR profiler interface (src/EtwClrProfiler/ETWClrProfiler.h)
2. Implement callback handler in the tracer (src/EtwClrProfiler/CorProfilerTracer.cpp)
3. Route events to logger infrastructure (src/EtwClrProfiler/Logger.cpp)
4. Register event in ETW manifest (src/EtwClrProfiler/ETWClrProfiler.man)

Add a New Compression Algorithm

1. Create new codec class in ZL folder following Deflater pattern (src/CSVReader/ETLStackBrowse/ZL/Deflater.cs)
2. Register codec in compression coordination logic (src/CSVReader/ETLStackBrowse/ZL/CompressionTracing.cs)
3. Add unit tests for encode/decode round-trip (src/FastSerialization.Tests/SerializerTests.cs)

• Event Tracing for Windows (ETW) — Kernel-level performance instrumentation with minimal overhead; standard Windows diagnostic infrastructure.
• COM-based CLR Profiler API — Official .NET Framework profiling interface; enables deep hooks into runtime without modifying managed code.
• Custom Deflate Compression (ZL folder) — Trace files can be very large; custom implementation provides control over performance vs. compression tradeoffs.
• C# & C++ Mixed — Native code for profiler hooks and ETW integration; managed code for analysis logic and UI, maximizing developer productivity.
• .NET Framework 4.7.2+ — Widely deployed baseline; sufficient for Windows-only tool targeting enterprise environments.

• Custom compression codec instead of System.IO.Compression

  • Why: Fine-grained control over performance and memory trade-offs for large trace files; ability to tune for streaming scenarios.
  • Consequence: Additional maintenance burden and custom implementation risks, but better throughput for trace I/O.

• COM-based profiler instead of managed EventPipe (EventListener)

  • Why: Deeper instrumentation of CLR internals; captures events not available through managed APIs.
  • Consequence: Windows-only; requires native code; harder to debug, but more comprehensive data collection.

• In-memory trace model with aggressive compression

  • Why: Faster interactive analysis and filtering; traces can be weeks of data; must fit in memory for responsiveness.
  • Consequence: High memory footprint for large traces; limits horizontal scalability, but enables real-time drill-down queries.

• Stack aggregation with caching

  • Why: Repeated grouping queries (by function, module, etc.) are expensive; cache amortizes cost across multiple analyses.
  • Consequence: Cache invalidation complexity; stale data if trace modified, but typical workflows see 10x speedup on second query.

• Real-time online profiling (PerfView is post-mortem analysis only).
• Cross-platform GUI (Windows tool; Linux analysis limited to trace file import).
• Live streaming of trace data to external dashboards.
• Multi-tenant or cloud-based SaaS offering.
• Automatic anomaly detection or AI-driven recommendations.

Environment constraints: Requires .NET Framework 4.7.2+ on Windows (no .NET Core runtime alternative); ETW collection requires admin privileges. Build quirks: build.cmd is the authoritative build command (not dotnet CLI); Visual Studio 2019+ strongly recommended over command-line. Trace format brittleness: Trace parsing in ETLStackBrowse depends on exact ETW event schema; OS/Windows SDK updates can break parsing. ZL compression: Custom deflate implementation (src/CSVReader/ETLStackBrowse/ZL/) is non-standard; compatibility issues may arise with external tools. No strong package.json equivalent: dependency management via .csproj files only; NuGet.config controls feed sources.

• Event Tracing for Windows (ETW) — ETW is the foundational data source for PerfView; understanding ETW providers, sessions, and event schemas is essential for effective trace collection and interpretation
• Stack walking and call stack unwinding — PerfView's core capability is attributing CPU time and allocations to call stacks; the Stack.cs implementation handles frame resolution and symbol lookup critical to diagnosis
• DEFLATE compression (ZL codec) — Trace files are large; PerfView uses a custom DEFLATE implementation in ZL/ to compress traces; understanding this codec is vital for optimizing trace serialization
• EventPipe (.NET Core trace format) — Modern alternative to ETW used by .NET Core/5+; PerfView must parse both ETW and EventPipe formats, making this dual-format support a key architectural requirement
• Symbol resolution and debugging information — Raw trace data contains memory addresses; converting them to function names requires PDB lookup and symbol servers; TraceEvent/PerfView integration handles this abstraction
• Memory allocation tracking (GC events) — PerfView specializes in memory diagnostics via ETW GC events; understanding allocation rate, object lifetime, and heap behavior is core to the tool's value proposition
• Context switches and CPU sampling — PerfView collects CPU samples via context-switch events; statistical sampling bias and sample interpretation are subtle but critical for accurate performance attribution

• dotnet/diagnostics — Official .NET runtime diagnostics tools (dotnet-trace, dotnet-dump); provides EventPipe collection complement to PerfView's ETW focus
• dotnet/runtime — Source of truth for .NET EventPipe event schemas and ETW event definitions that PerfView parses
• microsoft/TraceEvent — Standalone TraceEvent NuGet library (used by PerfView); allows programmatic trace analysis without the GUI
• microsoft/BenchmarkDotNet — Complementary .NET performance measurement tool; often used with PerfView traces for detailed profiling validation
• google/perfetto — Cross-platform trace visualization alternative (Android/Linux focus); inspired modern trace UI patterns that PerfView approaches differently

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for ETLStackBrowse compression components (ZL namespace)

The src/CSVReader/ETLStackBrowse/ZL directory contains critical compression/decompression logic (Deflater, Inflater, HuffmanTree, etc.) with no visible test coverage. These components handle binary data integrity and could have subtle bugs. Adding comprehensive unit tests would improve reliability of trace file parsing.

• [ ] Create new test project: src/CSVReader.Tests/ETLStackBrowse/ZLCompressionTests.cs
• [ ] Add tests for Deflater.cs with various input sizes and compression levels
• [ ] Add tests for Inflater.cs round-trip compression/decompression
• [ ] Add tests for HuffmanTree.cs encoding/decoding correctness
• [ ] Add tests for edge cases: empty input, single byte, large files, malformed data
• [ ] Integrate tests into .github/workflows CI pipeline

Complete and expand documentation/TraceEvent/TraceEventProgrammersGuide.md with API examples

The TraceEvent library is a major component of PerfView (mentioned in README as 'Are you here about the TraceEvent Library?'), but TraceEventProgrammersGuide.md is incomplete. The file exists but lacks concrete code examples for common tasks like reading ETL files, filtering events, and analyzing stacks. Contributors could add practical examples with working code.

• [ ] Review existing documentation/TraceEvent/TraceEventProgrammersGuide.md structure
• [ ] Add section: 'Reading and Iterating Through ETL Files' with code example
• [ ] Add section: 'Filtering Events by Type and Provider' with code example
• [ ] Add section: 'Analyzing Stack Traces and Call Stacks' with code example
• [ ] Add section: 'Working with Memory Allocation Data' with code example
• [ ] Cross-reference with documentation/TraceEvent/SymbolReader examples

Add GitHub Action workflow for analyzing PerfView trace files in CI pipeline

PerfView is a performance analysis tool, yet there's no CI workflow to actually collect and analyze performance data during builds (only stale.yml and copilot-setup-steps.yml exist). Adding a workflow that collects PerfView traces during test runs would dogfood the tool, detect regressions, and serve as a reference for users.

• [ ] Create .github/workflows/perfview-trace-analysis.yml
• [ ] Add step to run existing test suite (CSVReader.Tests, etc.) with PerfView/TraceEvent collection enabled
• [ ] Export results as .etl files and upload as artifacts
• [ ] Add step to generate summary report comparing performance against baseline
• [ ] Document the workflow in CONTRIBUTING.md with instructions for local reproduction
• [ ] Integrate with existing .pipelines/perfview-job.yml for consistency

• Add unit tests for src/CSVReader/ETLStackBrowse/ZL/Deflater.cs decompression edge cases (currently appears to lack dedicated test coverage visible in file tree); useful for learning the compression layer.
• Expand documentation/Scenarios.md with concrete examples comparing TraceEvent library vs. PerfView GUI for common use cases (dotnet-trace vs. PerfView.exe); helps clarify tool positioning for new users.
• Add missing inline code documentation (XML doc comments) to public methods in src/CSVReader/ETLStackBrowse/Stack.cs and TraceInterface.cs; low-risk way to improve IDE intellisense and maintainability.

PerfView is a Microsoft-managed open-source project with generally good security practices including proper security.md reporting procedures and CI/CD pipelines. Primary concerns are: (1) Custom native C++ code in profiler component requiring strict memory safety controls, (2) Custom compression library implementation that should be replaced with standard libraries, and (3) Incomplete visibility into current dependency versions. The project demonstrates security awareness with dedicated security documentation, though it requires completion. No obvious hardcoded secrets, SQL injection risks, or XSS vulnerabilities detected in the file structure. Recommend focused security reviews on native code components and dependency management automation.

• Medium · Native C++ Code in EtwClrProfiler — src/EtwClrProfiler/ (*.cpp, *.h files). The repository contains native C++ code (EtwClrProfiler) that interfaces with the CLR profiling APIs and ETW infrastructure. Native code is inherently more susceptible to memory safety issues such as buffer overflows, use-after-free, and pointer arithmetic errors. Fix: Implement comprehensive code review process focusing on memory safety, use static analysis tools (e.g., Clang Static Analyzer, PREfast), enable Address Sanitizer (ASAN) in CI/CD pipelines, and consider using safer alternatives like C++/CLI with managed overlays where applicable.
• Medium · Custom Compression Library Implementation — src/CSVReader/ETLStackBrowse/ZL/. The codebase contains a custom implementation of deflate/gzip compression (ZL directory) rather than using well-tested standard libraries. Custom cryptographic and compression implementations are high-risk for security vulnerabilities including algorithmic weaknesses and implementation flaws. Fix: Replace custom compression implementation with well-maintained standard library implementations (.NET's System.IO.Compression or equivalent). If custom implementation is necessary for legacy reasons, conduct thorough security audit and fuzzing.
• Low · Incomplete Security Policy Documentation — SECURITY.md. The SECURITY.md file appears to be incomplete (truncated), which may leave unclear reporting procedures for security vulnerabilities. Clear security policies are essential for responsible disclosure. Fix: Complete and fully document the security.md file with complete MSRC reporting URLs, response time expectations, and supported versions. Ensure the file is comprehensive and accessible.
• Low · Dependency Management Clarity — src/Directory.Packages.props. While Directory.Packages.props is present for centralized package management, the actual dependency versions are not visible in the provided file structure. This makes it difficult to assess if vulnerable dependency versions are being used. Fix: Regularly audit dependencies using tools like OWASP Dependency-Check or Snyk. Implement automated dependency scanning in CI/CD pipeline (which appears to exist in .azuredevops and .github/workflows). Keep all NuGet packages updated to latest secure versions.
• Low · No Explicit Input Validation Pattern Visible — src/CSVReader/, src/CSVReader/ETLStackBrowse/. The file structure shows ETL file parsing (ETLStackBrowse) and CSV reading components, which handle external file formats. Without visible input validation patterns, there's risk of malformed file handling. Fix: Implement robust input validation for all external file formats (ETL, CSV). Use schema validation, size limits, and handle malformed data gracefully with appropriate error messages. Add fuzzing tests for file parsing.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.