8

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.

Bart Friederichs
  • 33,050
  • 15
  • 95
  • 195
  • 5
    Why don't you attach a small piece of code that you have problems with? – Eiver Feb 20 '14 at 14:39
  • 1
    @Eiver I added the code. But the question is not about the code. I know why it throws the exception. It should throw it. – Bart Friederichs Feb 20 '14 at 14:43
  • @BartFriederichs: whatever happens there is most probably a problem buried in the parts of the code we don't see, some wrong configuration in your build process (we don't see either), or a problem specific with your IDE (which you did not mention with one word). IMHO its not a conceptual programming problem, thus voting to close. – Doc Brown Feb 20 '14 at 15:03
  • @DocBrown perhaps another StackExchange site might help me? As I said, just switching my build to "Any CPU" made the 64 bit computer crash. I am just trying to understand what's going on here, not fixing the crash. – Bart Friederichs Feb 20 '14 at 15:05
  • at a guess, either the offending line is being optimized out or by running 32 bit code on 64 you are triggering some sort of compatibility shim that fixes the problem for you – jk. Feb 20 '14 at 15:07
  • @BartFriederichs: this question *could* be suited for stackoverflow, but I hope my comment made clear that its hard to give you a good answer without having your original source code & project config & IDE. – Doc Brown Feb 20 '14 at 15:08
  • @DocBrown OK, thanks. I guess it is not a well known effect on 64/32 bit applications. – Bart Friederichs Feb 20 '14 at 15:13
  • 2
    @BartFriederichs I think the point here is that it is likely not directly or even weakly contributed to the number of bits. There are many factors at play, and in my experience, it is easy to let yourself get convinced of something just because it is the only difference you can see when it simply isn't the case. – Neil Feb 20 '14 at 16:31
  • 8
    Your question here is basically "something weird happens on my machine when I run a program that you don't have". OK, that's an interesting story, but not one that admits to anyone here giving you an explanation. If you want an understanding of it, **create the smallest possible program that reproduces the behaviour** and post that. Then we can actually *try* it on different machines and see what happens. – Eric Lippert Feb 20 '14 at 16:45
  • 4
    @BartFriederichs - Its simple. Its much more likely your code is at fault then the compiler having an code optimizing bug. The control in question is not new, its been used by hundreds of thousands of applications, that single line has been used hundreds of thousands of applications. – Security Hound Feb 20 '14 at 16:48
  • I updated my question a little, and it is already answered in the comments. It doesn't seem to be an obvious thing. – Bart Friederichs Feb 21 '14 at 08:08
  • without knowing how you fixed it, it's impossible to figure what could be the reason (eg, I've seen stuff like that when different VM schedulers were hiding or revealing data races in multithreaded code). Also, there's no `NullPointerException` in C#, do you by chance mean `NullReferenceException`? – gnat Feb 21 '14 at 09:00
  • @gnat It was a `NullReferenceException` yes (I also code a lot in Java, hence my mistake, the concepts are the same though). 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. – Bart Friederichs Feb 21 '14 at 10:22
  • Unfortunately I don't have enough rep here to vote to reopen, but I recommend people do, because this is a textbook case of a known bug! – Phoshi Feb 21 '14 at 11:13
  • 1
    @Phoshi It was closed for what I believe is a poor reason but it is still off topic here. This is a site meant more for conceptual questions about software development rather than diagnosing implementation and code problems. – maple_shaft Feb 21 '14 at 14:30

1 Answers1

14

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.

Community
  • 1
  • 1
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • I think you deserve +1 just because I didn't understand most of what you said. – Ian Feb 21 '14 at 15:41
  • Thanks for the explanation. I read [this piece](http://blog.paulbetts.org/index.php/2010/07/20/the-case-of-the-disappearing-onload-exception-user-mode-callback-exceptions-in-x64/) from that other answer and made me wondering about the "_For complicated reasons, we cannot propagate the exception back on 64-bit operating systems (amd64 and IA64)._" sentence. Any resources on that? – Bart Friederichs Feb 21 '14 at 15:58
  • Well, it is complicated. The exact way the Wow64 emulation works is completely undocumented. Doesn't help you anyway. Updating to Windows 8 helps. – Hans Passant Feb 21 '14 at 16:03