ETW tracing

Diagnostics & logging distinguished durable history (Event Log) from high-volume, real-time tracing. This chapter is about that second category: ETW (Event Tracing for Windows) — the mechanism underneath both a great deal of Windows' own internal diagnostics and much of the Event Log service itself.

Three roles: controllers, providers, consumers

ETW's model splits cleanly into three participant roles:

• Controllers start and configure sessions — deciding which providers to enable, at what verbosity, and where the resulting trace data should go.
• Providers — the same general concept as in Providers & channels, though ETW providers can emit far more granular, higher-frequency events than what typically ends up in a durable Event Log channel — emit trace events into whatever active sessions have enabled them.
• Consumers read and process the resulting event stream, either live (as events are emitted) or from a captured trace file, for analysis.

This is a genuinely different shape than Event Log's simpler "provider writes, channel stores" model — ETW is built around the idea that tracing needs, and their associated performance cost, should be turned on deliberately and specifically, not run continuously by default the way durable logging effectively does.

Why volume, not just content, is the differentiator

The practical reason ETW exists as a separate mechanism rather than simply "more Event Log": genuinely useful diagnostic detail — every function entry and exit in a hot code path, precise timing of each step in a multi-stage operation — would be far too voluminous to persist durably, indefinitely, the way Event Log records are. ETW's session model lets you deliberately trade retention for resolution: turn on high-volume, high-detail tracing for a specific, bounded window of time (while reproducing a problem, for instance), capture everything at that resolution, then turn it back off — rather than either paying that overhead continuously, or never having that level of detail available at all.

A worked example: tracking a slow boot

A slow-boot investigation is a genuinely representative case for why you'd reach past Event Log toward ETW specifically: Event Log might tell you that a particular service took an unusually long time to start, or that some component logged an error during startup — useful, but coarse. An ETW boot trace can tell you, with fine-grained timing, the precise sequence and duration of each stage along the way: exactly which driver initialization, which service dependency wait, or which disk I/O operation actually consumed the bulk of the elapsed time. This is the kind of question — not just "did something go wrong" but "exactly where did the time go" — that ETW's resolution is specifically built to answer, and that Event Log's coarser, durable-summary model was never designed to.

A common mistake

Treating ETW as "just another log file, with a different name" misses what actually distinguishes it: it's a configurable, session-based tracing mechanism with its own performance and retention tradeoffs, not a passive, always-on record the way Event Log effectively behaves. Whether ETW data is available for a given moment in time depends entirely on whether a relevant session was actively running and capturing at that moment — unlike Event Log, where relevant channels are generally always being written to by default.

Where this connects

• The Windows Event Log is itself implemented, underneath, using ETW infrastructure — the two are related, not separate universes.
• Scheduling is exactly the kind of precise, timing-sensitive behavior ETW-based tracing is well suited to investigating, where Event Log's coarser granularity wouldn't be enough.