Event Tracing for Windows, commonly abbreviated as ETW, is the high speed tracing facility built into the Windows operating system. Introduced with Windows 2000, it provides a uniform, low overhead mechanism by which the kernel, device drivers, and user mode applications can emit structured diagnostic and performance events. Over more than two decades ETW has grown from a little known internal profiling aid into the backbone of performance analysis and security telemetry on every supported edition of Windows. Understanding its architecture, its buffering model, and the tools that consume its data is essential for anyone who diagnoses system behavior at scale, whether the goal is finding a latency regression in a driver or reconstructing the timeline of a security incident.
Origins and architectural goals
ETW shipped first in Windows 2000 as an instrumentation layer for Microsoft engineers who needed to measure kernel behavior without attaching a debugger. The design brief was demanding: tracing had to run on production servers, add only a small overhead percentage, and collect hundreds of thousands of events per second on busy systems. Earlier approaches such as printf style logging could not satisfy these constraints because formatting strings and writing text to disk costs far more than the phenomena being measured.
The architects solved this problem by separating event generation from event processing. A component that has something to report writes a compact binary record into an in memory buffer and moves on immediately. Formatting, filtering, and persistence are deferred to consumers that run later, often on a different machine entirely. This separation is the single most important idea in ETW and explains nearly every other design decision, from the use of manifests to describe event layouts to the choice of per processor buffers.
The subsystem has been extended in every major release. Windows Vista layered the Event Log service on top of ETW, Windows 8 expanded the kernel providers and added channel support in manifests, and Windows 10 made ETW a primary data source for cloud delivered security analysis. Throughout these changes the core programming contracts have remained stable, so a session configuration written for Windows Server 2003 still functions on current releases.
Providers controllers and consumers
The ETW programming model organizes participants into three clearly defined roles. A provider is any component that emits events. Providers exist at every level of the system: the kernel itself exposes providers for process, thread, disk, network, and memory activity; device drivers register their own providers; and user mode applications and runtimes such as the .NET Common Language Runtime, the JavaScript engine in Microsoft Edge, and SQL Server publish hundreds of specialized event sources. A provider registers with ETW at runtime using a unique GUID and then calls a small set of logging functions whenever something noteworthy occurs.
Controllers are tools that start, configure, and stop trace sessions. A controller decides which providers feed a given session, at what verbosity, and with which keyword filters. The logman command line utility, the wevtutil tool for event channels, and programmatic clients built on the StartTrace and EnableTraceEx2 functions all act as controllers. Controllers also choose buffering parameters, file paths for the event trace log, and whether a session is circular, sequential, or written to a global logger at boot.
Consumers read events from an active session in real time or open a recorded event trace log file afterwards. Consumers range from simple text dumpers to full analysis applications. The separation of roles keeps each component small and testable. Modern .NET code frequently implements consumers with the TraceEvent library, which automates manifest parsing and exposes strongly typed callbacks for thousands of known event types.
Manifests GUIDs levels and keywords
Because ETW events are stored as compact binary records, consumers need a schema to interpret them. Classic providers describe their events in an instrumentation manifest, an XML document compiled with the message compiler into a binary resource. The manifest declares the provider GUID, the events it can emit, and the type and meaning of every field in each event. Newer TraceLogging providers embed a self describing header inside each event record, removing the need to install a manifest on the analysis machine, which has made TraceLogging the preferred approach for newly written components.
Every provider is identified by a 128 bit GUID, and controllers use these identifiers when enabling providers. Well known GUIDs exist for the core kernel providers, while application specific providers publish their identifiers in documentation or header files. Because GUIDs are stable across releases, automation that targets a particular provider continues to work after operating system upgrades.
Filtering relies on two numeric fields attached to every event. The level is an integer that expresses severity or verbosity, conventionally ranging from one for critical conditions through five for verbose diagnostic chatter; a session that enables a provider at level four receives events at levels one through four. Keywords are 64 bit bitmasks that group events by functional area, such as thread scheduling, file input and output, or registry access, and a session may combine several keyword masks with bitwise operations. Together, levels and keywords let an analyst capture exactly the slice of activity under study, which keeps trace files small and keeps overhead proportional to the data actually needed rather than to everything a provider could emit.
Per processor circular buffers and low overhead
The performance character of ETW comes from its buffering design. Each active session maintains a pool of fixed size buffers, allocated by default per logical processor, into which events are copied as they are generated. Writing an event is little more than reserving space in the current buffer with an interlocked operation and copying the record, so the cost on the hot path is typically measured in single digit microseconds and often far less. No disk writes or string formatting happen inside the provider.
Sessions can operate in several buffering modes. A file session flushes filled buffers to disk in the background. An auto logger session starts at boot and records continuously. Circular buffering keeps a fixed ring of buffers in memory and overwrites the oldest data, which is ideal for flight recorder scenarios where only the final seconds before a failure matter; many diagnostics pipelines keep a lightweight circular session running permanently and stop it on demand when a problem is detected. Real time sessions hand buffers directly to a consumer thread with minimal latency.
End to end overhead is therefore configurable. A kernel session capturing process and thread events at default settings typically adds under five percent processor cost on a busy server, and keyword-filtered application sessions are often far cheaper. Measured results on multi core hardware routinely stay below the five percent design target because buffer allocation is per processor and requires no global locks. Buffer sizing, flush timers, and minimum and maximum buffer counts are all tunable through the controller APIs, giving operators explicit control over the memory footprint.
Xperf Windows Performance Analyzer and Sysinternals tooling
The most prominent consumer family is the Windows Performance Toolkit. Its command line recorder, formerly known as xperf and now invoked through wpr, starts and configures ETW sessions using profiles that describe common scenarios such as CPU sampling, disk input and output, or power transitions. The graphical analyzer, Windows Performance Analyzer, opens the resulting trace files and presents timelines, stacked sampled call graphs, and ready thread analysis views that reveal why a process stalled or why a boot took too long. Together these tools have been the standard answer to slow boot, slow logon, and high processor usage investigations across Windows client and server editions for well over a decade.
Xperf itself remains available in the toolkit and is still used by many engineers because of its scriptable provider syntax, including flags for stack walking that record the full call stack at the moment each event fires. Stack walking is what turns a raw list of compute intensive samples into an actionable attribution of processor time to specific functions, and it is a distinctive capability of the ETW consumer model because stacks are captured by the kernel through a provider flag and decoded by the consumer using symbol files.
The Sysinternals suite builds complementary tools on the same infrastructure. Process Monitor records file system, registry, and network activity and displays it in a filterable live view, while Process Explorer surfaces per thread processor usage. PerfView from the .NET team has become a favorite for managed code analysis, reading ETW events from the runtime to attribute allocation and garbage collection cost. This rich ecosystem exists precisely because ETW standardizes both event production and consumption.
Security telemetry role
Beyond performance work, ETW is the substrate on which modern Windows security monitoring rests. The Microsoft-Windows-Kernel-Audit and related providers emit events for process creation, image loading, and network connections, and the Sysmon service from Sysinternals packages these and other sources into a documented, XML filtered event stream that security operations centers worldwide collect and alert on. Event ID records such as process creation with the full command line have become canonical evidence in incident response.
Defender for Endpoint and its antimalware platform consume ETW providers, including a specialized threat intelligence provider added in Windows 10, to observe behaviors such as memory allocation into remote processes. The Antimalware Scan Interface uses ETW events to expose script content to scanning engines, closing a gap where obfuscated PowerShell once ran invisibly. Many third party endpoint detection products likewise subscribe to ETW channels because the data is authoritative: it comes from the kernel component that performed the operation rather than from an intercepted user mode call.
This prominence has also drawn adversarial attention. Attack tooling attempts to patch or suppress ETW functions inside a process so that malicious activity goes unrecorded, and Microsoft has responded with harder to tamper instrumentation. The practical lesson for defenders is to collect ETW telemetry at multiple layers, prefer kernel generated events where they exist, and monitor for the disabling of the monitoring itself, since an unexpected gap in an event stream is itself a signal worth investigating.
Practical guidance for engineers and analysts
Getting started with ETW requires only built in tools. The logman utility lists registered providers with their GUIDs, starts trace sessions, and converts binary logs to CSV or XML. The wevtutil tool manages publishers that channel events into the Windows Event Log. For programmable workflows the TraceEvent NuGet package or the krabsetw C++ library wrap the controller and consumer APIs in a few lines of code, and PowerShell exposes related cmdlets for channel configuration. A typical investigation follows a repeatable sequence.
- Identify the providers relevant to the problem using logman query providers or published documentation; choose levels and keywords that isolate the activity of interest while excluding routine chatter; start a session with explicit buffer counts and a file or real time delivery target.
- Reproduce the scenario while tracing is active, keeping the capture window as short as practical so that file sizes remain manageable and analysis timelines stay focused; include stack walking flags when attribution to call sites is required but remember that stack walking increases overhead and file size visibly.
- Stop and merge the trace, then analyze it in Windows Performance Analyzer, PerfView, or a programmatic consumer; correlate timestamps across providers to reconstruct cause and effect, and export key findings as evidence with their event identifiers.
- Where continuous coverage is needed, deploy a small circular buffer session or a Sysmon configuration under version control, and validate on representative hardware that sustained overhead stays within the agreed budget before rolling it out broadly.
ETW rewards this kind of discipline because it exposes the operating system with unusual honesty. Two decades after Windows 2000 first shipped it, the same three roles, the same GUID contracts, and the same per processor buffer pools carry the diagnostic and security observability of one of the most widely deployed operating systems in the world.