StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POVS 2012 (VB.net) is ignoring unhandled exceptions on Windows 7 64bit
text
Body
copied!<blockquote> <p><strong>Possible Duplicate:</strong><br> <a href="https://stackoverflow.com/questions/4933958/vs2010-does-not-show-unhandled-exception-message-in-a-winforms-application-on-a">VS2010 does not show unhandled exception message in a WinForms Application on a 64-bit version of Windows</a> </p> </blockquote> <p>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).</p> <p>Just got so far with a basic research project (WinForms, VB), and found that VS is ignoring unhandled exceptions. The last line of this <em>should</em> cause an exception:</p> <pre><code>With cmd .Connection = sqlConn .CommandType = CommandType.StoredProcedure .CommandText = "NameOfStoredProcedure" .Parameters.Add("@TheParameterName", SqlDbType.Int, -1) .Parameters("@TheParameterNameWithATypo").Direction = ParameterDirection.ReturnValue </code></pre> <p>Sure enough, the Immediate window shows:</p> <pre><code>A first chance exception of type 'System.IndexOutOfRangeException' occurred in System.Data.dll </code></pre> <p>But the code just carries on running!</p> <p>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).</p> <p>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.</p> <p>Found another <a href="https://stackoverflow.com/questions/7572995/how-can-i-get-winforms-to-stop-silently-ignoring-unhandled-exceptions">question</a> 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.</p> <p><strong>EDIT:</strong> 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:</p> <pre><code>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 </code></pre> <p>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...</p> <p>Luckily, applying the hotfix in <a href="http://support.microsoft.com/kb/976038" rel="nofollow noreferrer">KB976038</a> 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.</p> <p><strong>EDIT2:</strong> 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):</p> <blockquote> <p>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).</p> </blockquote> <p>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.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload