ETL File Documentation

Summary

An Event Trace Log file is a binary log written by Event Tracing for Windows (ETW), the high-speed logging framework built into Windows since Windows 2000. A .etl holds time-stamped, low-level events (CPU, disk, boot, driver, and network activity) packed for tooling, not reading, so its MIME type is application/octet-stream. Open it with Event Viewer, Windows Performance Analyzer, or PerfView, or run tracerpt to export text.

Technical details

Feature	Value
Full name	Event Trace Log (Event Tracing for Windows)
File extension	`.etl`
MIME type	`application/octet-stream`
Format type	Binary trace log — buffered stream of ETW events
Developer	Microsoft
Introduced	Windows 2000 (ETW framework)
Category	System / diagnostic log
Buffer header	`WMI_BUFFER_HEADER` at the start of every buffer
Logfile header	`TRACE_LOGFILE_HEADER` in the first buffer (OS build, clock resolution)
Buffer alignment	Fixed-size buffers (commonly 64 KB); events 8-byte aligned
Byte order	Little-endian (x86/x64 Windows)
Magic number	None constant — identified by internal logfile header, not a byte signature
Open standard	No — Microsoft-defined
Created by	WPR, xperf, logman, `netsh trace`, PerfView, Windows itself
Read with	Event Viewer, WPA, PerfView, `tracerpt`
Text export	`tracerpt file.etl` → `dumpfile.xml` + `summary.txt` (or `-of CSV`)
Convert to	`.evtx` (Event Viewer), `.xml` / `.csv` (tracerpt)
Typical location	`C:\Windows\System32\LogFiles\WMI\`, WPR/SleepStudy captures
Related extensions	`.evtx`, `.evt`, `.etlx`, `.blg`, `.dmp`
Specification	`learn.microsoft.com/windows/win32/etw/`

Structure at a glance

An .etl has no constant magic-byte signature. It is a sequence of fixed-size buffers, and each buffer opens with a WMI_BUFFER_HEADER holding the buffer size and a saved-offset marking how many bytes are valid. The first buffer additionally carries a TRACE_LOGFILE_HEADER event that records the OS version and build, the trace start time, the clock resolution, and the number of buffers. Because these buffers are flushed verbatim, the buffer header recurs throughout the file. Identify an .etl by its extension and by opening it in an ETW tool, not by a leading byte string.

What is an ETL file?

ETL stands for Event Trace Log, the on-disk output of Event Tracing for Windows (ETW). ETW is the kernel-level logging framework Microsoft added in Windows 2000, and it is still the backbone of Windows diagnostics today. A provider (the operating system, a driver, or an application) emits events; a controller starts a trace session with buffers; and a consumer or the session itself flushes those buffers to an .etl file. The result is a dense, time-stamped record of what the machine was doing, written with very low overhead so that even high-frequency events like context switches or disk I/O can be captured live.

An .etl is binary by design. Open one in Notepad and you see garbage, because the format packs raw event structures back to back with no text framing. It is meant to be decoded by tooling: Event Viewer for a quick look, Windows Performance Analyzer (WPA) or PerfView for graphical timelines, and the built-in tracerpt command for exporting XML or CSV. One naming caution: this ETL is unrelated to the data-warehouse term ETL (Extract, Transform, Load), which is a process, not a file format.

Buffers and the WMI_BUFFER_HEADER

The fundamental unit of an .etl is the buffer, not the event. ETW writes events into fixed-size in-memory buffers (commonly 64 KB), and when a buffer fills or the session flushes, that buffer is written to the file exactly as it sat in memory. An .etl is therefore a concatenation of these buffers, and every buffer begins with the same fixed-size WMI_BUFFER_HEADER.

WMI_BUFFER_HEADER (per buffer)
  Wnode.BufferSize   : total bytes of this buffer (offset to the NEXT buffer)
  Wnode.SavedOffset  : count of valid bytes actually used in this buffer
  Wnode.CurrentOffset: write cursor within the buffer
  Wnode.TimeStamp    : when the buffer was written
  ClientContext      : clock type, processor, alignment
  ... padding to the buffer boundary ...

Two fields make the file walkable. BufferSize is effectively the offset to the next buffer: add it to the current buffer's start and you land on the following WMI_BUFFER_HEADER. SavedOffset tells a reader how many of those bytes hold real event data versus trailing padding, since a buffer flushed early is not full. Because buffers are flushed verbatim, this header structure recurs from the start of the file to the end, and a parser can skip an entire buffer it does not care about by jumping BufferSize bytes.

The logfile header: TRACE_LOGFILE_HEADER

The very first buffer is special. After its WMI_BUFFER_HEADER comes a logfile-header event carrying a TRACE_LOGFILE_HEADER structure, which describes the trace as a whole rather than any single event. A consumer reads this before anything else to learn how to interpret the rest of the file.

TRACE_LOGFILE_HEADER (first buffer only)
  BufferSize        : buffer size used by this session
  Version / ProviderVersion : ETW + OS build numbers
  NumberOfProcessors
  TimerResolution / CpuSpeedInMHz
  BootTime / StartTime / EndTime
  BuffersWritten / BuffersLost / EventsLost
  PointerSize       : 4 or 8 (32- vs 64-bit capture)
  TimeZoneInformation

The header records the OS version and build, the number of processors, the clock resolution, and how many buffers were written or lost. The PointerSize field matters for decoding: a trace taken on 64-bit Windows stores 8-byte pointers, and a reader must know that to parse pointer-sized fields in later events. The presence of this header is also how tools recognise the file as a genuine ETL rather than guessing from a magic number, which the format does not have.

Events within a buffer: headers and payloads

Inside a buffer, after the buffer header, sit the events. Each event is a variable-size block that begins with its own fixed header (for modern manifest-based providers this is an EVENT_HEADER, for older classic providers a SYSTEM_TRACE_HEADER or EVENT_TRACE_HEADER). The header names the provider, the event ID and version, the level and keyword flags, the CPU that logged it, and a high-resolution timestamp; the payload that follows is the event's own data, whose layout is defined by the provider.

Events are 8-byte aligned within the buffer, so a reader advances event by event using each header's size field. Crucially, the payload is only self-describing if the consumer has the provider's schema. Manifest-based providers register an XML manifest that maps an event ID to named, typed fields; without it, a tool can still show that an event occurred and its raw bytes, but not friendly field names. This is why a third-party .etl sometimes displays events with numeric IDs and no readable descriptions: the decoding metadata (the manifest, or a TMF file for WPP tracing, or matching symbols) is not present on the analysing machine.

Providers, GUIDs and decoding metadata

Every event is tagged with the GUID of the provider that emitted it. A single .etl can interleave events from dozens of providers (the kernel, the disk stack, TCP/IP, a specific driver), all multiplexed through the same session buffers. Decoding turns those GUIDs and event IDs back into meaning through one of three metadata paths.

Provider style	Decoding metadata
Manifest-based (modern ETW)	Registered XML manifest mapping event ID → typed fields
WPP software tracing	TMF (Trace Message Format) files generated at build time
Kernel / classic providers	Built-in schemas plus symbols (PDB) for stack resolution

For CPU sampling and stack walks, the raw events carry return addresses, not function names. Resolving those into a readable call stack needs symbol files (PDBs) for the modules involved, which is why WPA and PerfView prompt for a symbol path and often download from the Microsoft symbol server. The .etl stores the addresses and the module list; the symbols live outside the file.

Reading an ETL and exporting readable text

Because the file is binary buffers, you need an ETW consumer to make sense of it. Event Viewer opens a saved .etl through Action › Open Saved Log and can convert it to the EVTX event-log format for browsing alongside normal Windows logs. WPA (from the Windows Performance Toolkit) renders CPU, disk, and boot activity as graphical timelines. PerfView is a free Microsoft profiler strong on CPU and .NET traces.

For plain text, the built-in command is tracerpt. Running tracerpt yourfile.etl writes dumpfile.xml (a structured dump of every event) plus summary.txt; adding -of CSV produces a spreadsheet-friendly table. The exported report is a derivation of the trace, not the trace itself: it flattens the decoded events into text, discarding the buffer structure. There is no meaningful conversion of an .etl to a document format like PDF beyond printing such a report.

Where ETL files come from, and deleting them

Most people never deliberately create an .etl: Windows writes them on its own. Diagnostic traces accumulate under C:\Windows\System32\LogFiles\WMI\, the SleepStudy and energy reports produce them, and Windows Performance Recorder (WPR) captures save them. Support engineers frequently ask a user to run a trace with netsh trace, logman, or WPR and send back the resulting .etl.

These files are passive data and safe to delete when you no longer need them; Windows recreates active ones as required. The one file you should not delete is one a running trace session is currently writing to. There is also a privacy dimension: a trace can capture file paths, URLs, process names, and other details that were in memory, so an .etl should only be shared through trusted support channels rather than posted publicly.

ETL versus EVTX, and the etlx cache

ETL and EVTX are easy to confuse because both are Windows logs read in tools. EVTX is the standard Windows Event Log format: a smaller set of higher-level, human-oriented records that Event Viewer shows by default. ETL is the lower-level, high-frequency trace stream from ETW, aimed at performance and deep diagnostics, and it can hold orders of magnitude more events. Event Viewer bridges the two by opening an .etl and offering to save it as .evtx.

A related file is the .etlx. PerfView and some tools convert an .etl into an .etlx, an indexed, seekable cache of the same trace that supports random access and repeated queries without re-parsing the raw buffers each time. The .etlx is a derived index, not a replacement for the original capture.

References

Feedback

Was this page helpful?

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.

Table of contents