Windbg运行时触发未手动设置的int 3指令的原因排查

问题背景 #

在进行崩溃分析时，我遇到了一段汇编指令：

74553ef7 50 push eax
74553ef8 e81ba0ffff call MSVCR90!CxxThrowException (7454df18)
74553efd cc int 3
74553efe cc int 3
74553eff cc int 3
74553f00 cc int 3
74553f01 cc int 3
74553f02 cc int 3

使用WinDbg调试时，程序停在了int 3指令处。我确认自己并未手动设置任何断点，同时检查了调试器的默认断点配置：

0:009> sx
vcpp - Visual C++ exception - second-chance break - handled
wkd - Wake debugger - second-chance break - not handled
wob - WOW64 breakpoint - second-chance break - handled
wos - WOW64 single step exception - second-chance break - handled

我的疑问是：这些int 3是WinDbg设置的吗？若是，原因是什么？还是它们原本就存在于二进制镜像中？若是，编译器为何插入该指令？

解答 #

先给你一个明确结论：这些int 3绝对不是WinDbg设置的，它们本来就存在于MSVCR90.dll的这段代码里。下面分两部分给你解释：

为什么排除WinDbg的可能性？ #

WinDbg不管是手动设断点还是自动断点，本质都是把目标地址的原始指令字节替换成0xCC（也就是int 3），但调试器会临时保存原始字节，方便后续恢复执行。而你遇到的是连续的int 3，而且紧跟在call MSVCR90!CxxThrowException之后——这个函数是C++抛出异常的核心逻辑，正常调用它之后，程序会立刻进入异常展开流程，根本不会执行到后面的代码。

再看你贴的sx输出，也没有开启任何会自动插入这类连续断点的配置，WinDbg默认也不会在系统库的代码段里自动搞这么多连续断点。

编译器为什么要插入这些int3？ #

这些连续的int 3属于**"陷阱指令"**，是编译器在特定场景下生成的，主要有两个核心原因：

• 不可达代码的预警标记：CxxThrowException执行后会触发异常，正常情况下后面的代码永远不会被走到。编译器识别出这段代码是绝对不可达的，就用int 3填充。如果程序真的跑到这里，说明异常处理机制出了大问题——比如栈被损坏、异常处理链被破坏、运行时库状态异常等，触发调试器断点就是为了强制提醒你排查这类严重问题。
• 代码对齐填充：偶尔编译器为了让代码段满足内存对齐要求（比如16字节对齐），会在函数末尾或代码间隙用int 3填充空字节。不过结合你这个场景，显然更偏向于前者——毕竟是紧跟在异常抛出调用后的连续陷阱指令，就是用来做故障预警的。

简单来说，这些int 3是编译器给你的"红色警报"：正常程序根本不该走到这里，一旦走到了，就得重点排查栈完整性、异常处理注册信息、运行时库状态这些方向的问题。

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