WinDbg 动态调试（Windows 用户态 + 内核）

何时使用 / 何时不用

• 用：Windows 用户态进程调试（启动/附加、断点、单步、寄存器）；崩溃/异常分析（!analyze -v）；内核调试（双机/VM/本地 kd）；驱动与内核模块分析（配合 [[re-kernel]]）；崩溃 dump（minidump/full dump）分析
• 用：时间旅行调试（TTD）——ttd.exe 录制 .run 轨迹后任意回放，适合「复现一次慢慢查」的校验/解密逻辑（见 [[commands]] TTD 节）
• 不用：Linux 目标（走 [[re-gdb]]）；macOS 目标（[[re-lldb]]）；只需轻量 GUI 调试（[[re-x64dbg]] 更快）
• 不用：只做静态分析/反编译（[[re-ida]] / [[re-ghidra]] / [[re-binaryninja]]）；无需与运行态互动的纯静态流程不需要调试器
• 不用：WSL 内跨边界 attach Windows 进程（[[re-analyze/platform-tips]] WSL 分支：跨边界走 Windows 侧工具）

工具准备

参考 [[re-analyze/platform-tips]] Windows 分支——attach 需要管理员权限；调试属动态执行，默认沙箱内进行（[[re-analyze/platform-tips]] 最高原则）。

WinDbg（微软商店版 / Windows SDK / WDK）

• 商店版（新 UI WinDbg）：winget install Microsoft.WinDbg（或 Microsoft Store 搜索 "WinDbg"）
• 经典版：Windows SDK 安装器勾选 "Debugging Tools for Windows"；choco install windbg
• WDK（含内核调试工具 kd.exe/kdnet.exe）：winget install Microsoft.WindowsWDK 或 Visual Studio 安装器勾选 WDK
• 验证: 打开 WinDbg，File > Open Executable 加载任意 exe 能停在初始断点；命令窗口 ver 输出版本号
• 版本差异: 商店版（WinDbg 1.x，Chromium UI）与经典版（WinDbg 10.0.x）命令兼容，UI 与附加流程不同；dump 分析两者通用（见 [[gotchas]]）

Windows 符号（Windows SDK 符号 / 公共符号服务器）

• 符号路径: .sympath srv*C:\symbols*https://msdl.microsoft.com/download/symbols（或设环境变量 _NT_SYMBOL_PATH）
• 内核模块符号: 内核调试下 .reload /f nt（强制从符号服务器拉取）
• 验证: !analyze -v 输出中出现函数名而非 +0x1a 裸偏移

双机/虚拟机内核调试环境

• 目标机（被调试）: bcdedit /debug on + bcdedit /dbgsettings serial debugport:1 baudrate:115200（串口）或 bcdedit /dbgsettings net hostip:<宿主机IP> port:50000 key:<kdnet.exe生成的key>（NET 网卡，Windows 10+ 推荐）
• VM 场景: VMware/Hyper-V 给目标 VM 添加串口设备（Named Pipe \\.\pipe\com_1 / -vmconnect），宿主 WinDbg File > Kernel Debug > COM 填管道名
• 本地内核调试（仅测试机，需测试签名）: bcdedit /set testsigning on 重启后，WinDbg File > Kernel Debug > Local
• 验证: 目标机重启停在 "Waiting to reconnect" 或进入调试等待后，宿主 WinDbg 附加成功、g 后 Ctrl+Break 能中断、lm 列出模块

TTD（时间旅行调试，Windows 10 1903+）

• 录制: ttd.exe -out C:\traces target.exe（或 -attach <pid> 附加录制；-monitor <进程名> 监控启动）
• 打开: WinDbg File > Open 选 .run 轨迹文件（或 Open Trace File）
• 验证: ttd.exe -help 有输出；录一段后用 WinDbg 打开，!tt 能跳到任意位置、g- 能往回跑（详见 [[commands]] TTD 节）

操作步骤

1. 附加/启动用户态目标：

   • 启动: File > Open Executable 选目标 exe，停在初始断点（ntdll 加载完成处）
   • 附加: File > Attach to Process 按 PID/进程名选目标（管理员权限启动 WinDbg 才能附加高权限进程）
   • 命令行: windbg -p <pid> / windbg 目标.exe；-g 跳过初始断点直接运行

2. 断点 / 单步 / 寄存器：

   • 符号断点: bp kernel32!CreateFileW；地址断点: bp 0x401000；bl 列表、bd/be 禁用/启用、bc * 清空
   • 未加载模块的符号用 bu（unresolved，模块加载后自动绑定）——目标 DLL 按需加载时 bu 是正解
   • 命令断点: bp 地址 "r rax; k; gc"——命中时打印现场后自动继续，日志式观察不打断流程
   • 单步: g 继续、p 步过、t 步入、gu 执行到当前函数返回
   • 寄存器: r 全部、r rax 查看、r eax=0 修改（绕过校验常用）
   • 内存/反汇编: u 0x401000 反汇编、dd/db 读内存、dps rsp 看栈内容
   • 搜索: s -d 0x0 L?10000000 0xdeadbeef（值）、s -a 0x0 L?10000000 "text"（ASCII 串）——找硬编码常量/密钥用
   • 符号搜索: x 模块!*关键字*（如 x kernel32!*Virtual*）——不确定精确符号名时模糊匹配

3. 异常分析 !analyze -v：

   • 目标崩溃停下后: !analyze -v → 读 EXCEPTION_CODE、FAULTING_IP、STACK_TEXT、PROCESS_NAME
   • 内核蓝屏对应 bugcheck 码（BUGCHECK_CODE，如 0xD1 驱动访问无效内存）——先记码再往下查，常见码含义要能对上故障方向
   • 现场恢复: 从 STACK_TEXT 取 EXCEPTION_RECORD 地址 .exr <addr>（异常记录），再取 CONTEXT 地址 .cxr <addr> 恢复寄存器现场，之后 k 出真实调用栈（栈损坏时唯一可靠的栈回溯方式）
   • dump 现场更简单: 打开 dump 后直接 .ecxr（自动用异常上下文设寄存器现场）→ k——minidump 分析标准开局
   • dump 分析: File > Open Crash Dump 打开 .dmp（用户态用 .dump /ma 生成；内核蓝屏用 %SystemRoot%\Minidump\*.dmp 或完全 dump），同样 !analyze -v 出 bugcheck 码与故障模块

4. 内核调试（双机 / VM / 本地 kd）：

   • 目标机配置见「工具准备」；配置后重启，宿主 File > Kernel Debug 按所用传输（COM/NET）连接
   • VM 管道串口流程: 目标 VM 加串口 Named Pipe → 目标机 bcdedit /dbgsettings serial → 宿主 File > Kernel Debug > COM 填管道名（\\.\pipe\com_1）→ 目标机重启等连
   • 连接后: g 让目标继续跑；Ctrl+Break 随时中断回调试器；!process 0 0 确认会话活着
   • 本地调试: bcdedit /set testsigning on 重启后 File > Kernel Debug > Local（仅测试机，不影响生产机的用法）

5. 扩展命令：

   • !process 0 0（全部进程列表）、!process <EPROCESS> 1（单进程详情+线程）；.process /p <EPROCESS> 切到目标进程上下文后再 k/!thread
   • !teb（当前线程 TEB）、!peb（当前进程 PEB——命令行、加载模块、环境块）
   • lm（模块列表，行尾 (deferred)=符号未加载、(no symbols)=无符号）、lmv m <模块>（版本+路径）、lmi <模块>（镜像头）
   • kv（带符号完整栈回溯，驱动分析常用）、!analyze -v 后按 STACK_TEXT 逐帧核对
   • 驱动专项: lmv m 驱动名 拿基址 → .reload /f 驱动名 加载符号 → 深挖转 [[re-kernel]]

6. TTD 回放（校验/解密逻辑慢查）：

   ttd.exe -out C:\traces target.exe     # 录制
   WinDbg 打开 .run → g- / t- / p-       # 往回跑
   !tt 50                                 # 跳到轨迹 50% 处
   !tt 7213:36                            # 跳指定位置（事件序号:步数）
   

   • 断点前移/后移: !tt br 在某寄存器值变化处停；!tt bm 在内存访问处停
   • 首次打开轨迹先 !tt.index 建索引（之后打开跳过）；回放中途也可断点 bp（在轨迹上工作）
   • 查询 API: dx @$cursession.TTD.Calls("模块!函数") 统计调用次数/参数（如 ...Calls("ntdll!mem*")）
   • TTD 限制: 需管理员运行、用户态专用、轨迹文件很大（数 GB）、回放只读不能写内存（见 [[gotchas]]）

7. 伪寄存器与脚本化（简单自动化）：

   • 伪寄存器: r $t0 = 0 起临时变量；$$ > <文件> 把命令输出重定向到文件（如 $$ > c:\log.txt）
   • 条件执行: .if (rax==0) { ... } .else { ... }——配合 gc 做断点内逻辑
   • !runaway 看线程 CPU 时间（找忙等/死循环线程）；!locks 查锁状态（挂起排查）

跨域联合

• [[re-binary-core]]：工作流第 6 步 Windows 调试器（用户态+内核）
• [[re-kernel]]：内核调试与驱动/rootkit 运行时验证固定调用本技能
• [[re-anti-analysis]]：反调试对抗（内核级检测点）、脱壳后验证
• [[re-malware]]：恶意样本崩溃 dump 分析与内核组件
• [[re-cracking]]：授权校验崩溃定位（!analyze -v 快速找崩溃原因）
• 与 [[re-x64dbg]] 互补：轻量 GUI 断点调试用 x64dbg，内核/异常现场恢复/轨迹回放用 WinDbg

常见坑与陷阱

• 符号未配置 → 全是裸偏移无函数名：现象——lm 行尾 (no symbols)，k 输出 ntdll!+0x1a；原因——符号路径为空或没 _NT_SYMBOL_PATH；对策——.sympath srv*C:\symbols*https://msdl.microsoft.com/download/symbols 后 .reload /f，内核模块同理（先确认符号服务器可达）
• 内核调试配置错 → 目标机蓝屏死等或连不上：现象——目标机重启后停在 debug 等待或直接进系统未中断；原因——bcdedit 传输类型/端口与宿主不一致，或物理机单机本地调试受限（PatchGuard）；对策——用 VM 串口管道最稳（两边都对 \\.\pipe\com_1），bcdedit /dbgsettings 重查配置，物理机场景优先 KDNET
• 32/64 位命令与寄存器差异：现象——64 位目标下 r eax 改错值、!teb 字段对不上；原因——x64 上下文用 rax/rbx...（低 32 位是 eax 等）、wow64 目标线程栈在 x86 层；对策——先确认目标位数，wow64 场景 .load wow64exts + !wow64exts.sw 切到 x86 上下文
• 栈损坏时 k 是假象：现象——调用栈乱（地址不像代码）；原因——栈指针被破坏/内存踩踏，常规回溯不可信；对策——用 .exr 拿异常记录、.cxr 恢复 CONTEXT 后再 k，必要时 !analyze -v 的 STACK_TEXT 里直接取现场
• 蓝屏 dump 打不开：现象——Open Crash Dump 报格式错；原因——minidump 不完整（磁盘满）或用的 32 位 WinDbg 读 64 位 dump；对策——目标机确认内核页交换文件（crash dump 需要 pagefile）足够大，改用同位数 WinDbg
• RPC 调用统一入口 NdrStubCall3（svchost 功能逆向）：现象——要拦/分析某个系统功能（如 Toast 通知），不知道它经什么通道进 svchost；原因——功能实现经 RPC 到 svchost 进程，入口难找；对策——Process Monitor 看目标进程加载 rpcrt4.dll + RpcView 确认 RPC 目标进程；所有 RPC 服务端 stub 统一走 rpcrt4 的 NdrStubCall3（x64；NdrStubCall2 是旧版 x86，ReactOS/Wine 源码可印证）——在其下断 kvn 看调用来源；筛选目标调用：第三参数（r8）指向 RPC_MESSAGE（+0x1C 是 ProcNum 方法编号、+0x28 是接口描述指针 RpcInterfaceInformation → RPC_SERVER_INTERFACE 的 InterfaceId 在 +0x04）；opnum 由 MIDL 按方法声明顺序从 0 编号（如 PostNotification3 排第 0x29 位 → opnum=0x29），ObjectStublessClientN 中 rax=N 即 ProcNum；坑：NdrStubCall3 处理 svchost 内所有 RPC 接口，必须按 InterfaceId + ProcNum 双重筛选，只拦目标方法（拦错会把 Edge 等其他功能搞挂）
• TTD 限制、版本差异与符号服务器细节见 [[gotchas]]