64bit exception in WndProc silently

Question

The following code will crash when working 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 } 

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

The first chance exception in 0x13929384 in Test.exe is: 0xC0000005: access is the location of the 0x00000000 violation record.
First chance exception in 0x77c6ee42 in Test.exe: 0xC0150010: context activation is deactivated inactive for the current thread of execution.

What is the reason for this? I know this is a hardware exception ( http://msdn.microsoft.com/en-us/library/aa363082.aspx ), but why the difference when running under 32-bit and 64-bit? And what can I do to handle such errors correctly? Because they really need to be captured and secured, unlike what is currently happening, what Windows just carries is pumping the application and let it work (so the user and developers are completely unaware of any problems actually happened).

Update: Our regular SetUnhandledExceptionFilter reporting software uses SetUnhandledExceptionFilter , but this is not caused by the x64 call for hardware exceptions inside WndProc. Does anyone have any info on this or a workaround?

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

Answer 1

OK, I got a response from Microsoft:

Hello,

Thanks for the report. I found out that this is a Windows problem, and there is a fix available. please see http://support.microsoft.com/kb/976038 for a fix that you can install if you wish.

@Skute: note that the Compatibility Assistant program will ask once if the program should be allowed to continue execution, and after that it will always be allowed, so there may be a reason for the confusing behavior you see.

Pat Brenner Visual C ++ Libraries Development

So, the workaround is either to make sure the fix is ​​installed, or to wrap each WndProc in your application with __try / __ except block.

Answer 2

Another exception occurs when the stack is unwound to exclude an access exception. What is swallowed, causing the AV to disappear. You will need to figure out which code does this. Debugging + Exceptions, check the "Abandoned" box for Win32 exceptions. The debugger stops at the first, continue. Check the stack of calls when it stops again. Add it to your question if you cannot figure it out.

Answer 3

The only way we were able to get around this problem is to put __try / __ except around each WndProc callback in the application. Then we throw the exception to our exception handler. Awful, but it seems like this is a problem with Windows itself. Still waiting for Microsoft to come back to us.

Answer 4

I would venture to suggest that the problem is with how SEH works in x64. If your exception should return in kernel mode when the stack expands, then you are stuck in the behavior: Case with the OnLoad disappearing exception . Windows handles your exception for you; the fix is ​​a workaround for individual x64 applications to run in the same way as x86.

Answer 5

I did my homework to find this: exception catch windows. Here are the piles and dismantling: