If you have ever wondered how a modern endpoint detection and response (EDR) product sees process creations, image loads, and PowerShell commands in near real time without installing a kernel driver for every single data source, the answer is almost always Event Tracing for Windows (ETW). ETW is the high-performance, kernel-supported tracing and logging facility built into Windows since Windows 2000, and it quietly underpins an enormous amount of the platform: the Windows Event Log, performance analysis tools like Windows Performance Recorder, and much of the telemetry that security products consume. This article dissects how ETW is architected, how events flow from the code that emits them to the tools that read them, and why ETW has become a battleground between attackers and defenders.
The ETW Architecture: Providers, Controllers, Consumers
ETW is built around three roles that are deliberately decoupled from one another, so that any of them can exist without the others being present at that moment:
- Providers emit events. A provider is a component — a service, a driver, a runtime, an application — instrumented to write events describing what it is doing.
- Controllers start and stop trace sessions and decide which providers are enabled into which session, and at what level and keyword filter.
- Consumers read the events, either live from a real-time session or later from a log file.
The decoupling is the key design insight. A provider does not know or care whether anyone is listening; when no session has enabled it, its event-writing calls are extremely cheap and effectively do nothing. Only when a controller enables the provider into a session do its events begin to flow. This is what makes ETW cheap enough to leave instrumentation permanently compiled into production code.
Providers
A provider is identified by a GUID and, usually, a friendly name. When a session enables it, the provider’s callback fires and it begins calling EventWrite (or the older TraceEvent) to emit events. Windows has accumulated several provider technologies over the years:
- Manifest-based providers — the modern standard. The provider ships an instrumentation manifest describing its events, and tools can decode events precisely because the schema is registered with the system.
- Classic (MOF) providers — the original WMI-era model, still present for legacy sources such as the NT Kernel Logger.
- TraceLogging — a self-describing format where the event schema travels with the event, so no separate manifest is needed.
A handful of providers matter enormously for security work:
- Microsoft-Windows-Threat-Intelligence (often called ETW-TI) — a kernel-sourced provider that reports sensitive operations such as memory allocation and protection changes in remote processes. It is restricted to protected (PPL) consumers and is a cornerstone of modern EDR sensing.
- Microsoft-Windows-Kernel-Process — process and thread creation, image loads.
- Microsoft-Windows-PowerShell — pipeline execution and, critically, script-block logging that captures deobfuscated PowerShell.
- Microsoft-Windows-DotNETRuntime — CLR events including assembly loads and JIT activity, valuable for catching in-memory .NET tradecraft.
Trace Sessions and Buffers
A trace session is the unit that ties providers to consumers. A controller creates one — for example through the StartTrace API — gives it a name, and enables one or more providers into it. As enabled providers emit events, the kernel writes them into a set of buffers owned by that session. Each session has its own buffer pool, sized by the controller, and the kernel flushes buffers either to a real-time consumer or to a log file as they fill or on a timer.
Sessions come in two broad flavours. A file-based session writes events into an .etl (Event Trace Log) file for later analysis — this is how performance traces are captured. A real-time session delivers events to a live consumer as they occur, which is how monitoring tools and EDRs operate. Because buffering happens in the kernel and delivery is batched, ETW can sustain very high event rates with low overhead. One practical constraint worth knowing is that the system supports only a fixed number of simultaneous logger sessions, so sessions are a finite resource that tools must share.
Consumers
A consumer reads events by calling OpenTrace to attach to a real-time session or an .etl file, then ProcessTrace to receive decoded event records through a callback. You rarely have to write that code yourself, because Windows ships a rich set of consumer tools:
- logman — create, query, start, and stop sessions from the command line.
- wevtutil and Get-WinEvent — query the Event Log channels that sit on top of ETW.
- tracerpt — convert
.etlfiles into readable reports (CSV, XML). - xperf / Windows Performance Recorder (WPR) and PerfView — heavyweight capture and analysis tools used for performance and deep tracing.
Crucially, the Windows Event Log service is itself just an ETW consumer. The familiar channels you browse in Event Viewer — Security, System, Application, and the many “Applications and Services Logs” — are ETW sessions whose events the Event Log service persists into .evtx files. Understanding this collapses two things that look separate into one: the Event Log is not a different system from ETW; it is one particular, always-on consumer of it.
The Autologger and Boot-Time Tracing
Some telemetry must be captured from the very first moments of a boot, long before any user-mode controller could start a session. ETW solves this with autologgers: persistent session definitions stored in the registry under HKLM\SYSTEM\CurrentControlSet\Control\WMI\Autologger. Each subkey defines a session — its buffer sizes, its enabled providers, and its output — that the system starts automatically during boot. The built-in EventLog-* autologgers feed the Event Log channels, and security products register their own autologgers so their sensor is capturing events before most of the system, and any malware on it, has started. Because these definitions live in the registry, their integrity matters: an attacker who can write to an autologger key with SYSTEM rights can weaken or disable a defender’s boot-time collection.
Inspecting ETW
ETW is entirely observable from built-in tools. The following commands are the core workflow for seeing what is being traced on a live system:
# List every active trace session (-ets = query event trace sessions)
logman query -ets
# List the providers registered on this machine (name + GUID)
logman query providers
# Show the providers enabled into one specific session
logman query "EventLog-System" -ets
# Enumerate all Event Log channels (which are ETW consumers)
wevtutil el
# Read the 5 most recent Security log events as text
wevtutil qe Security /c:5 /rd:true /f:text
# From PowerShell: enumerate providers and inspect one
Get-WinEvent -ListProvider * | Select-Object Name, Id
Get-WinEvent -ListProvider Microsoft-Windows-PowerShelllogman query -ets is the fastest way to see which sessions exist right now — including the ones a security product runs. logman query providers maps friendly names to GUIDs, which you need when enabling a provider or interpreting a raw trace. wevtutil el reveals just how many channels sit on top of ETW, and Get-WinEvent -ListProvider lets you drill into a single provider’s events and keywords.
Security Relevance
ETW is a double-edged sword, and both edges are sharp. For defenders, it is one of the richest telemetry sources on the platform. ETW-TI surfaces the memory operations behind process injection; Kernel-Process events reveal process trees and image loads; PowerShell script-block logging records commands after they have been deobfuscated; and .NET runtime events expose in-memory assembly loading. A great deal of modern detection engineering amounts to consuming the right providers and writing logic over their events.
Precisely because ETW feeds detection, attackers target it — a family of techniques collectively known as ETW patching or blinding. The best-known variant patches ntdll!EtwEventWrite in the attacker’s own process: because that function is the user-mode chokepoint through which a process reports its own events, overwriting its first instruction with a ret silences the process’s userland ETW output without affecting other processes. Related tactics include disabling PowerShell or AMSI providers, unhooking or tampering with a session’s enabled providers, and manipulating autologger registry keys to stop a provider such as ETW-TI from being collected at boot.
It is worth being precise about the limits of these evasions. Patching EtwEventWrite only blinds events a process emits about itself from user mode; kernel-sourced providers like ETW-TI are written from ring 0 and are not affected by a user-mode patch in the monitored process. That asymmetry is exactly why defenders lean on kernel-backed telemetry, and why they also monitor for the tampering itself — unexpected modifications to ntdll‘s ETW stubs, disabled providers, or changes to autologger configuration are themselves high-fidelity signals that something is trying to go dark. (All of this is described for defensive understanding and authorized testing only.)
Conclusion
Event Tracing for Windows ties together nearly everything this series has covered: providers emit events from the processes, threads, memory operations, and security decisions we examined earlier; the kernel buffers and routes them; and consumers — from Event Viewer to enterprise EDRs — turn them into visibility. ETW is where Windows internals stops being academic and becomes the raw material of both attack detection and evasion. Master the architecture of providers, sessions, and consumers, and you can reason clearly about what a defender can see, what an attacker can hide, and where the two meet. That makes ETW a fitting capstone to the foundations of this Windows Internals series.
You Might Also Like
This article is part of the Windows Internals series. These related deep-dives cover adjacent parts of the system:
Comments