Windows Event Tracing (ETW): Architecture and Practical Tracing

When a Windows application slows down, an error log may say what failed without showing which system activity led to it. Event Tracing for Windows (ETW) is a built-in instrumentation and collection system for examining operating-system and application events, often at a finer level than ordinary event logs. This guide explains its architecture, how trace data moves from providers into a session, and how to capture a short performance trace with Windows Performance Recorder (WPR).

What Is Event Tracing for Windows?

ETW is a Windows tracing facility that lets instrumented software publish structured events. A controller can enable a provider for a specific tracing session, collect selected events to a file or consumer, and stop the session without restarting the application. Microsoft describes ETW as a kernel-level tracing facility, but providers can report both operating-system and application-defined events; it is not limited to kernel internals.

The useful distinction is that ETW is a mechanism for producing and collecting diagnostic events, not a single monitoring dashboard or a log format that explains itself. A trace contains timestamps, provider identity, event identifiers, and provider-defined payloads. An analysis tool interprets those events using metadata and symbols. The Microsoft overview of Event Tracing describes this model and the controller, provider, and consumer roles.

ETW is used in Windows performance investigations because it can capture related activity across applications, the kernel, and hardware-facing components. Developers can add instrumentation to their own programs, while administrators can record selected system profiles with tooling such as the Windows Performance Toolkit. A useful trace is scoped to a question: broad event collection can create large files, add overhead, and make the result harder to interpret.

The Problem ETW Solves

Traditional logs usually record events that an application or service has decided are important for operations: a service stopped, a user signed in, or a request failed. They are valuable for auditing and for understanding discrete failures, but they may not include the timing and volume of low-level activity needed to explain a performance regression.

ETW supports a different workflow. A program can include event-writing code while leaving the provider disabled during normal use. When an investigation begins, a controller enables the relevant provider and session; when it ends, the controller stops and saves the trace. This makes it possible to collect detailed evidence during a short reproduction instead of permanently writing every diagnostic event.

That does not make ETW a replacement for Windows Event Log. Event Log channels store durable operational records and are commonly queried or forwarded for ongoing monitoring. ETW sessions are typically configured for a particular trace, with event selection, buffering, and file or real-time delivery chosen for that capture. A program can publish events using ETW-related APIs, but the collection path and purpose determine whether those events are part of a trace session, an event log, or both.

How ETW Works

The basic event path is:

Provider → enabled session → buffers → trace file or real-time consumer → analysis

A provider is an application, service, driver, or Windows component that emits events. A controller starts and configures a session, enables providers, and sets options such as the output file and buffer behavior. The session selects and manages event collection. A consumer reads events from a running session or a saved trace. The same application can act as both provider and controller, and a session can enable multiple providers.

As events arrive, ETW writes them into memory buffers and periodically flushes those buffers to the configured destination. Buffer size, event rate, consumer speed, and storage throughput affect whether the capture keeps up. If events are lost, the resulting trace can be incomplete; a missing event is not proof that the event never occurred. Microsoft’s ETW session documentation explains session responsibilities, including buffer management and event delivery.

ETW supports file-mode and real-time collection. They are different delivery choices, not guarantees about whether the trace is complete or low overhead:

The Windows Performance Toolkit documentation describes WPR as a recorder for ETW-based profiles and Windows Performance Analyzer (WPA) as a tool for inspecting the result. WPR hides much of the low-level session configuration behind profiles, which makes it a practical starting point when the question is about system performance rather than writing a new ETW provider.

Components and Key Concepts

Providers and event schemas. A provider identifies the source of events; the event schema describes what each event means and how to decode its fields. Common provider styles include manifest-based providers, TraceLogging, legacy MOF providers, and WPP. They differ in how they register, describe, and encode events. For new Windows application instrumentation, developers should choose a supported provider approach and publish enough metadata for consumers to interpret the payload. Microsoft’s guide to providing ETW events covers provider behavior and event schemas. The Windows classic samples repository is a Microsoft project containing examples of Windows desktop API usage; samples are starting points, not a substitute for checking current API documentation.

Controllers and sessions. A controller chooses which providers to enable and how to record their events. A session is the configured collection context. Several sessions can run at once, but the system has limits, and sessions may compete for resources or provider access. Use an existing profile when it answers the question; custom sessions should be deliberate about provider selection, keywords, levels, and duration.

Buffers and lost events. ETW buffers absorb bursts between event production and flushing. Too little capacity, a high event rate, slow storage, or a consumer that cannot keep pace can lead to lost data. A long recording with every available provider enabled is usually a poor first step. Keep the capture brief, record only providers relevant to the hypothesis, and check the trace and tool output for loss indicators.

Trace files and analysis. ETL files store event data, but they are not ordinary text logs. WPA can organize events into tables and graphs, correlate activity, and expose timing relationships. Other tools can consume traces programmatically. Useful analysis depends on symbols, event metadata, and knowledge of the workload; simply opening a large trace does not identify the root cause.

ETW and distributed tracing. ETW captures events within Windows and applications that emit ETW events. It does not automatically propagate a request identity across network services. The W3C Trace Context specification standardizes HTTP headers for carrying distributed trace context between services. That specification is not an ETW format: application-level distributed traces and ETW traces can complement each other, but answer different questions.

Real-World Use Cases

• Diagnosing a slow application: Record CPU scheduling, disk, memory, or application events around a repeatable slowdown, then use WPA to compare the sequence and duration of activity.
• Investigating startup or shutdown delays: Capture a bounded boot or service-start scenario to identify long operations and dependencies. Use a purpose-built profile rather than leaving a broad trace running indefinitely.
• Understanding a Windows component: Enable the relevant provider for a controlled reproduction to see what a component reports. For example, Windows DNS Server architecture explains that DNS analytical logging uses ETW; a trace can provide context for how that instrumentation fits into broader diagnostics.
• Building application instrumentation: Developers can emit events around important operations, include useful fields, and enable them only when needed. Consistent event names and schemas make later analysis more practical.
• Investigating Windows event records: Event Log analysis remains the right tool for many operational and audit questions. The Windows Event Log analysis and monitoring guide covers channels and durable records, while ETW is useful when a short, detailed performance trace is needed.
• Comparing operating-system tracing approaches: Linux administrators may encounter eBPF observability and network tracing, which instruments supported Linux kernel hooks. The concepts overlap at a high level, but ETW and eBPF have different APIs, security models, and event pipelines.

Getting Started with WPR

WPR and WPA are included in the Windows Performance Toolkit, which is available through the Windows Assessment and Deployment Kit (ADK). Install only the components needed for performance recording and analysis. On a machine where the tools are already installed, open an elevated PowerShell or Command Prompt and list the profiles available on that system:

wpr -profiles

Choose a built-in profile that matches the investigation. The following example uses GeneralProfile, if it is listed, and records to a file. Reproduce the issue briefly, then stop the recording and save the ETL file to the current user’s desktop:

wpr -start GeneralProfile -filemode

# Reproduce the performance issue, then stop the recording.
wpr -stop "$env:USERPROFILE\Desktop\etw-capture.etl"

If GeneralProfile is not listed or does not cover the needed events, use a suitable profile shown by wpr -profiles and consult wpr -help start for the installed version’s options. WPR may require elevation for profiles that collect system-wide events. Avoid recording longer than necessary: ETL files can contain process names, paths, and other operationally sensitive details, so store and share them with the same care as diagnostic logs.

Open the resulting ETL file with Windows Performance Analyzer and examine the tables related to the question, such as CPU usage, disk activity, or process lifetimes. Compare the relevant time range with the moment the issue occurred, and check for lost events before drawing conclusions. Microsoft’s WPR command-line reference documents profile discovery, start, status, and stop operations.

For a first investigation, write down one testable question, capture only a short reproduction, and compare the trace with application-level timing or Windows Event Log records. If a recording fails to start, verify that WPR is installed, the selected profile exists, the terminal has the required permissions, and another active recording is not occupying the session. If the ETL is empty or incomplete, confirm that the profile enables providers for the workload and inspect WPR/WPA diagnostics for dropped events before expanding the capture.

Common Misconceptions

“ETW is just another name for Windows Event Log.” The systems can share provider technology and related APIs, but they have distinct collection and retention models. Event Log is designed around named channels and durable records; an ETW session is configured to capture selected events for real-time consumption or trace analysis.

“ETW tracing has no performance cost.” ETW is designed for efficient tracing, but enabling providers still consumes CPU, memory bandwidth, storage, and analysis time. Broad or high-volume captures can affect the workload or lose events. Measure the impact and keep the trace scoped.

“A trace contains every event that happened.” A trace contains what enabled providers emitted and the session successfully collected. Providers may not expose the needed event, the chosen profile may omit it, or buffers and consumers may fail to keep up. Treat the trace as evidence with coverage limits, not a complete recording of the machine.

Related Articles

• Windows Event Log Analysis and Monitoring
• Windows DNS Server Architecture
• eBPF Observability: How Kernel Tracing Works
• Linux Performance Tuning: A Measurement-First Guide

Changelog and Last Updated

Last updated: October 25. Initial publication.