问题描述
我有一段代码抛出 NullReferenceException ：
dataSource.DataSource = GetView();
抛出该错误是因为 dataSource 是空。 GetView 返回 DataTable 。
It throws because dataSource is null. GetView returns a DataTable.
但是，运行时在一台计算机（64位）上，程序继续运行，没有任何问题。确实会发生异常，因为当我踩踏时，我会完全进入其他位置。
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.
在另一个（32位）上运行时，它将引发异常，调试器将停止。
When run on another (32 bits) it throws the exception and my debugger stops.
我的程序编译为32位。当我切换到任何CPU时，该64位计算机确实会因异常而崩溃。
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.
推荐答案
注释太多，无法显示重复的链接，因此我将其作为答案。在调试32位程序时，这是Vista和Win7的64位版本上的一个已知问题。消息调度程序中通常有一个后台程序，当调度程序处理Windows消息并且该消息的事件处理程序引发未捕获的异常时，该捕获程序会捕获未处理的异常。 通常会触发Winforms上的Application.ThreadException事件，而WPF上会触发Dispatcher.UnhandledException事件。
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对于源自64位窗口管理器且多次遍历Wow64仿真层边界的某些消息存在问题。他们无法弄清楚如何让未处理的异常遍历这些层，异常信息与代码模型紧密相关。因此，他们做了他们唯一能做的事情，他们 catch 异常。通常，这会激活应用程序兼容性对话框，该对话框允许用户选择将异常视为良性，每个人都在此对话框上单击是，因为他们不知道对话框的要求是什么，并且不希望自己的程序兼容。
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.
这对您的调试尝试非常致命，由于Windows捕获并吞下了该异常，因此调试器无法再看到未处理的异常。这样您就可以准确地描述您的内容，代码会停止运行，而没有任何提示原因。您所看到的只是在输出窗口中的第一次机会异常通知，非常容易错过。
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.
这篇关于64位计算机上的32位程序不会在NullReferenceException上崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！