TheJCAB
commented
11 months ago You are correct. TTD currently can only acquire control of any thread after it returns back to user mode from kernel, so if you can arrange for that to happen once or twice somehow after you let the process run from the debugger you'll be able to record what you want.
Not that only a "flow control" return from kernel counts here. A thread being resumed after being suspended doesn't count as a return from kernel for this purpose.
Exception dispatching and APCs do count, including the relatively new "special" user mode APCs, which may or may not serve you as an alternative here. You can read about them here: https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/types-of-apcs
How this helps,
JCAB
I would like to be able to capture a Time Travel Debugging trace starting from an arbitrary point in a debugging session. In other words, I want to transfer the monitored process from the debugger to the TTD tracer. I do not see an easy way to do that right now with ttd.exe or the menus in WinDbg.
My specific scenario comes about when I am analyzing malware. I often need to manually bypass several anti-analysis techniques or packing layers or otherwise need to force it down specific code paths before it is on the right path of execution. At this point I would like to start the TTD trace.
I have tried to debug my malware manually, bypass the anti-analysis techniques, then use TTD.exe to attach to the malware process, and then detach from the process with the debugger. That does create a run trace, but it does not capture from where I left off in the debugger. It looks like TTD takes time to initialize and the malware's main threads are running during that, resulting in the trace starting from an arbitrary point in execution after I detach with the debugger.