VS2008调试器不会破坏未处理的异常

本文介绍了VS2008调试器不会破坏未处理的异常的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述 我的vs调试器有一个奇怪的问题。当在vs调试器下运行我的程序时，调试器不会破坏未处理的异常。而是将控制权返回给VS，就像程序正常退出一样。如果我查看输出选项卡，则在线程终止之前列出一个第一次机会exetion。

我了解如何使用调试中的异常框菜单。我已经对未处理的异常进行了检查。如果我检查发生的特定exeption的第一次机会异常，调试器将停止。

但是，我的理解是，调试器也应该停止在任何'未处理的异常'。这不是为了我这样做。

以下是输出选项卡的最后几行：

mscorlib.dll中发生类型为System.ArgumentOutOfRangeException的第一次机会异常线程0x60c已退出代码0（0x0）。 程序[3588] ALMSSecurityManager.vshost.exe：Managed已退出，代码为-532459699（0xe0434f4d）。

我不明白为什么异常被标记为第一次机会异常，当它被处理

我相信0xe0434f4d退出代码是一个通用的COM错误。

任何想法？ >

Metro。

解决方案

如果您使用的是64位操作系统，有一个很好的机会，你被一个操作系统级别的行为，导致异常消失。最可靠的重现方式是制作一个新的WinForm应用程序，只需在OnLoad中引发异常;它似乎不会被抛出。看看这些：

Visual Studio不会打破Windows 64位 的未处理异常

• http：// social.msdn.microsoft/Forums/en/vsdebug/thread/69a0b831-7782-4bd9-b910-25c85f18bceb

消失的OnLoad异常情况

x64开发机器上的静默异常（Microsoft连接）

• https：// connect.microsoft/VisualStudio/feedback/details/357311/silent-exceptions-on-x64-development-machines

第一个是我从Google发现的（此线程没有帮助），那个线程让我来了以下两个。第二个是最好的解释，第三个是Microsoft错误/机票（重申这是设计行为）。

所以，基本上，如果您的应用程序抛出一个Exception，它在备份堆栈的路上遇到内核模式边界，则会在该边界被阻塞。而Windows团队决定处理最好的方式是假装处理异常;执行继续，就好像一切正​​常完成。

哦，这发生在任何地方。调试与释放是无关紧要的。 .NET与C ++无关。这是操作系统级的行为。

想象一下，您必须将一些关键数据写入磁盘，但在内核模式边界错误的一侧失败。其他代码尝试以后使用它，如果你幸运的话，你会发现数据有问题，但为什么？我敢打赌你永远不会认为您的应用程序无法写入数据---因为您预计会抛出异常。

Jerks。

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.

解决方案

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:

Visual Studio doesn't break on unhandled exception with windows 64-bit

• http: // social.msdn.microsoft/Forums/en/vsdebug/thread/69a0b831-7782-4bd9-b910-25c85f18bceb

The case of the disappearing OnLoad exception

Silent exceptions on x64 development machines (Microsoft Connect)

• https: // connect.microsoft/VisualStudio/feedback/details/357311/silent-exceptions-on-x64-development-machines

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.