int 3就是我们常说的软件断点,问题是,在什么时候我们需要用到int 3呢?
我们经常会碰到这样一种场景,有时候一个软件会由多个EXE组成,其中的某些EXE是由另外的EXE调用的,这时候我们通常调用其它EXE创建进程的时候必须用Visual Studio 的Attach Process把VS的调试器和进程关联上(同样用WinDbg也是如此)。这时候我们会碰到一个问题,就是因为进程启动的速度过快,结果进程初始化的一些代码,比如在MFC程序的InitInstance里,WinMain里或是任何其他的初始化代码很快就执行过去了,如果Bug出现在这些代码中,你就无法调试了。
怎么办?说道这里,大家应该明白我的意思了,对了,这时候就可以在初始化打头的函数中用int 3把程序软中断,随后再Attach Process。当然,在我知道int 3之前我一直用的是Sleep让线程沉睡,但是这个办法不仅不如int 3优雅,更没有int 3方便,因为毕竟int 3是实实在在的断点。
int3还有一个用户态的API封装DebugBreak(),用法类似。
不过这篇文章还没有完,因为在普通情况下,如果你直接运行程序,当执行到int 3或是DebugBreak时会弹出一个“XXX 已停止工作,Windows正在检查该问题的解决方案。。。”的系统提示框,这时候需要等上一段时间后才会弹出对话框让你选择调试程序还是关闭程序,然后我们只要选择调试并关联上对应的工程就可以对工程进行正常的调试了。