采用以下简单来源(将其命名为test.cpp):
#include <windows.h>
void main()
{
DebugBreak();
}
使用以下命令编译并链接:
cl /MD /c test.cpp
link /debug test.obj
如果现在运行TEST.EXE(在64位Windows 7系统上),则会出现以下对话框:
现在添加以下源文件(将其命名为test2.cpp):
void hello()
{
}
并将其与第一个源一起编译和链接,如下所示:
cl /MD /c test.cpp
cl /MD /c /clr test2.cpp
link test.obj test2.obj
请注意,我们甚至没有调用hello-function,我们只是将它链接起来。
现在再次运行TEST.EXE(在相同的64位Windows 7系统上)。而不是上面显示的对话框,你得到这个:
显然,在.Net框架中进行链接会使DebugBreak的行为有所不同。 为什么是这样?我怎样才能再次获得旧的DebugBreak行为? 这可能是Windows 7或64位特定行为吗?
侧面说明我为什么要使用DebugBreak:我们有一个自定义断言框架(类似于John Robbin的Debugging Windows Applications书中的SuperAssert),我使用DebugBreak函数,所以开发人员可以跳转到如果出现问题,调试器(或打开一个新的调试器)。现在只有简单的弹出窗口,不再可能跳转到调试器。
作为替代解决方案,我可以执行除零或写入无效地址,但我发现这是一个不太干净的解决方案。
修改 这是第二个测试中的调用堆栈(简单对话框):
ntdll.dll!_NtRaiseHardError@24() + 0x12 bytes
ntdll.dll!_NtRaiseHardError@24() + 0x12 bytes
clrjit.dll!Compiler::compCompile() + 0x5987 bytes
clr.dll!RaiseFailFastExceptionOnWin7() + 0x6b bytes
clr.dll!WatsonLastChance() + 0x1b8 bytes
clr.dll!InternalUnhandledExceptionFilter_Worker() + 0x29c bytes
clr.dll!InitGSCookie() + 0x70062 bytes
clr.dll!__CorExeMain@0() + 0x71111 bytes
msvcr100_clr0400.dll!@_EH4_CallFilterFunc@8() + 0x12 bytes
msvcr100_clr0400.dll!__except_handler4_common() + 0x7f bytes
clr.dll!__except_handler4() + 0x20 bytes
ntdll.dll!ExecuteHandler2@20() + 0x26 bytes
ntdll.dll!ExecuteHandler@20() + 0x24 bytes
ntdll.dll!_KiUserExceptionDispatcher@8() + 0xf bytes
KernelBase.dll!_DebugBreak@0() + 0x2 bytes
test_mixed.exe!01031009()
这是第一个测试中的调用堆栈(带有选项“close”和“debug”的对话框):
ntdll.dll!_ZwWaitForMultipleObjects@20() + 0x15 bytes
ntdll.dll!_ZwWaitForMultipleObjects@20() + 0x15 bytes
kernel32.dll!_WaitForMultipleObjectsExImplementation@20() + 0x8e bytes
kernel32.dll!_WaitForMultipleObjects@16() + 0x18 bytes
kernel32.dll!_WerpReportFaultInternal@8() + 0x124 bytes
kernel32.dll!_WerpReportFault@8() + 0x49 bytes
kernel32.dll!_BasepReportFault@8() + 0x1f bytes
kernel32.dll!_UnhandledExceptionFilter@4() + 0xe0 bytes
ntdll.dll!___RtlUserThreadStart@8() + 0x369cc bytes
ntdll.dll!@_EH4_CallFilterFunc@8() + 0x12 bytes
ntdll.dll!ExecuteHandler2@20() + 0x26 bytes
ntdll.dll!ExecuteHandler@20() + 0x24 bytes
ntdll.dll!_KiUserExceptionDispatcher@8() + 0xf bytes
KernelBase.dll!_DebugBreak@0() + 0x2 bytes
test_native.exe!00af1009()
差异从ntdll.dll !Executehandler2 @20开始。在非.NET应用程序中,它调用ntdll.dll!@_EH4_CallFilterFunc
。在.net应用程序中调用clr.dll!__except_handler4
。
答案 0 :(得分:2)
我在下一页找到了解决方案:http://www.codeproject.com/KB/debug/DebugBreakAnyway.aspx。
不是只编写DebugBreak,而是必须在__try / __ except结构之间嵌入DebugBreak调用,如下所示:
__try
{
DebugBreak();
}
__except (UnhandledExceptionFilter(GetExceptionInformation()))
{
}
显然,UnhandledExceptionFilter函数默认处理DebugBreak异常,这似乎在混合模式应用中被否决了。
现在你再次回到原来的对话框。