Microsoft Open-Sources DxTimingCaptureLibrary for Live DirectX 12 ETW Profiling on Windows 10 and 11

Microsoft's DirectX Developer Blog announced the release on September 30, 2026, in a post by Austin Kinross, Engineering Manager for PIX. The library is on GitHub under the MIT license, and Microsoft says it works on all versions of Windows 10 and Windows 11.

What DxTimingCaptureLibrary actually is​

The library is built on Event Tracing for Windows (ETW), the low-overhead system Windows uses to collect detailed events from the operating system and applications. The D3D12 runtime, DXGI and the DirectX kernel all send ETW events when important work happens. The raw data is valuable, but it is hard to read, and it often has to be matched up across several providers before it tells you anything.

That matching is the library's job. The project README calls DxTimingCaptureLibrary a Windows ETW consumer. It decodes and correlates events from these sources:

• Direct3D 12
• The DirectX graphics kernel (LDDMCore/DXGK)
• The PIX event runtime
• DirectStorage
• The ETW system-config provider

Events from any other source are ignored. The library passes its results to your code through callback interfaces, so an engine or profiler does not have to parse raw ETW payloads itself.

Where the code came from matters. Microsoft says it took the code out of PIX Timing Captures and turned it into a standalone project. It also says all DirectX data shown in the PIX Timing Capture UI is available through the library. That is a claim about the data, not the product. You do not get PIX's interface, CPU sampling or the rest of the PIX tool in a static library.

Section summary: DxTimingCaptureLibrary is the part of PIX that turns DirectX ETW events into structured data, now open-sourced so your own tools can use it.

Why this is different from what PIX already offered​

PIX timing data could already be captured from inside a game. Microsoft's PIX blog documented programmatic Timing Captures, where PIXBeginCapture and PIXEndCapture can now be used to start and stop Timing Captures from code running in your title. That feature arrived with the 2303.02 release of PIX on Windows and version 1.0.230302001 of the WinPIXEventRuntime.

That route had requirements. The PIX team noted that timing captures use several ETW providers. This dependency requires your title to be running with administrator privileges to be able to take programmatic captures. A helper DLL also had to be loaded first, and WinPixTimingCapturer is shipped with PIX, and not with WinPixEventRuntime. PIX had to be installed on the machine, and the output was a capture file you opened later in PIX.

DxTimingCaptureLibrary works differently:

The privilege entry in the last column comes from the new library's README. It says that starting a real-time ETW session and enabling the DXGK provider requires administrator rights or membership in the Performance Log Users group. Studios that don't want to run test builds fully elevated get a little more room.

Section summary: PIX captures data to a file for later review. DxTimingCaptureLibrary delivers it live to your code, and you decide what to do with it.

The data you can get​

The announcement and the README together describe a wide range of data:

• GPU timing. Top-of-pipe and bottom-of-pipe timestamps for each command-list work item. The driver fills them in through D3D history buffers. The README also lists command-list spans and submission details.
• GPU engine activity. Other processes' GPU work, and how it relates to your own.
• API object lifetimes. Creation and destruction times, debug names, descriptions, placement, size and GPU virtual addresses for resources, heaps, pipeline states and other D3D12 objects.
• Residency and paging. Make-resident, evict, page-in, page-out, migration and segment changes, each tied to specific D3D12 objects. The data also covers per-adapter memory budgets and usage, and migration failures, including those caused by VRAM fragmentation.
• DirectStorage. Files, queues, reads, status notifications, fence signals, event signals and submissions.
• D3D12 runtime failures. Error logs with timestamps, error codes, thread IDs and messages.
• Pipeline-state compilation. Start and end times for PSO compilation.
• Displays. Monitor information and VSync timestamps.
• PIX runtime data. WinPixEventRuntime markers on CPU and GPU timelines, custom counters and memory events.
• Diagnostics. ETW data-loss notifications and processing problems the library recovered from.

The residency data is especially useful for PC developers. Unexplained stutter on an 8 GB card is often caused by the kernel quietly paging resources out of VRAM. Having that visible in an in-engine overlay, tied to named resources, could shorten a lot of debugging sessions.

An important asterisk on PIX markers​

The announcement lists WinPixEventRuntime markers among the available data, but the README adds a qualification. The repository ships with a stub PIX event decoder, so PIX markers are not decoded by default. To decode them, replace lib/PixEventDecoderStub.cpp with the real decoder from Microsoft's pixevents project. If your markers don't appear right after you clone the repo, this is the cause.

Getting started: the integration workflow​

Microsoft's high-level steps are:

1. Create and configure an ETW session with the relevant DirectX providers. Provider GUIDs and keyword flags for EnableTraceEx2 are in <DxTimingCaptureLibrary/EtwProviders.h>.
2. Route the session's event callback so that each EVENT_RECORD is forwarded to DxTimingCaptureEventHandler::HandleEventRecord.
3. Implement the callback interfaces you need. Every callback is optional, and empty slots fall back to no-op implementations.
4. Wait for callbacks as matching events arrive. After ProcessTrace returns, call OnDataComplete() on the handler to flush any pending data.

The settings you must not skip​

The README gives one requirement that decides whether your numbers mean anything. The ETW session must use raw QPC timestamps. Set PROCESS_TRACE_MODE_RAW_TIMESTAMP on the trace and Wnode.ClientContext = 1 on the session. Without these, the README says, the timing data will be wrong. The basic sample shows the full setup.

Other integration details from the README:

• Callback lifetime. The handler does not own your callback objects, so they must outlive it.
• Tracking options. DxTimingCaptureLibraryOptions has TrackApiObjects, TrackGpuTiming and TrackGpuEngineActivity switches for the more expensive tracking work. Set them to match the ETW provider keywords you actually enable.
• Scope. The target process ID limits API-object, residency and runtime-failure data to that process. GPU timing can include multiple processes. GPU engine activity is always machine-wide.
• Exception safety. The quickstart wraps HandleEventRecord in a try/catch and warns against letting a C++ exception unwind through ProcessTrace's C frames.
• Linking. The simplest option is to add lib/DxTimingCaptureLibrary.lib.vcxproj to your solution. If you link the prebuilt .lib instead, match the CRT: Debug uses /MDd and Release uses /MD. You also need include paths for include/, third_party/PixEventDecoder/include/, and the D3D12 Agility SDK headers (for d3d12.h and D3D12Events.h).
• Offline analysis. To process a recorded .etl file instead of a live session, the README points to the --etl option in the Perfetto sample.

Build prerequisites​

You can build the x64 Debug or Release configuration in Visual Studio. From a Developer Command Prompt, use msbuild DxTimingCaptureLibrary.sln /restore /p:Configuration=Debug /p:Platform=x64.

The blog says the library works on all versions of Windows 10 and 11, but the repository's documented build target is x64 only. The documentation does not cover Arm64 builds, so treat Arm64 as untested until the project says otherwise.

The samples, and which one to open first​

• Basic event logging / residency logging. The best starting point. It prints output from every callback and shows the full setup: creating a real-time ETW session, enabling providers, feeding events to the library, handling errors and reporting data loss. An optional mode logs only residency and paging events. Run it as DxTimingCaptureLibrary.sample.exe [processId].
• D3D12 journal entries. Records a deliberately invalid CopyBufferRegion() call and shows the runtime-failure callback reporting it. Microsoft says this gives less detail than the D3D12 debug layer but more than the standard D3D12 error, and it works on retail runtimes without the debug layer. That makes it useful for field telemetry, where the debug layer is not available.
• Perfetto. Turns GPU timing callbacks into a Perfetto trace. Each command list's top-of-pipe and end-of-pipe timestamps appear on the GPU timeline, linked to the CPU-side marker where the work was recorded. It also shows other processes' GPU work, which helps when something outside your game is competing for the GPU. It works on live sessions or saved ETL files.
• Memory map / treemap. Draws treemaps of resource and heap usage in system memory and video memory. Microsoft labels it a work in progress. The README says it misses some resources and doesn't yet handle resources moving between system and video memory.
• ETL processor. Dumps lower-level data from saved traces: D3D12 device PIDs, raw history-buffer submissions as CSV, and outstanding dxgkrnl allocations. Microsoft says it is more useful to driver developers debugging GPU timing than to game developers.

On testing, the README says unit tests are deterministic and need no special hardware. Functional tests run against a live ETW session and need a D3D12-capable GPU and administrator rights, and the DirectStorage tests also need DirectStorage support.

Analysis: who benefits, and what to watch​

The main beneficiaries are engine teams that already maintain their own profiling overlays. They can now add kernel-level residency data, driver-populated GPU timestamps and retail-safe runtime error logs without writing their own ETW decoders, which is slow and fragile work. The MIT license also means middleware vendors and open-source tools can ship the code without legal complications.

Some caveats:

• This is a first release. When the repository was inspected, it had a single commit. Expect changes to APIs and samples.
• Privileges still apply. Real-time sessions need administrator rights or Performance Log Users membership. That is manageable in a studio, but it limits any idea of collecting this data from players' machines.
• GPU timing depends on the driver. The timestamps come from driver-populated history buffers, so their accuracy depends on driver behavior. The ETL processor sample exists for driver developers chasing exactly these problems. PIX's own known-issues page has warned about timing-data errors on some GPU and driver setups, for example that on NVIDIA GPUs running recent drivers with Hardware Scheduling enabled, users could hit timing-data collection errors. Whether any of those problems apply to this library is not documented. The general point is that the data is only as good as the stack underneath it.
• Not everything works out of the box. PIX markers need the real decoder swapped in, and the memory treemap is unfinished.

The project is open to contributions. The README welcomes bug fixes, new samples and support for more ETW events or providers, and suggests opening an issue before larger changes. The team is also on the #pix channel of the DirectX Discord.

Bottom line: DxTimingCaptureLibrary won't replace PIX, and it isn't meant to. It gives D3D12 developers direct access to the data PIX Timing Captures show, so it can go into their own tools instead of a separate capture file. Before you trust any timing numbers, set the raw-timestamp options described above.