Visual Studio 2015 break on unhandled exceptions not working

Question

There's a new window called "Exception Settings" that appears in the lower right pane by default when you begin debugging. It has all of the options you would expect.

You can bring it up with CTRL+ALT+E

This allows you to cherry-pick which exceptions cause a break in the debugger.

The key, though, is that you can also set whether these exceptions always break, or only break when it's an unhandled exception -- but setting this is not very intuitive.

You will need to first check "Enable Just My Code" under Tools > Options > Debugging.

This then allows you to right-click the column header (Break When Thrown) in the new Exceptions Settings window, and add the "Additional Actions" column, which then allows you to set each exception as "Continue when unhandled in user code".

So just right-click an exception or an entire group and disable the "Continue when unhandled in user code" flag. Unfortunately, the "Additional Actions" column will show up empty which is the same as "Break when unhandled in user code".

More on this here:

http://blogs.msdn.com/b/visualstudioalm/archive/2015/02/23/the-new-exception-settings-window-in-visual-studio-2015.aspx

I had the same issue and I managed to solve this by doing this -

1. Press Ctrl + Alt + e to bring up the Exception Settings window.
2. Tick Common Language Runtime Exceptions.

That's it!

I was inspired this post since I am using a x64 version of Windows.

For googler that wants to break only when the exception concerns their code, there is an option in Visual Studio 2015: Options->Debugging->General->Just My Code. Once checked, it allow to do not break when the exception is managed (thrown and catched) outside your code.

Microsoft have subtly changed the logic in the new exceptions window.

See http://blogs.msdn.com/b/visualstudioalm/archive/2015/02/23/the-new-exception-settings-window-in-visual-studio-2015.aspx

The key part being:

Important Notes

• This new window contains all of the same functionality as the old modal dialog. No capabilities of the debugger have changed only the way you can access them
• The debugger will always break when an exception is unhandled
• The setting to change if the debugger breaks on user-unhandled exceptions has moved under a context menu
• The menu location has moved to Debug -> Windows -> Exception Settings

However, if like me you have a Global Unhandled Exception Handler in your code then the second item on that list is key: For me, no exceptions will therefore be truly unhandled, which seems to be different from VS2013.

To get back the behaviour where VS breaks on unhandled exceptions, I had to tick all of the exception types I wanted to break on and then secondly ensure that the "Additional Options" (you may need to make this column visible*) for "Continue when unhandled in user code" was NOT set. The VS2015 logic does not seem to consider my Global Unhandled Exception Handler to be "handled in user code", so it does break on these; it doesn't break on caught exceptions though. This makes it work like VS2013 did.

*How to enable the "Additional Actions" column

If I'm correctly reading between the lines here, the issue is that your exception is effectively 'disappearing' even though the default debugger behavior should break on unhandled exceptions.

If you have asynchronous methods, you may be running into this issue because exceptions not caught on a thread pool thread as part of a Task continuation are not considered unhandled exceptions. Rather, they are swallowed and stored with the Task.

For example, take a look at this code:

class Program
{
    static void Main(string[] args)
    {
        Test();
        Console.ReadLine();
    }

    private async static Task Test()
    {
        await Task.Delay(100);
        throw new Exception("Exception!");
    }
}

If you run this program with the default debugger settings (stop on unhandled exceptions only), the debugger will not break. This is because the thread pool thread allocated to the continuation swallows the exception (passing it to the Task instance) and releases itself back to the pool.

Note that, in this case, the real issue is that the Task returned by Test() is never checked. If you have similar types of 'fire-and-forget' logic in your code, then you won't see the exceptions at the time they are thrown (even if they are 'unhandled' inside the method); the exception only shows up when you observe the Task by awaiting it, checking its Result or explicitly looking at its Exception.

This is just a guess, but I think it's likely you're observing something like this.