5

I have an MFC-driven dialog-based application created with MSVS2005. Here is my problem step by step. I have button on my dialog and corresponding click-handler with code like this:

int* i = 0;
*i = 3;

I'm running debug version of program and when I click on the button, Visual Studio catches focus and alerts "Access violation writing location" exception, program cannot recover from the error and all I can do is to stop debugging. And this is the right behavior.

Now I add some OpenGL initialization code in the OnInitDialog() method:

    HDC DC = GetDC(GetSafeHwnd());
    static PIXELFORMATDESCRIPTOR pfd =
    {
      sizeof(PIXELFORMATDESCRIPTOR), // size of this pfd
      1, // version number
      PFD_DRAW_TO_WINDOW | // support window
      PFD_SUPPORT_OPENGL | // support OpenGL
      PFD_DOUBLEBUFFER, // double buffered
      PFD_TYPE_RGBA, // RGBA type
      24, // 24-bit color depth
      0, 0, 0, 0, 0, 0, // color bits ignored
      0, // no alpha buffer
      0, // shift bit ignored
      0, // no accumulation buffer
      0, 0, 0, 0, // accum bits ignored
      32, // 32-bit z-buffer
      0, // no stencil buffer
      0, // no auxiliary buffer
      PFD_MAIN_PLANE, // main layer
      0, // reserved
      0, 0, 0 // layer masks ignored
    };

    int pixelformat = ChoosePixelFormat(DC, &pfd);
    SetPixelFormat(DC, pixelformat, &pfd);

    HGLRC hrc = wglCreateContext(DC);
    ASSERT(hrc != NULL);
    wglMakeCurrent(DC, hrc);

Of course this is not exactly what I do, it is the simplified version of my code. Well now the strange things begin to happen: all initialization is fine, there are no errors in OnInitDialog(), but when I click the button... no exception is thrown. Nothing happens. At all. If I set a break-point at the *i = 3; and press F11 on it, the handler-function halts immediately and focus is returned to the application, which continue to work well. I can click button again and the same thing will happen.

It seems like someone had handled occurred exception of access violation and silently returned execution into main application message-receiving cycle.

If I comment the line wglMakeCurrent(DC, hrc);, all works fine as before, exception is thrown and Visual Studio catches it and shows window with error message and program must be terminated afterwards.

I experience this problem under Windows 7 64-bit, NVIDIA GeForce 8800 with latest drivers (of 11.01.2010) available at website installed. My colleague has Windows Vista 32-bit and has no such problem - exception is thrown and application crashes in both cases.

Well, hope good guys will help me :)

PS The problem originally where posted under this topic.

Community
  • 1
  • 1
Mikhail
  • 20,685
  • 7
  • 70
  • 146
  • That's funny, I had the same problem recently... if you wrap exception-throwing code in a try-catch block, it will catch the exception there, but if the exception propagates up in to MFC code it does seem to get swallowed. I guess a potential workaround is to use try-catch blocks yourself. – AshleysBrain Jan 29 '10 at 15:52
  • I can confirm this problem and it has to do with OpenGL on windows vista 64 bits and windows 7 64 bits. Looking for the answer myself :) – rtn Feb 12 '10 at 16:38
  • This seems similar to my problem: http://stackoverflow.com/questions/2622200/exceptions-silently-caught-by-windows-how-to-handle-manually – Mark Ingram Apr 12 '10 at 13:25

4 Answers4

3

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.

The solution is to wrap your wndproc (or hookproc) with a try/except frame so you can catch the exception before Windows does.

Thanks to Skywing at http://www.nynaeve.net/

We've contacted nVidia about this issue, but they say it's not their bug, but rather the Microsoft's. Could you please tell how you located the exception handler? And do you have some additional information, e.g. some feedbacks from Microsoft?

I used the "!exchain"-command in WinDbg to get this information.

rtn
  • 127,556
  • 20
  • 111
  • 121
  • We've contacted nVidia about this issue, but they say it's not their bug, but rather the Microsoft's. Could you please tell how you located the exception handler? And do you have some additional information, e.g. some feedbacks from Microsoft? – Mikhail May 25 '10 at 14:39
1

Rather than wrapping the WndProc or hooking all WndProcs, you could use Vectored Exception Handling:

http://msdn.microsoft.com/en-us/library/ms679274.aspx

Mark Ingram
  • 71,849
  • 51
  • 176
  • 230
  • I take it back. We had to revert this change because it was overly aggressive. There were exceptions we wanted to leave alone and allow to be handled the normal way, but we couldn't distinguish them from Access Violations and the like, which we want to crash. – Brian Dec 17 '11 at 02:15
  • I have a base class for all user interface that overrides WndProc with __try / __catch. The handler then calls the crash reporter in release, in debug it continues so we can debug the crash. – Mark Ingram Dec 18 '11 at 19:58
  • After further investigation we discovered our problem was actually a Windows bug with 32-bit programs running on 64-bit Operating Systems. There's a separate article on stack overflow about it, that I think was the real problem for the Original Poster as well. – Brian Jan 10 '12 at 23:37
0

First, both behaviors are correct. Dereferencing a null pointer is "undefined behavior", not a guaranteed access violation.

First, find out whether this is related to exception throwing or only to accessing memory location zero (try a different exception).

If you configure Visual Studio to stop on first-chance access violations, does it break?

Call VirtualQuery(NULL, ...) before and after glMakeCurrent and compare. Maybe the nVidia OpenGL drivers VirtualAlloc page zero (a bad idea, but not impossible or illegal).

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
  • Same behavior for any exceptions, including manually raised with throw operator. If I configure Visual Studio to stop on first-chance exceptions, it breaks. – Mikhail Feb 16 '10 at 09:07
  • Sounds like a vectored exception handler is registered and eats the exception. http://msdn.microsoft.com/en-us/library/ms681420(VS.85).aspx Break at the first-chance exception, then start single-stepping (make sure you have the option "Just My Code" disabled so that you can step through other libraries). Probably some handler returns EXCEPTION_CONTINUE_EXECUTION instead of EXCEPTION_CONTINUE_SEARCH. – Ben Voigt Feb 17 '10 at 21:59
  • Compared results of VirtualQuery(NULL, ...), results are the same for calls before and after wglCreateContext(). – Mikhail Feb 18 '10 at 06:49
  • The VirtualQuery assumption was for troubleshooting if NULL pointer exceptions weren't triggering but other exceptions were. Since you have all exceptions being swallowed, step through vectored exception handlers. You should at least get some insight into what DLLs contain the handlers and why the behavior is different between your two systems. – Ben Voigt Feb 18 '10 at 15:42
  • I'm not sure that's the case. I think Mark Ingram's comment was closer to the mark. Vectored Exception Handling seems to be the solution, not the problem. I had this same problem, and Iadded a handler that issues an appfatal and that gets it to crash on exceptions. Prior to adding that I couldn't manage to step into the vectored exception handling. Once I added one, I was able to step into it, leading me to believe my handler is the only one, and handling by crashing is the correct way to get that behavior. – Brian Dec 06 '11 at 22:53
0

I found this question when I was looking at a similar problem. Our problem turned out to be silent consumption of exceptions when running a 32-bit application on 64-bit Windows.

http://connect.microsoft.com/VisualStudio/feedback/details/550944/hardware-exceptions-on-x64-machines-are-silently-caught-in-wndproc-messages

There’s a fix available from Microsoft, though deploying it is somewhat challenging if you have multiple target platforms:

http://support.microsoft.com/kb/976038

Here's an article on the subject describing the behavior:

http://blog.paulbetts.org/index.php/2010/07/20/the-case-of-the-disappearing-onload-exception-user-mode-callback-exceptions-in-x64/

This thread on stack overflow also describes the problem I was experiencing: Exceptions silently caught by Windows, how to handle manually?

Community
  • 1
  • 1
Brian
  • 134
  • 4