Windows默默捕捉到的异常,如何手动处理?
当异常在消息泵中抛出时,我们遇到了 Windows 静默处理异常并允许应用程序继续运行的问题.例如,我们创建了一个测试 MFC MDI 应用程序,并覆盖了 OnDraw:
We're having problems with Windows silently eating exceptions and allowing the application to continue running, when the exception is thrown inside the message pump. For example, we created a test MFC MDI application, and overrode OnDraw:
void CTestView::OnDraw(CDC* /*pDC*/)
{
*(int*)0 = 0; // Crash
CTestDoc* pDoc = GetDocument();
ASSERT_VALID(pDoc);
if (!pDoc)
return;
// TODO: add draw code for native data here
}
在运行应用程序时,您可能会收到令人讨厌的错误消息,但实际上您什么也得不到.该程序似乎运行得很好,但是如果您检查输出窗口,您将看到:
You would expect a nasty error message when running the application, but you actually get nothing at all. The program appears to be running perfectly well, but if you check the output window you will see:
第一次机会例外在Test.exe 中的 0x13929384:0xC0000005:访问冲突写入位置 0x00000000.
0x77c6ee42 处的第一次机会异常在Test.exe:0xC0150010:激活上下文被停用对当前线程不活跃执行.
First-chance exception at 0x13929384 in Test.exe: 0xC0000005: Access violation writing location 0x00000000.
First-chance exception at 0x77c6ee42 in Test.exe: 0xC0150010: The activation context being deactivated is not active for the current thread of execution.
我知道为什么我会收到应用程序上下文异常,但为什么它被静默处理?这意味着我们的应用程序在使用时可能会遇到严重的问题,但我们永远不会知道,因为我们的用户永远不会报告任何问题.
I know why I'm receiving the application context exception, but why is it being handled silently? It means our applications could be suffering serious problems when in use, but we'll never know about it, because our users will never report any problems.
推荐答案
在浏览了类似的问题后,我偶然发现了这个答案:OpenGL 抑制 MFC 基于对话框的应用程序中的异常
After browsing similar questions I stumbled across this answer: OpenGL suppresses exceptions in MFC dialog-based application
好的,我找到了更多信息对这个.在我的情况下,它是 Windows 7安装KiUserCallbackExceptionHandler 作为异常处理程序,在调用我之前WndProc 并给我执行控制.这是由ntdll!KiUserCallbackDispatcher.一世怀疑这是一个安全微软采取措施防止入侵 SEH.
"Ok, I found out some more information about this. In my case it's windows 7 that installs KiUserCallbackExceptionHandler as exception handler, before calling my WndProc and giving me execution control. This is done by ntdll!KiUserCallbackDispatcher. I suspect that this is a security measure taken by Microsoft to prevent hacking into SEH.
解决方案是包装你的 wndproc(或 hookproc)与 try/except框架."
The solution is to wrap your wndproc (or hookproc) with a try/except frame."
我已向 Microsoft 提交了错误报告,您可以在此处查看他们的回复:
http://connect.microsoft.com/VisualStudio/feedback/details/550944/hardware-exceptions-on-x64-machines-are-silently-caught-in-wndproc-messages
I've filed a bug report with Microsoft, you can see their response here:
http://connect.microsoft.com/VisualStudio/feedback/details/550944/hardware-exceptions-on-x64-machines-are-silently-caught-in-wndproc-messages
来自微软:
感谢您的报告.我发现这是一个Windows问题,并且有一个可用的热修复程序.请参见http://support.microsoft.com/kb/976038 获取可以安装的修复程序如果你愿意.
Thanks for the report. I've found out that this is a Windows issue, and there is a hot fix available. Please see http://support.microsoft.com/kb/976038 for a fix that you can install if you wish.
相关文章