Introduction
This document takes a look at Event Tracing for Windows (ETW), it’s purpose and the resulting ecosystem that is available to interact with it.
What Is it
Event Tracing for Windows (ETW) is an efficient kernel-level tracing facility that lets you log kernel or application-defined events to a log file. You can consume the events in real time or from a log file
As seen in the above diagram, ETW is broken into four main components:
Controllers
Controllers provide the ability to start and stop event tracing sessions and enable or disable the providers that will log events into a given session.
Providers
Providers are what log events to sessions. They can either be enabled (logging events) or disabled (not logging events) by a controller. There are four main types of providers:
- MOF (classic) providers
- WPP providers
- Manifest-based providers
- TraceLogging providers
For a given provider, each type of event that can be logged has a corresponding schema, referred to as a manifest.
Sessions
Event sessions are what store the events coming from a set of providers, this can either go into an in memory buffer owned by the session or be routed directly into a log file (in the .etl
format).
Consumers
Consumers are any application/kernel that reads events from either as a live stream from a session or directly from a .etl
file.
Things to be Aware of
Structure & Schema of Events
The structure of a .etl
file and the events that make it up is not something that is published. It is intended that to access these events while in the .etl
format that one uses a Microsoft tool, such as tracerpt
, or one of Microsoft’s APIs. There’s two ways I’ve found so far to access ETW traces:
- Microsoft provided way to access Event Traces (live or from a logfile) via Trace Processing
- ETWDeserializer
- TraceEvent
ETW is strongly-typed in that each event has a specific schema (known as a manifest) for it’s event data. Event providers define that schema and make it available to consumers such that they can decode the event’s data. For a given .etl
file there is a corresponding manifest collection that contain the relevant manifests for the events. This manifest collection can either be embedded in the .etl
or sit to the side in an XML format. There’s no guarantee of the manifest being available. If not directly available, the decoder looks to see if the provider GUID’s in the event has a corresponding provider on the system that knows how to decode it.
Decoded event in XML (with known manifest):
|
|
Decoded event in XML (without known manifest):
|
|
You can see with the above event that in the case we don’t have a manifest, the raw event payload is shown. Were we to have a manifest describing how to interpret that EventPayload, we would be able to properly decode it.
Lost Events
Logging in ETW is asynchronous and with that comes the possibility of lost events. Events can be lost if (application specific):
- Events with size > 64k are lost
- ETW buffer size is smaller than total event size
- Consumer is too slow
- Disk is too slow
Useful Links
Event Tracing Overview + Walkthrough
Geoff Chappell Event Tracing Notes