Debugger ignores errors in dynamically loaded DLLs

Question

Hello.

I have a very strange problem related to debugging of self-coded DLLs. I have an MFC-driven dialog-based application, several projects linked statically and several DLL-projects which are loaded at runtime.

I build solution in debug, run the application and I can easily debug those DLL-projects. Now the problem. If there is some obvious runtime error in DLL like following

int* i = 0;
*i = 4;

debugger asserts no error, throws no exception and silently returns to idle state with even no (visible) stack returns. It looks like when I'm hitting F10 on the statement *i = 4;, the control returns to main application window and program execution continues as nothing happened! And if there are no errors in the code, it executes fine. But I expect errors to be asserted in this case! And they are - in the main application's code.

I use LoadLibrary() function to load my DLL into application. DLL itself has MFC statically linked, same as every other project in solution has.

Any ideas? Don't even know what question to google...

Answer 1

Most likely you are loading the DLL with LoadLibrary() from an incorrect location and the lack of PDBs prevent the debugger from setting break point. You may also load the retail DLLs with Asserts disabled (if by 'errors to be asserted' you mean you have ASSERT in code). If the error is a page fault (as the AV you show in your example) and your debugger doesn't break, it means that the exception is handled. You can always turn on the break on first chance, eg. sxe av. Not sure how you do that from the code editing tool, but you can always use a real debugger.

Answer 2

There's an exception handler somewhere in your code base that is swallowing exceptions. Look for SetUnhandledExceptionFilter first. Also: Debug + Exceptions, Win32 Exceptions, tick the Thrown checkbox.

Answer 3

Oh, it seems like the bug is not related to DLL at all. Debugger behaves the same way in the main application module too. I've inserted this code-snippet into OnInitDialog() function and into button-click OnBnClickedButton1() handler function.

In the first case (when inside OnInitDialog()), exception is thrown as usual and the program could not recover from this error. The following messages are traced in output window:

First-chance exception at 0x00a3a83e in dmc.exe: 0xC0000005: Access violation writing location 0x00000000.

First-chance exception at 0x00a3a83e in dmc.exe: 0xC0000005: Access violation writing location 0x00000000.

Unhandled exception at 0x00a3a83e in dmc.exe: 0xC0000005: Access violation writing location 0x00000000.

But in second case (when inside OnBnClickedButton1()) no exception is thrown, execution of OnBnClickedButton1() is aborted and the program continues to run normally. The following messages are traced in output window:

First-chance exception at 0x00a3c23f in dmc.exe: 0xC0000005: Access violation writing location 0x00000000.

So it seems like some top-level exception handler appears after the application is initialized. I've created new test application and tried the same thing with it - exceptions are thrown in both cases. I've compared their project-settings (diff on .vcproj files) and found no differences related to this issue.

Maybe this behavior is controlled by some weird MFC macro-defines? Or have I unintentionally affected it by some other settings?

Sorry for mistakes in the first version of problem.

Answer 4

Oh, it turned out that problem is caused by OpenGL wglMakeCurrent() call and is experienced only under Windows 7 64-bit with NVIDIA GeForce 8800 graphic card, meanwhile all works fine under Windows Vista 32-bit.

I asked new question here. Thanks for your feedback.