This is a nascent extension to our launcher for the Windows Debugger. The launcher itself - functions, but lacks full integration. In particular, Ghidra's concept of time is not mapped - directly to the TTD concept of time. TTD uses a major/minor scheme for ordering events, where - the major index changes when TTD must record a change in state. Events, including thread - creation/termination, module loads/unloads, syscalls, and other asynchronous changes, merit new - major indices. When you step forward or backward in a trace, the dbgeng API will increment and - decrement correspondingly. Ghidra, on the other hand, will only increment.
+This is an extension to our launcher for the Windows Debugger to support TTD. WinDbg TTD
+ uses event:ticks to denote its times. This corresponds well to Ghidra's
+ snapshot:steps syntax, when we let snapshot be an event and ticks count the number
+ of instruction steps. Upon expanding the "Events" node in the Model tree, we create a snapshot
+ for every TTD event, including thread create/terminate, module load/unload, syscall, and other
+ asynchronous changes. Then, when Ghidra navigates to a schedule of the form
+ snapshot:steps, we command WinDbg to navigate to the corresponding
+ event:ticks instead of using Ghidra's emulator. Conversely, time navigation from
+ the WinDbg CLI will correspondingly navigate Ghidra. Thus, the two are synchronized in time. We
+ also add reverse variants of the Go and Step control commands.
This launcher has basically the same options as the WinDbg launcher, except that arguments are not included and the DLL path must contain TTDReplay.dll and the scripts that implement TTD. These are most easily obtained by installing WinDbg Preview or later.
+ +Depending on how you acquire WinDbg TTD, you may need to copy the installation to a + directory Ghidra is allowed to access. It's best not to try cherry-picking files. Just + copy/unpack the entire WinDbg installation. Point the launch dialog to the directory containing + dbgeng.dll as usual.
+ +NOTE: It's possible, especially if you have anti-virus software installed, that + dbghelp.dll is forcefully loaded into the Python process before our connector package + tries to load dbgeng.dll. This can cause dbghelp.dll to be loaded from + System32, but dbgeng.dll to be loaded from the WinDbg installation, often + leading to DLL compatibility problems. This usually manifests in module load and/or Python + import errors. The only real way to be sure is to use a system utility and inspect the DLLs + loaded by the python.exe process. You may be able to work around the issue by copying + dbghelp.dll (and any other affected WinDbg DLLs) from the WinDbg installation into + your Python installation, e.g., C:\Python313\dbghelp.dll.