The New Exception Settings Window in Visual Studio 2015
February 23, 2015
In Visual Studio 2015 we’re pleased to introduce the new Exception Settings tool window for configuring the debugger’s exception settings. In this post I will walk you through the features of this new window. For more information on exception classifications in Visual Studio, see Understanding Exceptions while Debugging with Visual Studio.
Now in a Tool Window
In previous versions of Visual Studio, when you wanted to configure exception settings you would have to go to the modal, slow-opening, hard-to-search Exceptions Dialog. We heard all of your feedback, so we built an improved Exception Settings window.
We have taken all of the useful functionality of that old dialog and put it into this convenient and easy to use tool window.
To access this window go to the Debug menu and select Windows -> Exception Settings.
Enabling Exceptions to Break When Thrown
The Exception Settings window contains a list of the default exceptions provided by Visual Studio. These exceptions are grouped into categories that correspond to the different debug engines you might use.
Checking a checkbox next to an exception means that you are instructing the debugger to break execution when that exception is thrown. When a box is unchecked or an exception is not in the list, the debugger will only break execution when that exception type is unhandled.
Using the Toolbar
From the new Exception Settings window you can filter the exceptions list to show you only enabled items, add exceptions to the list, remove exceptions from the list, and reset the list to its default configuration, and quickly search through the list to find what you are interested in. This is not a master list of every exception that could break your application, just a set of default exceptions we provide to get you started.
The following are the features offered to you by the toolbar as shown in the screenshot, from left-to-right:
- Filter – Show only checked exceptions. You can use this filter to see what exceptions you have enabled to Break when Thrown. If you have a set of exceptions that you need to temporarily disable, this filter provides an easy way to do that.
- Add to list. You can add exceptions to the list that you would like to configure to break when thrown. This is especially useful if you are using custom exception types in your code. Click on the category in which you would like to add an exception, and then click the “Add” button. An editor will open in the window underneath the category. Type in your exception and then hit enter to save your new exception to the list. Pressing Esc or hitting the remove button will cancel adding the new exception to the list. Exceptions you add to the list will be persisted with the solution.
- Remove from list. You can remove individual exception types or entire categories from the list. For example, if you are managed debugging and uninterested in native exception types, you can remove the “C++ Exceptions” category so that it is not cluttering your view. Removed exceptions are treated as being unchecked and will break when unhandled. Exceptions removed from the list will not currently be persisted when you close and reopen the solution. We plan to enable this is a future release by allowing exceptions you remove from the list to be persisted with the solution.
- Reset to default list. You can use this button to return the state of your list to the default configuration. Removed exceptions will be added back, and added exceptions will be removed. The state of all the checkboxes will also be reset to default values.
- Search. You can use this as a convenient and quick way to find the exception type you want to configure in the list. Search works as a filter that will scope your list to all items matching your search term. For example searching the term “null” will show you all exceptions containing “null” so you no longer have to scroll through the entire list to find the exception you are looking for.
Using the Context Menu
You can also add, remove, and reset the list as described above by using the context menu. Additionally, you can enable certain exceptions to “Continue when unhandled in user code” by selecting this option from the context menu. (This is the same setting that was toggled from a second column of check boxes in the old modal dialog.) This option is currently only supported for debugging Managed or JavaScript applications with Just My Code enabled. You can view which exception types have this option enable by showing the Additional Actions Column under “Show Columns”. If you have Just My Code disabled you will not see these two context menu items because they do not apply.
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
Try It Out!
In this post I only described the new and improved UI experience for exception settings; to learn how to take advantage of this window to diagnose bugs in your code, please read my other blog post on Understanding Exceptions while Debugging with Visual Studio.
You can experience the new Exception Settings tool window right now by installing Visual Studio 2015 CTP6. If you run into issues or have any other feedback you’d like to share about this new window, please let us know in the comments below, through Visual Studio’s Send a Smile feature, or in our MSDN forum.


AWESOME!!! This looks like a great feature and one that will be used a bunch. Great work.
Thank you so much for replacing that horrific old dialog at long last. This definitely looks like an improvement.
A few comments:
I'd still very much like to have "exception profiles" that you can save and load. Depending on the application or the bug being tracked down, I frequently need to catch different sets of exceptions and manually recreating them each time is painful.
It's a weird UI decision having the "Continue when unhandled in user code" only be accessible via context menu. Seems like maybe there should be an additional column of checkboxes.
A very welcome and awesome improvement!
Most developers will probably think I'm pretty ridiculous for even noticing this (yes I am a textbook case of OCD) let alone mentioning it, but the UI label capitalization inconsistency hurts my eyes!
In grid headings: "Break when Thrown" + "Additional Actions" (yes "when" is a word that should be capitalized even in headings).
And in the context menu: "Add to list", "Remove from list" etc. alongside "Show Columns"
And in the grid: "Continue when Unhandled in user code" – why the capital U? In the context menu it's lower case.
Have the UI style guidelines around capitalization within MS changed recently, or are they just no longer enforced?
Great improvements, this will make things much better.
I'm not sure if this already exists and I've just never found it, but a keyboard shortcut to enable Break on CLR exceptions would be so useful to me.
It would be really awesome if you also add a quick way to toggle "just my code" to that window. It could be a button or checkbox in the toolbar of the new exceptions tool window.
@MichaelD!: Thanks! I look forward to hearing more feedback as you dogfood this new window
@MgSm88: Adding "exception profiles" is a great suggestion, I encourage you to vote for this item on UserVoice (visualstudio.uservoice.com/…/3352678 )
Thank for the feedback about "Continue when unhandled in user code". As a follow up question, is turning off breaking for user-unhandled exceptions something you do often?
@Daniel Stolt: Thanks for bringing these UI style capitalization elements to our attention. UI guidelines have not changed, but can easily get overlooked for pre-releases. These capitalization issues will be updated in the next release.
@Dave Shaw and @Mathias: Thanks for the suggestions we are always looking for feedback to improve your workflow. I would also recommend creating a suggestion on UserVoice visualstudio.uservoice.com as well.
Not very helpful as a bug report, but the old dialog also has the problem that sometimes the settings are lost, so you have to set it again. It could be caused by VS crashing, but I'm not sure.
@Lucian Bargaoanu: Thanks for the feedback. The exception settings in both the old dialog and new window are saved when the solution is closed. If VS crashes, the solution may not close properly and these settings can be lost. Also if you have configured exception settings and then open a new solution or another existing solution, the settings will change to represent how you previously configured them for that solution.
If you encounter a time when your settings are lost, and it isn't a result of one of the above situations, I encourage you to file a bug through the Send-A-Smile feature (msdn.microsoft.com/…/zzszcehe.aspx) so we can investigate.
I've been waiting for this feature for a long time. Only 1 question, is there a way to import/export configuration? It would be a very useful feature. Sometimes not very good developers do the next thing – surround potentially wrong code into try/catch block. For example, access to Dictionary by wrong key within try/catch instead of using TryGetValue method. In this case, when such code called dozen of times you are forced to uncheck specific kind of exception. But you can skip an exception you would like to Break while debugging, So if you reset Exception handling configuration to its default value – then you can get a lot of exceptions starting an application (especially if you are debugging not Just Your Own Code, but some Library or even .Net Source Code). So it take a time to configure exceptions you would like to skip and leave exceptions you would like to stop in debugger. In this case Export/Import configuration can be very useful.
As the person that designed and implemented the old Exceptions dialog, I welcome this change!
@xmetropol: Thanks for your great suggestion! There is currently not a way to import or export an exception settings configuration. I encourage you take a look at the following UserVoice items and vote for which of these suggestions would best help your scenario. Or if none of them do, I encourage you to create your own item and have the community vote for it. We often use UserVoice to help prioritize our feature requests.
Having "exception profiles" to switch between while debugging: (visualstudio.uservoice.com/…/3352678-provide-a-more-robust-exceptions-window-in-visual)
Saving and loading Exception Settings: (visualstudio.uservoice.com/…/6704391-save-and-load-set-of-selected-exceptions)
Adding conditions to filter out exceptions thrown in third party libraries: (visualstudio.uservoice.com/…/2486532-allow-the-debugger-to-stop-on-user-handled-and-thr)
@Adam Krantz: Glad you like it!
I just stumbled upon this feature while using CTP6 (I hadn't seen this blog post before then). This is the one single feature I've been asking to be added to Visual Studio for the past ten years. It's a tremendous quality of life improvement to no longer need to deal with the old slow modal dialog (often when I'm fighting against hard timeouts).
I'm sure there is more you can do with the feature to make it even better – but simply having this as a modeless panel now instead of a modal dialog is HUGE!
THANK YOU!!
@Keith Rome: Thank you so much for your enthusiasm about this feature! We are happy that it has eased a pain point for you. We are always looking for customer feedback and suggestions to continue to improve our features. Please feel free to use Visual Studio’s Send a Smile feature as an easy way to keep the feedback flowing.
This seems like a big improvement, thanks.
This is great, but I too would like to see "exception profiles" as a feature. I've been hanging out for that since VS 2008.
These all seem like nice tweaks, but the one feature I know a lot of us have been missing is to be able to ignore exceptions that occur in specific parts of the code. Very often you are interested in seeing all exceptions that occur, except the few exceptions that you know will always be thrown, in specific points of the code.
This could be an IoException, for deleting an existing file, which you don't care about, but you are also unable to do anything about. Having to disable all IoExceptions until you are past that point in the code and then having to re-enable that exception type again, is a constant annoyance.
@Yort – Thanks for the feedback. If you haven't already, please be sure to vote for this feature on UserVoice (visualstudio.uservoice.com/…/3352678-provide-a-more-robust-exceptions-window-in-visual) and also feel free to leave any additional comments there about what scenarios you would like to use "exception profiles" for.
@Mort – Thanks for the suggestion. We have definitely heard this from other customers as well. My question for you is, "What do you mean when you say 'specific parts of the code'? Would you want to disable exceptions thrown simply by a specific function, or is there some other characteristic to define it?"
Making it a floating window is an improvement but changing the content of that window appears to be an usability degradation.
The previous (modal) window allowed to select on how to break on exception: "Break when thrown" or "Break when unhandled"
The new dialog seems not to provide that important functionality. What I want is "Break when unhandled" but what I get is "Break when thrown". As a side note, "Break when unhandled" is my main use-case because I don't care about exceptions that are properly handled in code, I care about unhandled ones only. The question is: how to get "Break when unhandled"?
@ogggre -Thanks for your question. In Visual Studio, all exceptions that are truly unhandled will always break. There is not a setting to change this for any exception. This is the same way it behaved in VS 2013.
In the previous modal dialog, the second column of checkboxes was for the setting of "user-unhandled". User-Unhandled exceptions ultimately end up handled by some external code (non-user code), but are not handled in the user code before reaching that external code. You can read a more detailed explanation in this blog post (blogs.msdn.com/…/understanding-exceptions-while-debugging-with-visual-studio.aspx)
Sounds good, but now I can see the details when an exception was thrown, wonder while.
Please make it possible to search using acronyms.
For instance NRE should match 'NullReferenceException'.
@Kaycee Anderson
Re: "Thank for the feedback about "Continue when unhandled in user code". As a follow up question, is turning off breaking for user-unhandled exceptions something you do often?"
It's not only about how often but also about how easy. I had to google to find how to switch off because I would have never guessed there is a context menu. There's already a checkbox for thrown, I'm quite sure everyone would expect to find unhandled as a checkbox next to thrown instead of context menu.
@jbtibor – Thanks for your feedback. To clarify, the debugger will always break when an exception is unhandled. We do not currently provide an option to change this behavior. The option in the context menu only relates to the setting for user-unhandled exceptions. I have heard from others as well that the phrase "Continue when unhandled in user code" does not make this distinction clear. What is the scenario you have for when you wanted to turn off user-unhandled exceptions?
@Kaycee Anderson
To continue the discussion that @jbtibor started I have an application that I work on that has some old code that can throw exceptions onto a separate thread or cause thread abort which are unhandled. This ultimately kills the thread, but we also have an AppDomain UnhandledException event handler that we bind a handler to so we can log these exceptions for traceability when that happens.
This is our main reason to permit an unhandled exception to be thrown.
Although we do our best to unit test this event handler (via a proxy object), eventually you need to test it fully integrated at runtime and we all know how complicated application logic can get once all the parts are integrated together.
Currently we build the application and run it separately from the debugger, but that is not ideal. If that event handler ever throws an exception you would never know and the application would just terminate without any traceability.
"No capabilities of the debugger have changed only the way you can access them"
I wish that would be true. Unfortunately, VS2015 will now break execution even when asked to "break when thrown" and when the handled exception is thrown inside a DebuggerNonUserCode.
This makes "break when thrown" basically worthless except for extremely primitive example console applications.
@Jeremy — Thanks for continuing the discussion, and sorry for the delay. I am trying to better understand the scenario you described. What exactly would you like the debugger to do to help you for this situation?
@Imi– Thanks for helping to bring this issue to our attention. After looking closely at the code, we found that a bug was introduced that affects the DebuggerNonUserCode attribute. We are investigating possible solutions and hope to have this fixed soon in a future release.
[Update] We have provided a solution to the DebuggerNonUserCode issue reported by @Imi, details can be found in the following blog post https://blogs.msdn.microsoft.com/visualstudioalm/2016/02/12/using-the-debuggernonusercode-attribute-in-visual-studio-2015/
Why don't we get similar improvements on the C++ side.
I'd like to be able to add C++ type name (including template names since they're all the same in C++) and then be able to select whether or not the debugger will stop when that object is thrown.
Update: we found that we can get the C++ debugger to recognize user exceptions, but we must be careful how we spell the typename. Some spaces are a problem, some aren't. A *careful* cut-n-paste operation to grep just the typename (no extra spaces) in the exception dialog pop-up, then click on the "Open Exceptions Setting" link and add the selected text to the list. This does appear to work, even for template exception types.
@c++ guy — Thanks for the update.
How to see the inner exception message