我有一段代码会引发NullReferenceException：
dataSource.DataSource = GetView();
它因为dataSource为null而抛出。 GetView会返回DataTable。
但是，当在一台计算机（64位）上运行时，程序会继续运行而不会出现任何问题。确实发生了异常，因为当我迈出这一步时，我最终完全在其他地方结束。调试器不会停止。
当在另一个（32位）上运行时，它会抛出异常而我的调试器会停止。
我的程序编译为32位。当我切换到“任何CPU”时，64位计算机会在异常时崩溃。
更新我知道如何解决我的问题（事实上我已经有了）。所有我想知道的是，这是某种已知的行为还是可能由多种原因造成的。
修复是1）选择“任何CPU”（使64位机器崩溃）和2）在运行此文件之前检查dataSource是否为空。
答案 0 :(得分：14)
太多评论使重复链接可见，所以我会把它作为答案。当您调试32位程序时，这是64位版本的Vista和Win7上的已知问题。当调度程序处理Windows消息并且消息的事件处理程序抛出未捕获的异常时，消息调度程序通常会有一个后退停止捕获未处理的异常。 通常触发Winforms上的Application.ThreadException事件，WPF上的Dispatcher.UnhandledException事件。
然而，当您调试程序时，这些事件非常笨拙，这使得很难诊断未处理的异常。因此，当您使用附加的调试器启动程序时，将禁用此反向停止以允许调试器查看异常并显示异常助手。为您解决问题提供帮助。
Microsoft在某些消息中遇到问题，这些消息来自64位窗口管理器并且不止一次遍历Wow64仿真层边界。他们无法弄清楚如何让未处理的异常遍历这些层，异常信息与代码模型紧密相关。所以他们做了他们唯一能做的事情，他们抓住例外。这通常会激活“应用程序兼容性”对话框，允许用户选择将异常视为良性，每个人都在此对话框上单击“是”，因为他们不知道对话框要求的内容以及它们的程序是否兼容。
这对于您的调试尝试非常致命，调试器无法再看到未处理的异常，因为Windows会捕获并吞下它。所以你得到了你所描述的，代码只是停止运行而没有任何提示原因。你只能看到输出窗口中的第一次机会异常通知，很容易错过。
我之前发布了有关此问题的答案，并记录了该问题的解决方法。你会发现它here。