VS2008 Debugger does not break on unhandled exception

L

6

2

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.

Leucoderma answered 19/9, 2008 at 15:41 Comment(0)

N

5

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

Naumann answered 4/12, 2010 at 17:13 Comment(5)

I promise, it wasn't out of malice! The alternatives were to make your machine run extra, super slow (save off the full register context constantly), or instacrash your app once an SEH exception occurs in a user-mode callback. The good news is, user-mode callbacks are solely(*) within window procedures, so this doesn't affect service apps, nor does it affect worker threads (i.e. any non-windowing thread) – Snatchy 14/1, 2011 at 8:24

@Paul - I truly would have preferred the "instacrash". At least I know to be paranoid now. – Naumann 27/1, 2011 at 16:8

@PaulBetts Your blog post on this issue claims that Windows 7 fixes this issue because you get a one-off popup from the Program Compatibility Assistant. That's a strange kind of "fix". More like a small band-aid. Surely a real "fix" would allow you to start debugging these Exceptions again, as normal. – Deliberative 6/12, 2014 at 14:20

@Deliberative The one-off popup only applies to apps that don't have a Win7 manifest. New development should always have a Win7 manifest, which means that you'll be able to debug these exceptions because you'll get the (desired) crash behavior – Snatchy 7/12, 2014 at 3:48

@PaulBetts Interesting. Except that I still can't get it to work. Using VS2013, having "Embed manifest with default settings" selected in a brand new Windows Forms application's properties, still ignores Exceptions thrown in Form1_Load. Adding app.manifest, uncommenting Win7 compatibility, and selecting that manifest in the properties, still ignores Exceptions thrown in Form1_Load. – Deliberative 7/12, 2014 at 12:13

L

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.

Leucoderma answered 19/9, 2008 at 16:17 Comment(1)

See my post according to which it is possible that it has to do with the "Enable Just My Code" setting itself, and as such it is possible that in the latter session this setting was somehow reverted – Broadsword 24/7, 2012 at 20:5

N

5

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

Naumann answered 4/12, 2010 at 17:13 Comment(5)

I promise, it wasn't out of malice! The alternatives were to make your machine run extra, super slow (save off the full register context constantly), or instacrash your app once an SEH exception occurs in a user-mode callback. The good news is, user-mode callbacks are solely(*) within window procedures, so this doesn't affect service apps, nor does it affect worker threads (i.e. any non-windowing thread) – Snatchy 14/1, 2011 at 8:24

@Paul - I truly would have preferred the "instacrash". At least I know to be paranoid now. – Naumann 27/1, 2011 at 16:8

@PaulBetts Your blog post on this issue claims that Windows 7 fixes this issue because you get a one-off popup from the Program Compatibility Assistant. That's a strange kind of "fix". More like a small band-aid. Surely a real "fix" would allow you to start debugging these Exceptions again, as normal. – Deliberative 6/12, 2014 at 14:20

@Deliberative The one-off popup only applies to apps that don't have a Win7 manifest. New development should always have a Win7 manifest, which means that you'll be able to debug these exceptions because you'll get the (desired) crash behavior – Snatchy 7/12, 2014 at 3:48

@PaulBetts Interesting. Except that I still can't get it to work. Using VS2013, having "Embed manifest with default settings" selected in a brand new Windows Forms application's properties, still ignores Exceptions thrown in Form1_Load. Adding app.manifest, uncommenting Win7 compatibility, and selecting that manifest in the properties, still ignores Exceptions thrown in Form1_Load. – Deliberative 7/12, 2014 at 12:13

E

2

Ctl-D, E brings up the Exceptions window. You can set what exceptions you want to, and don't want to, break on.

Expression answered 19/9, 2008 at 15:42 Comment(0)

D

0

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.

Discus answered 19/9, 2008 at 15:42 Comment(0)

G

0

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.

Gigolo answered 19/9, 2008 at 15:51 Comment(0)

B

0

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

Broadsword answered 24/7, 2012 at 20:3 Comment(0)

Recommended topics

Hot tags