&wintrace (my time travel recorder & replayer for Windows) now supports most replay controls including forwards stepping in source code. The source stepping uses the same implementation that's used for live processes in RAD Debugger, which means it behaves exactly like stepping through a live process for both debug and release builds. Only remaining operations to be implemented are "step back into/over in source code" which are probably the most complicated. The other big core feature I'm still missing is supporting multi-threaded recordings in the replayer and that is something I will work on next. Because the record & replay flow is now functional I also started releasing alpha versions on the project's Discord server if you would like to test it out (the link to it is at the project's page: https://wintrace.io).

&wintrace I recorded a lengthier demo video of my Time Travel Debugging for Windows project where I showcase recording performance and current integration with RAD Debugger: https://www.youtube.com/watch?v=IumGevTuDsM
It also has a name & website with a bunch of additional info/benchmarks: https://wintrace.io/

&wintrace My time travel solution for Windows I'm developing can now index the entire execution of a recorded process to provide basic time travel controls: step forwards/backwards, rewind to start or end of the recording and jump to any position in the recording. The index contains process "keyframes" which define a differential memory state to the previous keyframes and jumping to a position chooses the nearest keyframe, executes from it until the position is reached and renders the full program memory pages on demand when the debugger asks for them. The replay engine and new controls are integrated with raddbg, and the session here is showing a recording of raddbg itself.

&wintrace I'm working on my high performance record/replay solution for Windows. The recorder is focused on delivering the lowest amount of overhead while recording a truthful, instruction level trace of the entire execution to replay later. In single threaded scenarios, it incurs about 4-5x performance overhead and while it can record all threads of a process, there's still work to be done there in terms of overhead. Here, I'm recording all threads of a pretty simple game and producing a file which I can replay later after the process terminated. The file can be transferred to another machine and replayed as many times as you want. The replay engine is integrated into a raddbg fork which allows for debugging the trace file like a normal process with full support for memory inspection, breakpoints and stepping, though I have yet to implement the "time travel" part in replay which is stepping back in the trace. There's still quite a lot of work to be done in the record/replay engines to make this a solid time travel experience but it is a good start.