32 bit program on 64 bit computer doesn't crash on NullReferenceException

Question

I have a piece of code that throws a NullReferenceException:

dataSource.DataSource = GetView();

It throws because dataSource is null. GetView returns a DataTable.

However, when run on the one computer (64 bits), the program continues without any problems. The Exception does happen, because when I step, I end up completely somewhere else. The debugger doesn't stop though.

When run on another (32 bits) it throws the exception and my debugger stops.

My program is compiled for 32 bit. When I switch to "Any CPU", the 64 bits computer does crash on the exception.

Update I know how to fix my problem (I in fact already have). All I want to know if this is is somehow known behaviour or something which can be caused by a number of reasons.

_{The fix was 1) choose "Any CPU" (which made the 64-bit machine crash) and 2) check if dataSource is null before running this piece.}

Answer 1

Too many comments to make the duplicate link visible, so I'll make it an answer. This is a known problem on the 64-bit versions of Vista and Win7 when you debug a 32-bit program. There is normally a back-stop in the message dispatcher that catches unhandled exceptions when the dispatcher processes a Windows message and the event handler for the message throws an exception that isn't caught. That normally triggers the Application.ThreadException event on Winforms, the Dispatcher.UnhandledException event on WPF.

These events are however very awkward when you debug a program, it makes it hard to diagnose unhandled exceptions. So when you start your program with a debugger attached, this back-stop is disabled to allow the debugger to see the exception and display the Exception Assistant. Giving you a shot at fixing the problem.

Microsoft had a problem with certain messages that originate from the 64-bit window manager and traverse the Wow64 emulation layer boundary more than once. They could not figure out how to let an unhandled exception traverse through these layers, the exception info is strongly tied to the code model. So they did the only other thing they could do, they catch the exception. This normally activates the Application Compatibility dialog that lets the user opt-in to treat the exception as benign, everybody clicks Yes on this dialog since they have no idea whatsoever what the dialog is asking for and like their program to be compatible.

This is pretty fatal to your debugging attempt, the debugger can no longer see the unhandled exception since Windows catches and swallows it. So you get exactly what you described, code just stops running without any hint why. All you can see is a first chance exception notification in the Output window, very easy to miss.

I posted an answer about this issue before and documented workarounds for the problem. You'll find it here.