{"componentChunkName":"component---src-templates-post-template-js","path":"/windows-windbg-008-time-travel-debugging-en","result":{"data":{"markdownRemark":{"id":"ee6c8117-37a0-5022-b908-06440cc749cb","html":"
\n

This page has been machine-translated from the original page.

\n
\n

My goal is to become proficient with WinDbg for Windows debugging and dump-based troubleshooting.

\n

This time, I’ll walk through the official Time Travel Debugging tutorial available in the UWP version of WinDbg Preview.

\n

Reference: Time Travel Debugging - Sample App Walkthrough - Windows drivers | Microsoft Docs

\n

For a full list of articles on Windows debugging and dump analysis with WinDbg, see the index page:

\n

Reference: Debugging and Troubleshooting Techniques with WinDbg

\n

This article covers the following topics.

\n\n

Table of Contents

\n\n

What Is Time Travel Debugging?

\n

The Time Travel Debugging (TTD) feature allows users to record the behavior of a running process and replay it forward and backward afterward.

\n

Reference: Time Travel Debugging - Overview - Windows drivers | Microsoft Docs

\n

Using TTD provides the following advantages:

\n\n

On the other hand, recording a TTD trace requires significant overhead — even a few minutes of recording can consume gigabytes of storage.

\n

TTD is available in WinDbg Preview, but it can also be used in Visual Studio.

\n

Reference: Introducing Time Travel Debugging for Visual Studio Enterprise 2019 - Visual Studio Blog

\n

Files Created by TTD

\n

During a trace, the following three files are typically created:

\n\n

The .idx and .run files in particular can become very large depending on how long the trace runs.

\n

What TTD Cannot Do

\n

As of WinDbg Preview at the time of writing (October 17, 2021), the following three things are not supported by TTD:

\n\n

In particular, because TTD traces are read-only, techniques common in live debugging — such as setting a breakpoint at a conditional branch and modifying a register to redirect execution to an arbitrary address — are not available in TTD.

\n

Tutorial: Preparing the Sample Program

\n

Let’s start working through the official TTD tutorial.

\n

Reference: Time Travel Debugging - Sample App Walkthrough - Windows drivers | Microsoft Docs

\n

The environment used for this tutorial:

\n\n

For the sample program, I used a version cross-compiled with llvm-mingw rather than Visual Studio.

\n

The sample program source code and compilation environment are described in the following article:

\n

Reference: How to Generate Symbol Files (.pdb) in a Linux Environment Using llvm-mingw

\n

The sample program I used looks like this:

\n
#include <array>\n#include <cstring> \n#include <stdio.h>\n#include <string.h>\n\nvoid GetCppConGreeting(wchar_t *buffer, size_t size)\n{\n    wchar_t const *const message = L\"HELLO FROM THE WINDBG TEAM. GOOD LUCK IN ALL OF YOUR TIME TRAVEL DEBUGGING!\";\n\n    wcscpy_s(buffer, size, message);\n}\n\nint main()\n{\n    std::array<wchar_t, 50> greeting{};\n    GetCppConGreeting(greeting.data(), sizeof(greeting));\n\n    wprintf(L\"%ls\\n\", greeting.data());\n\n    return 0;\n}
\n

Running the executable (ttd_sample.exe) — created based on the official tutorial source code — from PowerShell causes the program to crash abnormally for some reason.

\n

\n \n \n \n \n \n \n \n \n

\n

The application runs and the fault is reproduced. The TTD trace has been captured at this point, so click Terminate process to stop the application.

\n

\n \n \n \n \n \n \n \n \n

\n

When the application terminates, the TTD trace replay starts automatically with the Timeline positioned at the beginning.

\n

You are now ready to start troubleshooting with TTD.

\n

\n \n \n \n \n \n \n \n \n

\n

You can analyze the TTD trace directly from here, but let’s take the opportunity to open the saved trace file for analysis.

\n

Close WinDbg and relaunch it with administrator privileges.

\n

From the File menu, select Open trace file and open the .run file that was created.

\n

\n \n \n \n \n \n \n \n \n

\n

The trace file is now loaded into WinDbg and ready for analysis.

\n

Troubleshooting with TTD

\n

From here, analyze the captured trace file to perform troubleshooting.

\n

Loading the Symbol File

\n

The official tutorial starts by loading the symbol file path into WinDbg.

\n

In my environment, ttd_tutorial.pdb is placed on the Desktop, so I use .sympath+ <desktop path>.\nAfter adding the symbol file path, run the .reload command.

\n
.sympath+ C:\\Users\\Tadpole01\\Desktop\n.reload
\n

When the symbol file is loaded correctly, WinDbg can interpret and display function names and other symbols for ttd_tutorial.exe, as shown in the image below.

\n

\n \n \n \n \n \n \n \n \n

\n

Supplementary Note: About ESP and EBP

\n

Let me briefly touch on some computer architecture concepts.

\n

When a function is called on a computer running a CPU with an x64 architecture or similar, the CALL instruction is used.

\n

Simply put, the CALL instruction performs the following steps:

\n\n

Reference: Understanding the x86-64 processor stack - Qiita

\n

For more details, please refer to the following article:

\n

Reference: Overwriting the Memory Pointed to by the Stack Pointer in WinDbg to Execute an Arbitrary Function

\n

Identifying the Root Cause

\n

As confirmed earlier, the address indicated by the BSP register pointed to a string.

\n

In a program like this sample, the address stored in BSP is expected to be the address of the instruction called after main finishes.

\n

So where exactly did the stack get corrupted? Let’s find out.

\n

Set a breakpoint on the main function with the following command, then press Go Back to rewind time.

\n
bu ttd_tutorial!main
\n

Execution stops at the top of main. Step forward with Step Into until a memory address is pushed onto BSP.

\n

Inspecting memory immediately after the address is pushed onto BSP shows that at this point it still contains an instruction address (not yet a string) — the address of the instruction to be called after main finishes.

\n

\n \n \n \n \n \n \n \n \n

\n

Stepping forward several times with Step Over while comparing the Disassembly and Memory windows, it becomes clear that the stack was corrupted immediately after calling the GetCppConGreetingPwy function.

\n

Before stack corruption

\n

\n \n \n \n \n \n \n \n \n

\n

After stack corruption

\n

\n \n \n \n \n \n \n \n \n

\n

This identifies the GetCppConGreetingPwy function as the source of the stack corruption.

\n

Debugging the GetCppConGreetingPwy Function

\n

I rewound the TTD trace a little and stepped through the GetCppConGreetingPwy function.

\n

It turns out the stack was corrupted immediately after calling wcscpy_s.

\n

\n \n