Windows静默捕获的异常，如何手动处理？ [英] Exceptions silently caught by Windows, how to handle manually?

问题描述

当异常被抛入消息泵中时，我们遇到了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:

第一次机会异常在
0x13929384在Test.exe：
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。I
怀疑这是一个安全的
措施微软采取了防止
黑客入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.

解决方案是使用try / except
框架来包装你的wndproc
（或hookproc）。

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

来自Microsoft：

From Microsoft:

感谢您的报告。我发现这是一个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.

这篇关于Windows静默捕获的异常，如何手动处理？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！