有一天，我在调试一个问题，在一个进程上弹出一个Waston对话框。让我吃惊的是，在Waston触发的堆栈上，有一个带有Testcatch（…）块的非托管C++函数。据我理解，此块应该捕获Windows中抛出的任何用户模式异常，包括来自RaiseExceptionr调用（例如，C++异常）、AV、堆栈溢出等的异常。为什么异常会逃出这样的块而变得未处理？我发现异常是调试中断。在X86中，它由操作码0xCC或“int3”触发。当我调试到VCRT的EH代码时，我发现catch（…）故意让调试中断。它确实有意义：debug break是为了停止调试器，因此源代码不应该处理它。我只是从来没有意识到。
另一个有趣的部分是这个调试中断的来源，进程的代码从不调用DebugBreak。在我调试了更多之后，问题就出在一个过早的GC问题。托管代码向非托管代码传递了委托，但未通知GC延长其生存期。当非托管代码调用回调时，托管委托对象已被收集，因此非托管代码被调用到垃圾内存中。内存正好被0xCC填满，所以当进程试图执行这段代码时，它触发了int3，然后Waston启动了。