在WndProc中64位异常静默失败 [英] 64bit exceptions in WndProc silently fail

查看:459
本文介绍了在WndProc中64位异常静默失败的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

下面code将使硬盘在Windows 7 32位运行时失败:

The following code will give a hard fail when run under Windows 7 32bit:

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
}

不过,如果我尝试这种在Windows 7 64位,我刚刚得到这个在输出窗口:

However, if I try this on Windows 7 64bit, I just get this in the output window:

第一次机会异常在0x13929384   在test.exe的:0000005:访问   违反书写位置00000000。
  第一次机会异常的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.

,这是什么原因呢?我知道这是一个硬件异常(http://msdn.microsoft.com/en-us/library/aa363082.aspx),但为什么差别时,在32位和64位跑了?而我能做些什么,以正确处理这些样的错误?因为他们应该被捕获并固定,相对于目前发生的事情是Windows只是进行抽水消息应用程序,让我们运行它(这样用户和开发者们完全不知道实际发生的任何问题)。

What is the reason for this? I know it's a hardware exception (http://msdn.microsoft.com/en-us/library/aa363082.aspx), but why the difference when ran under 32bit and 64bit? And what can I do to correctly handle these kind of errors? Because they should really be trapped and fixed, as opposed to what currently happens which is Windows just carries on pumping messages to the application and let's it run (so the user and the developers are completely unaware any problems have actually occurred).

更新: 我们经常性的死机报告软件使用 SetUnhandledExceptionFilter 但这不会被调用在x64的内部WndProc的硬件异常。有没有人有这方面的消息,或替代方法?

Update: Our regular crash reporting software uses SetUnhandledExceptionFilter but that doesn't get called on x64 for hardware exceptions inside a WndProc. Does anyone have any information on this, or a workaround?

UPDATE2: 我报告的问题在微软连接:
<一href="https://connect.microsoft.com/VisualStudio/feedback/details/550944/hardware-exceptions-on-x64-machines-are-silently-caught-in-wndproc-messages" rel="nofollow">https://connect.microsoft.com/VisualStudio/feedback/details/550944/hardware-exceptions-on-x64-machines-are-silently-caught-in-wndproc-messages

Update2: I've reported the issue at Microsoft Connect:
https://connect.microsoft.com/VisualStudio/feedback/details/550944/hardware-exceptions-on-x64-machines-are-silently-caught-in-wndproc-messages

推荐答案

好了,我已经收到了来自微软的回复:

OK, I've received a reply from Microsoft:

您好,

感谢您的报告。我发现了   这是一个视窗的问题,并   有一个热修复程序可用。请   看到    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.

@Skute:注意程序   兼容性助手会再多问   如果该程序应允许   继续执行,并且它经过   将总是被允许,从而使可   混乱的行为的原因   你所看到的。

@Skute: note that the Program Compatibility Assistant will ask once if the program should be allowed to continue to execute, and after that it will always be allowed, so that may be the cause of the confusing behavior you are seeing.

八布伦纳的Visual C ++库   发展

Pat Brenner Visual C++ Libraries Development

因此​​,解决方法是确保安装修复程序,或每个包裹的WndProc在一个__try / __except块的应用程序。

So the workaround is either make sure the hotfix is installed, or wrap each WndProc in your application with a __try / __except block.

这篇关于在WndProc中64位异常静默失败的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆