A 32-bit program on a 64-bit computer does not break into a 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 running on one computer (64 bits), the program continues without problems. An exception occurs because when I step, I finish completely somewhere else. The debugger does not stop.

When running on another (32 bit), it throws an exception and my debugger stops.

My program compiled for 32 bit. When I switch to “Any processor,” the 64-bit computer will fail.

Update. I know how to fix my problem (I already have one). All I want to know is whether it is some known behavior or something that can be caused by a number of reasons.

_{Correction: 1) select "Any processor" (which caused the 64-bit machine to crash) and 2) check if the dataSource is zero before starting this part.}

Answer 1

There are too many comments to make the duplicate link visible, so I will make it an answer. This is a known issue in 64-bit versions of Vista and Win7 when debugging a 32-bit program. Typically, the message manager has a return stop that catches unhandled exceptions when the manager processes the Windows message and the event handler for the message throws an exception that was not detected. This usually fires the Application.ThreadException event in Winforms, the Dispatcher.UnhandledException event in WPF.

These events, however, are very inconvenient when debugging a program, which makes it difficult to diagnose unhandled exceptions. Therefore, when you run your program with the debugger attached, this back stop is disabled to allow the debugger to see the exception and display the “Exception Assistant”. Give you a chance to solve the problem.

Microsoft has a problem with some messages that come from the 64-bit window manager and cross the border of the Wow64 emulation level more than once. They could not understand how to resolve an unhandled exception through these levels; the exception information is strongly tied to the code model. So they did the only thing they could do, they caught the exception. Usually this activates the application compatibility dialog box, which allows the user to select the exception as benign, all clicks “Yes” in this dialog box, because they have no idea what the dialog is asking for, and, like their program, should be compatible.

This is quite dangerous for your debugging attempt, the debugger can no longer see the unhandled exception, since Windows catches it and swallows it. So, you get exactly what you described, the code just stops working without any hints. All you can see is the first exception exclusion notification in the Output window, which is very easy to miss.

I posted the answer about this problem before and documented workarounds for this problem. Here you will find.