Question

This is an unusual question to ask but here goes:

In my code, I accidentally dereference NULL somewhere. But instead of the application crashing with a segfault, it seems to stop execution of the current function and just return control back to the UI. This makes debugging difficult because I would normally like to be alerted to the crash so I can attach a debugger.

What could be causing this?

Specifically, my code is an ODBC Driver (ie. a DLL). My test application is ODBC Test (odbct32w.exe) which allows me to explicitly call the ODBC API functions in my DLL. When I call one of the functions which has a known segfault, instead of crashing the application, ODBC Test simply returns control to the UI without printing the result of the function call. I can then call any function in my driver again.

I do know that technically the application calls the ODBC driver manager which loads and calls the functions in my driver. But that is beside the point as my segfault (or whatever is happening) causes the driver manager function to not return either (as evidenced by the application not printing a result).

One of my co-workers with a similar machine experiences this same problem while another does not but we have not been able to determine any specific differences.

Answer 1

Windows has non-portable language extensions (known as “SEH”) which allow you to catch page faults and segmentation violations as exceptions.

There are parts of the OS libraries (particularly inside the OS code that processes some window messages, if I remember correctly) which have a __try block and will make your code continue to run even in the face of such catastrophic errors. Likely you are being called inside one of these __try blocks. Sad but true.

Check out this blog post, for example: The case of the disappearing OnLoad exception – user-mode callback exceptions in x64

Update:

I find it kind of weird the kind of ideas that are being attributed to me in the comments. For the record:

• I did not claim that SEH itself is bad.

  I said that it is “non-portable”, which is true. I also claimed that using SEH to ignore STATUS_ACCESS_VIOLATION in user mode code is “sad”. I stand by this. I should hope that I had the nerve to do this in new code and you were reviewing my code that you would yell at me, just as if I wrote catch (...) { /* Ignore this! */ }. It’s a bad idea. It’s especially bad for access violation because getting an AV typically means your process is in a bad state, and you shouldn’t continue execution.

• I did not argue that the existence of SEH means that you must swallow all errors.

  Of course SEH is a general mechanism and not to blame for every idiotic use of it. What I said was that some Windows binaries swallow STATUS_ACCESS_VIOLATION when calling into a function pointer, a true and observable fact, and that this is less than pretty. Note that they may have historical reasons or extenuating circumstances to justify this. Hence “sad but true.”

• I did not inject any “Windows vs. Unix” rhetoric here. A bad idea is a bad idea on any platform. Trying to recover from SIGSEGV on a Unix-type OS would be equally sketchy.