VS2008 调试器不会因未处理的异常而中断
我的 vs 调试器遇到了一个奇怪的问题。 当在 vs 调试器下运行我的程序时，调试器不会因未处理的异常而中断。 相反，控制权返回给 VS，就像程序正常退出一样。 如果我查看输出选项卡，会在线程终止之前列出第一次机会异常。
我了解如何使用“调试”菜单中的“异常”框。 我检查了未处理异常的中断。 如果我检查第一次机会异常以查找正在发生的特定异常，则调试器将停止。
然而，据我了解，调试器也应该在任何“未处理的异常”上停止。 它不是为我做这件事。
以下是“输出”选项卡的最后几行：
A first chance exception of type 'System.ArgumentOutOfRangeException' occurred in mscorlib.dll
The thread 0x60c has exited with code 0 (0x0).
The program '[3588] ALMSSecurityManager.vshost.exe: Managed' has exited with code -532459699 (0xe0434f4d).
我不明白为什么异常在未处理时被标记为“第一次机会”异常。
我相信 0xe0434f4d 退出代码是一般 COM 错误。
有任何想法吗？
地铁。
I'm having an odd problem with my vs debugger. When running my program under the vs debugger, the debugger does not break on an unhandled exception. Instead control is returned to VS as if the program exited normally. If I look in the output tab, There is a first-chance exeption listed just before the thread termination.
I understand how to use the "Exceptions" box from the Debug menu. I have the break on unhandled exceptions checked. If I check first-chance exceptions for the specific exeption that is occuring, the debugger will stop.
However, it is my understanding that the debugger should also stop on any 'Unhandled-Exceptions'. It is not doing this for me.
Here are the last few lines of my Output tab:
A first chance exception of type 'System.ArgumentOutOfRangeException' occurred in mscorlib.dll
The thread 0x60c has exited with code 0 (0x0).
The program '[3588] ALMSSecurityManager.vshost.exe: Managed' has exited with code -532459699 (0xe0434f4d).
I don't understand why the exception is flagges as a "first chance" exception when it is unhandled.
I believe that the 0xe0434f4d exit code is a generic COM error.
Any Ideas?
Metro.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
当我读到有关“异常...”对话框中有两个复选框的答案时，我返回并再次打开该对话框。 我只有一列复选框——用于“抛出”的中断。
事实证明，如果您没有在调试选项中选中“仅启用我的代码（仅限托管）”，则“异常”对话框中不会显示“用户未处理”列。
我选择了“仅启用我的代码”选项，并验证是否为所有异常类别选择了“异常”对话框上的“用户未处理”复选框。
我能够获得未处理的异常来闯入一个会话的调试器。 但第二天我回来时，行为还是和以前一样。
地铁。
When I read the answer about having two check boxes in the "Exception..." dialog, I went back and opened the dialog again. I only had one column of check boxes -- for break on "Thrown".
As it turns out, if you do not have "Enable Just My Code (Managed Only)" checked in the Debug options, the "User-Unhandled" column does not show in the "Exceptions" dialog.
I selected the "Enable Just My Code" option and verified that the "User-unhandled" checkbox on the "Exceptions" dialog was selected for all of the exception categories.
I was able to get unhandled exceptions to break into the debugger for one session. But when I came back the next day, the behavior was as before.
Metro.
如果您使用的是 64 位操作系统，那么您很可能会受到导致异常消失的操作系统级别行为的影响。 重现它的最可靠方法是创建一个新的 WinForm 应用程序，只需在 OnLoad 中抛出异常； 它看起来不会被抛出。 看看这些：
第一个是我从 Google 找到的（在这个线程没有帮助之后） ，该线程将我引向了以下两个。 第二个有最好的解释，第三个是 Microsoft bug/ticket（再次确认这是“设计使然”的行为）。
因此，基本上，如果您的应用程序在返回堆栈的过程中抛出一个触及内核模式边界的异常，它就会在该边界处被阻塞。 Windows 团队认为处理该问题的最佳方法是假装异常已得到处理； 执行继续进行，就好像一切正常完成一样。
哦，这种情况随处可见。 调试与发布无关。 .Net 与 C++ 无关。 这是操作系统级别的行为。
想象一下，您必须将一些关键数据写入磁盘，但它在内核模式边界的错误一侧失败。 其他代码稍后尝试使用它，如果幸运的话，您会发现数据有问题......但为什么呢？ 我敢打赌，您永远不会考虑您的应用程序无法写入数据——因为您预计会抛出异常。
混蛋。
If you're on a 64-bit OS, there's a pretty good chance you're being bitten by an OS-level behavior that causes exceptions to disappear. The most reliable way to reproduce it is to make a new WinForm application that simply throws an exception in OnLoad; it will appear to not get thrown. Take a look at these:
The first is what I found from Google (after this thread didn't help), and that thread led me to the following two. The second has the best explanation, and the third is the Microsoft bug/ticket (that re-affirms that this is "by design" behavior).
So, basically, if your application throws an Exception that hits a kernel-mode boundary on its way back up the stack, it gets blocked at that boundary. And the Windows team decided the best way to deal with it was to pretend the exception was handled; execution continues as if everything completed normally.
Oh, and this happens everywhere. Debug versus Release is irrelevant. .Net vs C++ is irrelevant. This is OS-level behavior.
Imagine you have to write some critical data to disk, but it fails on the wrong side of a kernal-mode boundary. Other code tries to use it later and, if you're lucky, you detect something's wrong with the data ...but why? I bet you never consider that your application failed to write the data---because you expected an exception would be thrown.
Jerks.
我遇到了类似的问题，并检查“仅启用我的代码（仅限托管）”解决了该问题，而如果我将其重新关闭，则问题又回来了，不知道为什么（但有可能某些 DLL 似乎得到了未选中时加载会导致该行为）。
I had a similar problem, and checking "Enable Just My Code (Managed Only)" fixed the problem, while if I turned it back off then the problem came back, no clue why (but it is possible that some DLL's that appear to get loaded when it is unchecked cause the behavior).
每隔一段时间，这种情况也会发生在我身上。 这看起来像是一个错误或其他什么，因为当我复制该场景时，异常被捕获并像往常一样显示。
Once every while this happens to me as well. It seems like a bug or something, as when I replicate the scenario the exception is caught and shown as usual.
“异常...”框中有两个复选框，我通常必须同时检查它们才能使其在未处理的异常时中断。 不管它看起来只是你需要检查一下。
There are two checkboxes in the "Exceptions..." box, I usually have to have them both checked to get it to break on unhandled exceptions. Regardless that it only reads like you need to have one checked.
Ctl-D、E 将打开“例外”窗口。 您可以设置想要中断或不想中断的例外情况。
Ctl-D, E brings up the Exceptions window. You can set what exceptions you want to, and don't want to, break on.