TTD 在 C# 中不可直接使用，因其仅支持原生代码，无法可靠捕获托管堆、GC、线程同步等 CLR 运行时状态；替代方案包括 dotnet-dump、dotnet-trace 和 Visual Studio IntelliTrace。
TTD 在 C# 中不可直接使用
Windows 的 Time Travel Debugging（TTD）是 Windows 10/11 内置的录制-回放式调试技术，但它只支持原生代码（x64/x86 用户态进程），不支持 .NET 托管代码。C# 程序运行在 CLR 上，执行的是 IL 指令，由 JIT 编译为原生代码，但 TTD 录制时无法可靠捕获托管堆状态、GC 行为、线程同步上下文等关键信息，因此 dotnet.exe 或任何托管进程启动后，用 tttracer.exe 录制会失败或回放时崩溃/断点失效。
替代方案：使用 dotnet-dump + Live Diagnostics
对 C# 应用做“时间旅行式”根因分析，实际可行路径是结合内存快照与运行时诊断能力：
-
dotnet-dump collect -p <pid></pid>可在异常前/后抓取完整托管堆快照，配合dotnet-dump analyze查看对象引用链、线程栈、异常对象详情 -
dotnet-trace collect --providers Microsoft-DotNetRuntime录制高性能事件流（含 GC、JIT、ThreadPool、Exception 等），导出.nettrace后用PerfView或dotnet-trace convert分析时序行为 - Visual Studio 2022+ 支持“IntelliTrace 事件模式”，可在调试时自动记录关键事件（如异常抛出、方法进入/退出），支持向后/向前跳转，但需项目启用
<debugtype>portable</debugtype>且仅限 .NET 5+ Windows 平台
为什么不能简单包装成 TTD 兼容进程
有人尝试用 dotnet exec 启动一个原生 host 进程再加载 CLR，希望骗过 TTD —— 这行不通。原因包括：
- TTD 要求被录制进程从入口点开始全程可控，而
coreclr.dll的初始化（如堆创建、线程池启动）发生在 JIT 和 GC 子系统就绪之前，TTD 无法重建这些托管运行时状态 - 托管异常（
System.NullReferenceException）不是 SEH 异常，TTD 的异常捕获机制无法拦截和重放 - 即使录制成功，回放时
!dumpheap、!clrstack等 SOS 命令大概率报错或返回无效地址，因为内存布局无法精确还原
真正接近“时间旅行”的 C# 实操组合
如果你需要重现并倒查某个偶发 bug，推荐以下最小可行组合：
- 部署时开启
DOTNET_DiagnosticPorts=127.0.0.1:9999，用dotnet-monitor监听并自动触发 dump/trace（例如检测到System.IO.IOException时立刻抓快照） - 在关键逻辑中插入
EventSource自定义事件，用dotnet-trace录制时带上你的 provider，这样能在 trace 中精确定位“第 3 次调用ProcessOrder()时发生了什么” - 避免依赖单次录制回放，改用“多点快照对比”：在可疑函数入口、中间状态、出口各抓一次
dotnet-dump，用dumpheap -stat和dumpobj对比对象生命周期
真正的难点不在工具链，而在如何把“时间旅行”的诉求拆解成可观测的托管事件与内存状态——CLR 不给你 rewind 指令指针，但它给了你足够多的钩子去记录和重建上下文。
