为何修改Windows异常ISR会导致系统陷入页错误循环？

核心原因 #

修改用户态异常对应的ISR入口后触发系统冻结，根源是用户态异常处理的栈切换依赖未完成时，非法访问引发页错误连锁反应，最终导致双错误（Double Fault）。

细节拆解 #

1. 用户态异常的栈切换逻辑
   用户态触发异常时，CPU会先执行栈切换：从用户栈切换到内核栈。这个过程中，Windows内核依赖gs:[860h]（对应KPCR->CurrentPrcb.NtTib.StackLimit）校验内核栈合法性，但此时栈段寄存器ss尚未完成初始化——从你提供的寄存器状态可以看到ss=0000，说明内核栈还未被正确映射。

2. ISR入口修改的破坏性
   直接修改ISR第一条指令（断点、NOP、JMP）会打破异常处理的原子性：

• 用户态异常触发后，CPU跳转到被修改的ISR，此时内核栈切换未完成，gs段的访问环境不合法；
• 当页错误处理例程nt!KiPageFault执行test word ptr gs:[860h]时，直接触发页错误；而页错误处理本身需要正常栈环境，进而引发双错误，最终导致系统冻结。

3. 内核态异常无问题的原因
   内核态触发异常时，已经处于合法的内核栈环境，ss段正常，gs寄存器映射也完全有效，因此修改ISR入口不会触发栈相关的页错误，流程可正常执行。

验证结论的补充 #

• 不同机器、不同异常ISR均出现相同问题，因为这是Windows内核异常处理机制的共性逻辑，与硬件无关；
• 修改ISR入口附近会触发问题，但修改偏移+100字节后可能正常——因为入口处是栈切换的关键前置逻辑，后续代码已完成栈初始化，不会触发栈相关的页错误。

替代调试方案 #

要调试用户态异常的ISR处理流程，可通过以下方法规避该问题：

• 在栈切换完成后的位置下断点：跳过ISR入口的栈切换代码（通常前几十字节），在KiExceptionDispatch或具体异常处理例程的入口设置断点；
• 使用条件断点过滤用户态异常场景：仅在内核栈初始化完成后触发断点，示例Windbg命令：

  bp nt!KiGeneralProtectionFault "r ss; .if (ss != 0000) { } .else { gc }"
  

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