可能重复：   VS2010不能在64位版本的Windows 的显示未处理的异常消息WinForms应用程序

Possible Duplicate: VS2010 does not show unhandled exception message in a WinForms Application on a 64-bit version of Windows

我刚刚安装并开始使用VS2012。是以前使用VS2008防爆preSS。 VS2012是在Win 7 64位运行。 （previous开发环境是在XP 32位）。

I've just installed and started using VS2012. Was using VS2008 Express before. VS2012 is running on Win 7 64-bit. (Previous dev environment was on XP 32-bit).

刚走到这一步，与基础研究项目（的WinForms，VB），并发现VS无视未处理的异常。这样做的最后一行的应的会导致异常：

Just got so far with a basic research project (WinForms, VB), and found that VS is ignoring unhandled exceptions. The last line of this should cause an exception:

With cmd 
 .Connection = sqlConn
 .CommandType = CommandType.StoredProcedure
 .CommandText = "NameOfStoredProcedure"
 .Parameters.Add("@TheParameterName", SqlDbType.Int, -1)
 .Parameters("@TheParameterNameWithATypo").Direction = ParameterDirection.ReturnValue

果然，立即窗口中显示：

Sure enough, the Immediate window shows:

A first chance exception of type 'System.IndexOutOfRangeException' occurred in System.Data.dll

不过，code只进行跑步！

But the code just carries on running!

在调试/例外对话框中，我有一个抛出和用户未处理复选框每一种类型的异常。 用户未处理被勾选所有。我不想勾选抛出，因为我会处理异常和不希望打破对处理的异常。 （现在，我都没有的try ... catch块在所有 - 但调试器充当如果整个项目包含在一个）

In the Debug/Exceptions dialog, I have a "Thrown" and "User-Unhandled" checkbox for every type of exception. "User-Unhandled" is ticked for all. I don't want to tick "Thrown", because I will be handling exceptions and don't want to break on handled exceptions. (Right now, I have no Try...Catch blocks at all - but the debugger is acting as if the entire project is contained in one).

我已经通过所有的选项看起来等等，却找不到任何神奇的导通中断的异常选项。这不是我的code我在寻找帮助的 - 那就是有这样的情况我不能相信调试器来检测愚蠢的错误，我将不可避免地使

I've looked through all the options and so on, but can't find any magic "turn on Break on Exception" option. It's not my code I'm looking for help with - it's that with this happening I just can't trust the debugger to detect the stupid mistakes that I'll inevitably make.

发现了另一个question如果有人遇到了这一点，这个问题似乎有与Win64的。但是，VS Win64上真的不能用？我不是很相信 - 但没有打破未处理的异常有效地使之无法

Found another question where someone ran into this, and the problem there seemed to be with Win64. But is VS really unusable on Win64? I can't quite believe that - but not breaking on unhandled exceptions effectively makes it unusable.

编辑： 感谢您的意见。我试图Neolisk的解决方案，而不得不改变code稍微因为两个处理程序的签名是不同的：

Thanks for all your comments. I tried Neolisk's solution, but had to change the code slightly because the signatures of the two handlers are different:

Public Sub Main()
    AddHandler Application.ThreadException, AddressOf ThreadExceptionHandler
    Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException)
    AddHandler AppDomain.CurrentDomain.UnhandledException, AddressOf UnhandledExceptionHandler

    Form1.Show()
End Sub

Friend Sub ThreadExceptionHandler(sender As Object, e As System.Threading.ThreadExceptionEventArgs)

End Sub

Friend Sub UnhandledExceptionhandler(sender As Object, E As System.UnhandledExceptionEventArgs)
End Sub

这个工作 - 谢谢！但它要求我关闭应用程序框架（否则应用程序无法使用子主要作为启动）。而TBH我是个太过.NET初学者，甚至肯定知道是什么造成的效果/优点/缺点。我已经在你所提供的所有链接阅读起来，并获得所发生的事情，但不想涉足，如果我能避免它...

This worked - thanks! But it required me to disable the Application Framework (otherwise the app can't use Sub Main as startup). And TBH I'm too much of a .NET beginner to even know for sure what the effect/advantages/disadvantages of that are. I've read up on the links you've all provided, and get what's happening, but don't want to get involved if I can avoid it...

幸运的是，应用此修补程序在 KB976038 很适合我。在code，应该引起异常和中断执行在调试模式下，流失Form_Load事件，现在做这种预期。这是使应用程序框架下，Form1作为启动对象，和code以上注释掉了。

Luckily, applying the hotfix in KB976038 has worked for me. The code that should cause an exception and a break in execution in debug mode, running off the Form_Load event, now does this as expected. This is with Application Framework enabled, Form1 as the startup object, and the code above commented out.

EDIT2： 不，该修补程序不起作用。原来的坏参数名行引起了code停止与异常。但随着DBNull->的Int32转换异常下一行只是导致该错误框（没有调试的可能性）：

No, that hotfix doesn't work. The original "bad parameter name" line caused the code to stop with an exception. But a subsequent line with a DBNull->Int32 conversion exception just caused this error box (and no debugging possibility):

vshost.exe - 应用程序错误内部错误：未处理的异常在   调试器:: HandleIPCEvent。事件ID = 0x246异常code = 0x0000005，   EIP = 0x70d58101。进程ID = 0xbec（3052），线程ID = 0xb1c（2844）。

vshost.exe - Application Error INTERNAL ERROR: Unhandled exception in Debugger::HandleIPCEvent. Event ID=0x246 Exception code=0x0000005, Eip=0x70d58101. Process ID=0xbec (3052), Thread ID=0xb1c (2844).

我真的AP preciate您的所有意见 - 但在我看来，这是一个致命弱点：如何开发使用VS如果他们不能相信的异常将调试的？我不应该记得开始与子主，并把每一次我要开发的东西这些特殊的线路：或记住，你不能使用code中的Form_Load？我会建议我们停止使用Win7的64位作为一个开发的操作系统。

I really appreciate all your comments - but to my mind this is a deal-breaker: how can a developer use VS if they can't trust that exceptions will be debuggable? I shouldn't have to remember to start with a Sub Main and put those special lines in every time I want to develop something: or remember that you can't use code in Form_Load? I'm going to recommend that we stop using Win7 64-bit as a development OS.

推荐答案

我觉得你有你的code。在的Form_Load ，因为这将解释。如果是这种情况，看看在这里我的问题：Explain在Visual Studio 2010及以上，WinForms和WPF 的严重错误。这是一个已知的问题。你需要要么把你的code OUT 的Form_Load 或让你的应用程序开始从子主，并把这些你已经找到了C＃3魔纹。这里有相同的3线VB.NET：

I think you have your code in Form_Load, as that would explain it. If this is the case, have a look at my question here: Explain critical bug in Visual Studio 2010 and up, WinForms and WPF. It is a known issue. You need to either put your code out of Form_Load or make your application start from Sub Main and put those 3 magic lines you already found for C#. Here are the same 3 lines for VB.NET:

AddHandler Application.ThreadException, AddressOf YourExceptionHandler
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException)
AddHandler AppDomain.CurrentDomain.UnhandledException, AddressOf YourExceptionHandler

据我记得，第一行实际上解决这个问题，其他2是用于支付其他的神秘的错误。它不会伤害始终都包含它们在你的程序的一开始，只是为了安全起见。 YourExceptionHandler 可以是一个空的方法。一旦你添加这些3线，异常捕获应该开始按预期工作。

As far as I remember, the first line actually fixes this problem, the other 2 are to cover for other mysterious errors. It does not hurt to always include them all at the very start of your program, just to be safe. YourExceptionHandler can be an empty method. Once you add these 3 lines, exception catching should start working as expected.