64 位计算机上的 32 位程序不会因 NullReferenceException 而崩溃 [英] 32 bit program on 64 bit computer doesn't crash on NullReferenceException

问题描述

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

I have a piece of code that throws a NullReferenceException:

dataSource.DataSource = GetView();

它抛出是因为 dataSource 是 null.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.

_{修复方法是 1) 选择Any CPU"(这会导致 64 位机器崩溃)和 2) 在运行此部分之前检查 dataSource 是否为空.}

推荐答案

评论太多，无法显示重复链接，所以我将其作为答案.当您调试 32 位程序时，这是 64 位版本的 Vista 和 Win7 上的一个已知问题.当调度程序处理 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 仿真层边界的某些消息存在问题.他们无法弄清楚如何让未处理的异常遍历这些层，异常信息与代码模型密切相关.所以他们做了他们唯一能做的另一件事，他们捕获异常.这通常会激活应用程序兼容性对话框，让用户选择将异常视为良性异常，每个人都在此对话框上单击是，因为他们不知道对话框要求什么并且喜欢他们的程序兼容.

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 而崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！