VS 2012 (VB.net) is ignoring unhandled exceptions on Windows 7 64bit [duplicate]

Question

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

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).

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

But the code just carries on running!

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).

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.

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.

EDIT: 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

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...

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: 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 - 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).

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.

Answer 1

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

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.