64 位计算机上的 32 位程序不会因 NullReferenceException 而崩溃

我有一段代码抛出一个NullReferenceException:

dataSource.DataSource = GetView();

它抛出是因为dataSource is null. GetView返回一个DataTable.

但是，当在一台计算机（64 位）上运行时，程序可以继续运行，不会出现任何问题。异常确实发生了，因为当我迈出一步时，我完全到了别的地方。但调试器不会停止。

当在另一个（32 位）上运行时，它会抛出异常并且我的调试器停止。

我的程序是为 32 位编译的。当我切换到“任何 CPU”时，64 位计算机确实因异常而崩溃。

Update我知道如何解决我的问题（事实上我已经知道了）。我只想知道这是否是某种已知的行为，或者可能是由多种原因引起的。

_{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.}

太多评论使重复链接可见，所以我将其作为答案。这是在 64 位版本的 Vista 和 Win7 上调试 32 位程序时的一个已知问题。消息调度程序中通常有一个后停止程序，当调度程序处理 Windows 消息并且该消息的事件处理程序抛出未捕获的异常时，它会捕获未处理的异常。那normally在 Winforms 上触发 Application.ThreadException 事件，在 WPF 上触发 Dispatcher.UnhandledException 事件。

然而，当您调试程序时，这些事件非常尴尬，它使得诊断未处理的异常变得困难。因此，当您在附加调试器的情况下启动程序时，此后停止功能将被禁用，以允许调试器查看异常并显示异常助手。为您提供解决问题的机会。

Microsoft 对源自 64 位窗口管理器并多次穿越 Wow64 模拟层边界的某些消息存在问题。他们无法弄清楚如何让未处理的异常遍历这些层，异常信息与代码模型紧密相关。所以他们做了他们唯一能做的另一件事，他们catch例外。这通常会激活“应用程序兼容性”对话框，让用户选择将异常视为良性，每个人都在此对话框上单击“是”，因为他们不知道该对话框要求什么，并且希望他们的程序兼容。

这对于您的调试尝试来说是非常致命的，调试器无法再看到未处理的异常，因为 Windows 捕获并吞下了它。因此，您得到的正是您所描述的内容，代码只是停止运行，没有任何提示原因。您只能在“输出”窗口中看到第一次机会异常通知，很容易错过。

我之前发布了有关此问题的答案并记录了该问题的解决方法。你会找到它here https://stackoverflow.com/a/4934010/17034.