Home Dashboard Directory Help
Search

Hardware exceptions on x64 machines are silently caught in WndProc messages by Mark Ingram UK


Status: 

Closed
 as External Help for as External


6
0
Sign in
to vote
Type: Bug
ID: 550944
Opened: 4/14/2010 3:05:54 AM
Access Restriction: Public
0
Workaround(s)
view
6
User(s) can reproduce this bug

Description

If a hardware exception (one where the exception code matches the values defined here http://msdn.microsoft.com/en-us/library/aa363082.aspx) occurs in a WndProc message (such as WM_PAINT) on a x64 machine, the exception will be caught silently, and the only way of spotting the crash is to check the output window.

Here is my example code (I will attach a test application that you can run too):

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
}

On x86 machines this will generate an error and the program will terminate, however on x64 machines, the application continues to run and if debugging, you will see the following written to the output window:

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.

These crashes are important, and we rely on being able to fix our application via the crash reports that get generated by our users. Having x64 machines hide crashes is dangerous as the problem will never get fixed.

What is the recommended way of catching these errors generically and then causing the UnhandledExceptionFilter to run as normal (which isn't called at all on x64 machines in WndProc messages)?

I've tried Vectored Exception Handling, but that's too heavy handed because it catches the errors before __try / __except, so a block of code could be aware that an exception will be generated, but the VEH handler will intercept before hand with no idea of whether we can continue or not (for example, some movie codecs we use anticipate a divide by zero exception, but VEH will pick it up before the codec).
Details
Sign in to post a comment.
Posted by Microsoft on 7/29/2010 at 11:30 AM
We don't know the Windows7 SP1 plan.
Posted by Mark Ingram (Work) on 7/14/2010 at 1:20 AM
Thanks Pat. Do you know if there are any plans to include this hotfix with Windows 7 SP1?
Posted by Microsoft on 7/13/2010 at 1:16 PM
Hello,

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: 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.

Pat Brenner
Visual C++ Libraries Development
Posted by Mark Ingram UK on 4/15/2010 at 5:14 AM
Further testing with x64 builds gave the following results:

Debug x64, no crash, the following was written to output window:
First-chance exception at 0x000000013fd43302 in Test.exe: 0xC0000005: Access violation writing location 0x0000000000000000.
First-chance exception at 0x77c2ee42 (ntdll.dll) in Test.exe: 0xC0150010: The activation context being deactivated is not active for the current thread of execution.

Debug x64 (with afxAmbientActCtx = FALSE; specified), no crash, the following was written to the output window:
First-chance exception at 0x000000013f4f3302 in Test.exe: 0xC0000005: Access violation writing location 0x0000000000000000.

Release x64, no crash.

Release x64 (with afxAmbientActCtx = FALSE; specified), no crash.

--

Needless to say, I'm very *very* confused as to why when I try it now, I don't get any crashes.
As my previous comment says, it did crash this morning when I tried it.
Posted by Mark Ingram UK on 4/15/2010 at 1:12 AM
@SvenC, sorry I've just realised what you said. *Built* as an x64 app it does crash, if you build the x86 version, then run that, you will notice that it silently handles the exception.
Posted by Mark Ingram UK on 4/15/2010 at 1:04 AM
@SvenC, did you try it in release mode. Also, do you have the access violation exceptions turned on in Visual Studio?
(And are you using VS2008?)
Posted by SvenC on 4/15/2010 at 12:12 AM
I have run your test project on Win 7 x64 and it crashes in in Crash when run as x64.
So I cannot repro the behavior you describe
Posted by Microsoft on 4/14/2010 at 11:26 PM
Thank you for reporting this issue.
We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Sign in to post a workaround.