Time Travel Debugging (TTD) file size

One question we are frequently asked is "What is the size of the TTD files?". TTD uses trace and index files for the record and replay steps of TTD debugging. See the /en-us/windows-hardware/drivers/debugger/time-travel-debugging-trace-file-information for more information on working with TTD files.

• Trace (.RUN) file stores the recording of the code execution
• Index (.IDX) file is automatically created when opening the trace file in WinDbg Preview to replay and debug the problem

TTD trace files can get really big and it is important to ensure that you have adequate free disk space available.  If you record an app or process even just for a few minutes, the trace file may grow to be several gigabytes in size.  The size of the trace file is dependent on a number of factors described below.  We cannot estimate the exact trace file size but can provide a rule of thumb to help you understand TTD file sizes.

Trace file size factors

The following factors can affect the size of the trace file:

• The number of code instructions executed across all threads when recording the running app or process
• The length of time during which the app or process was recorded (only as this affects the number of code instructions recorded)
• The size of the memory data used by the app or process

The number of instructions executed and recorded is the biggest factor that affects the trace file size.  A trace typically requires between 1 bit and 1 byte per instruction executed.  A trace is likely to be towards the lower end of that range when the recorded program executes a smaller number of distinct functions and operates on a smaller set of data.  A trace is likely to be towards the higher end of that range when the recorded program executes a larger number of distinct functions or operates on a larger set of data.

Rule of thumb

• The trace file grows roughly 5MB to 50MB per second when recording an active app or process, depending on the trace file size factors identified above.
• The trace file will not grow when the app or process being recorded is idle (e.g., when waiting for input).
• Currently there is no maximum file size limit for trace files.  WinDbg Preview can replay trace files that are well into the hundreds of gigabytes in size.

The index file is automatically created by WinDbg Preview when you open a trace for the first time.  It contains information that helps the debugger to replay the trace and query information about memory more efficiently.  Its size generally ranges from 1 to 2 times the size of the trace file.  The factors that affect its size are similar to those that affect the size of the trace file.

First, the size of the index file scales relative to the length of the trace.  A trace that contains a larger number of recorded instructions will generally have a larger index.

Second, the size of the index scales relative to the breadth of the memory accesses.  If the program that was recorded frequently accessed a large number of distinct memory locations, the index will generally be larger than if the program that was recorded accessed fewer distinct memory locations or if accesses to memory locations was less frequent.

Since these factors are similar to the factors that affect the size of the trace file, the size of the index file generally scales relative to the size of the index file (thus our estimate that it's typically between 1x and 2x the size of the trace file).

Both the TTD trace and index files are written to disk. Currently there is not a maximum file size limitation for either the trace or index file. The trace file grows in size until you stop recording or exceed the amount of available disk space. So what happens if you run out of disk space? We are working on improving the experience during recording and indexing.

During recording: TTD will write out last page to the trace file and then effectively wait until it can write again. This is more graceful than crashing but results in recording being suspended without user feedback (error/warning message) on what is occurring. We will improve the feedback in the near future (i.e. stop recording gracefully, warning/error message). Running out of disk space during recording results in a trace file with an incomplete record of the code execution. The incomplete trace file can be opened in WinDbg Preview but it may not include the actual problem if the error occurs after running out of disk space when writing the trace file.

• Today: WinDbg shows the Recording dialog but does not show an error/warning message when running out of disk space during recording.
• Workaround: Open File Explorer and check if the disk (i.e. C: drive) Free space is near zero. Alternately watch the trace (.RUN) file in File Explorer (default in Documents folder) and if not regularly growing in size then recording may be waiting. Click the Stop and Debug button in WinDbg, free up space or save to another disk, and start recording again.

During indexing: The debugger may produce an invalid index file, resulting in unpredictable behavior in the debugger, or the debugger engine host may crash.

• Workaround:  Close the debugger and delete any index file (.idx) that may exist for your trace.  Either free up sufficient disk space, or move the trace file to a different disk with sufficient free space.  Open the trace again in the debugger and run !index to create a new, correct index.  Indexing does not modify the original trace file (.run), so no data will have been lost.

• Anonymous
  November 07, 2017
  Any thoughts on rolling this trace file? For example, specifying the number of files to keep and the size of each file? So let us say, we want 10 files, 100MB per file, then we will always just have the 10 latest files.windbg will need to understand how to handle this (in case you need a header or magic number or something), but it might make using this feature more useful for real-world applications. Just a thought.
  • Anonymous
    November 17, 2017
    Thanks for the suggestions. We have requests to limit individual file sizes but not much around limiting the number of most recent use (MRU) files to manage the disk space of TTD files. Feel free to add your suggestion to Feedback Hub so we can learn if others would find this useful too.See TTD FAQ page https://blogs.msdn.microsoft.com/windbg/2017/10/20/time-travel-debugging-faq/ for Feedback Hub instructions.