如何在Windows触发启动修复模式前通过WinDbg附加调试内核

• 默认内核调试的开放时序根本不匹配：Windows默认配置下，内核调试端口是boot流程走完近30%、IO管理器初始化完成大半之后才会对外开放通信的。而你遇到的自签名boot驱动检测，是在IO管理器枚举boot启动类驱动列表的阶段就执行的，这部分逻辑的运行位置远早于默认的调试端口开放节点，等你能连上的时候，检测逻辑早跑完了，系统都已经跳修复模式了。
• 虚拟COM管道的连接时序有滞后：VMware的虚拟串口默认是等被调试机加载完系统自带的串口驱动、发出来硬件访问请求，才会真正建立管道连接，这个过程和签名检测逻辑是并行推进的，往往连接握手还没完成，检测就已经触发了。
• 签名检测阶段的调试端口默认锁死：x64版本Windows在boot驱动签名校验的关键节点，会临时切断调试端口的通信通道，避免调试器绕过校验规则，哪怕你碰巧在检测前连上了，到这个节点也会被强制断开，根本没法停在检测逻辑之前。
• 常见的配置误区：很多人配内核调试只开了bcdedit /debug on，没配置让内核早期就主动等调试器，本质上还是把调试端口设成了“系统跑顺了再连”的模式，自然追不上早期的检测流程。

• 第一步：修改被调试机的BCD启动配置，强制开启早期调试等待。在能访问被调试机系统或WinRE的状态下，用管理员权限执行以下命令：
  • 开启内核调试基础开关：bcdedit /debug on
  • 配置串口参数和VMware管道匹配：bcdedit /dbgsettings serial baudrate=115200 debugport=1
  • 强制内核初始化完最基础的调试端口就立刻挂起，等调试器连上再继续执行：bcdedit /set KDBGOptions 0x5
  • 这个参数的位掩码逻辑是：0x1 代表内核刚完成调试端口初始化就立即break，不等系统往下跑；0x4 代表开放所有早期启动阶段的调试权限，不会在签名检测节点锁死调试端口。
• 第二步：调整VMware虚拟串口配置消除连接延迟。把被调试机的串口设置修改为：
  • 绑定和WinDbg端完全一致的命名管道路径
  • 勾选“启动时自动连接管道”，不要等系统加载完串口驱动才建立连接
  • 关闭“管道断开时向客户机发送硬件中断”的选项，避免连接过程中触发额外的系统异常
• 第三步：按正确顺序建立调试连接。先启动运行WinDbg的VM，打开WinDbg的内核调试界面，选择COM连接模式，填好匹配的波特率和管道名，进入等待连接状态；再启动被调试的VM，这时候被调试机一初始化调试端口就会自动和WinDbg完成握手，内核直接停在最早期的调试断点上，根本不会往下执行签名检测的逻辑。

• 成功附加到早期内核断点后，先加载微软公共符号，然后直接对代码完整性校验的核心入口下断点：bp CI!CiValidateImageHeader
• 输入g命令让系统继续执行，等断点触发后，用k命令查看完整调用栈，就能顺着回溯路径找到上层负责枚举boot驱动列表、发起签名校验的具体函数——这部分逻辑一般就在nt!IopInitializeBootDrivers的代码分支里，你要找的自签名检查触发的完整路径，都能从调用栈里梳理出来。
• 操作注意：不要提前开启testsigning、nointegritychecks这类绕过签名校验的BCD开关，不然你构造的自签名驱动错误场景根本不会触发，也就没法抓到对应的检测逻辑。

内容的提问来源于stack exchange，提问作者user7225528