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