{"id":123,"date":"2015-01-07T19:24:00","date_gmt":"2015-01-07T19:24:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/visualstudioalm\/2015\/01\/07\/understanding-exceptions-while-debugging-with-visual-studio\/"},"modified":"2022-05-25T04:52:10","modified_gmt":"2022-05-25T12:52:10","slug":"understanding-exceptions-while-debugging-with-visual-studio","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/devops\/understanding-exceptions-while-debugging-with-visual-studio\/","title":{"rendered":"Understanding Exceptions while debugging with Visual Studio"},"content":{"rendered":"<p><em>This post has been updated to reflect *<a href=\"http:\/\/blogs.msdn.com\/b\/visualstudioalm\/archive\/2015\/02\/16\/the-new-exception-settings-window-in-visual-studio-2015.aspx\"><em>the experience while using Visual Studio 2015<\/em><\/a><\/em>.* If you have spent any time coding, odds are that you have had to deal with <a href=\"http:\/\/msdn.microsoft.com\/en-us\/library\/x85tt0dd.aspx\">Exception Handling<\/a>. In Visual Studio, when exceptions are thrown or end up unhandled, the debugger can help you debug these by breaking just like it breaks when a breakpoint is hit. In this blog post we will look at the different classifications of exceptions and how to configure when the debugger will break for those exceptions.<\/p>\n<h2>Classifications of Exceptions We will start by looking at the classification types of exceptions in the debugger. The debugger classifies exceptions in the following ways:<\/h2>\n<ul>\n<li>**First Chance Exceptions: **When an exception is first thrown in the application, this is classified as a \u201cfirst chance\u201d exception. At this point the debugger does not know if the exception will be caught (handled) by the application. All exceptions start as first chance exceptions. \n<ul>\n<li>The debugger gets notified every time an exception is thrown. You can see these notifications in the Output window and in <a href=\"http:\/\/blogs.msdn.com\/b\/visualstudioalm\/archive\/2013\/04\/22\/learn-intellitrace.aspx\">IntelliTrace<\/a>.<\/li>\n<li>You can tell the debugger what first chance exceptions to break for, just like enabling a breakpoint.<\/li>\n<li>Once broken due to a first chance exception, you can continue debugging by stepping or pressing Continue. When you continue, your code has the opportunity to handle this exception, if it doesn\u2019t then the exception now falls under one of the classifications listed below.<\/li>\n<\/ul>\n<\/li>\n<li>\u00a0**<a name=\"user-unhandled\"><\/a>User-unhandled Exceptions: **When a first chance exception is not caught (handled) in user code and is caught in <a href=\"http:\/\/msdn.microsoft.com\/en-us\/library\/a3694ts5.aspx\">\u201cExternal Code\u201d on the call stack<\/a>, this is classified as a \u201cuser-unhandled\u201d exception. This classification is only applicable when debugging Managed or JavaScript applications with <a href=\"http:\/\/msdn.microsoft.com\/en-us\/library\/dn457346.aspx\">Just My Code<\/a>enabled. \n<ul>\n<li>By default, the debugger will break for all user-unhandled exceptions.<\/li>\n<li>Once broken due to a user-unhandled exception, you can continue debugging by stepping or pressing Continue. The exception may be handled somewhere in <a href=\"http:\/\/msdn.microsoft.com\/en-us\/library\/vstudio\/h5e30exc(v=vs.100).aspx\">\u201cExternal Code\u201d<\/a> on the call stack, and if it isn\u2019t, then it becomes an unhandled exception.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><img decoding=\"async\" style=\"float: none; padding-top: 0px; padding-left: 0px; margin-left: auto; padding-right: 0px; margin-right: auto; border-width: 0px;\" title=\"ExternalCode\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2015\/01\/2185.ExternalCode_thumb_2038CC8A.png\" alt=\"ExternalCode\" width=\"547\" height=\"133\" border=\"0\" \/> <\/p>\n<li style=\"list-style-type: none;\">\n<ul>\n<li>\n      You can change the default, but in most cases you will likely not need to change this setting. Most frameworks, like ASP.NET, implement global exception handlers so that your application will not crash, but the exception has not really been dealt with properly. The debugger provides breaking for user-unhandled exceptions to notify you in these cases.\n    <\/li>\n<\/ul>\n<\/li>\n<ul>\n<li>**<a name=\"unhandled\"><\/a>Unhandled Exceptions: **When a first chance exception is not caught (handled) by the application and reaches the <a href=\"http:\/\/msdn.microsoft.com\/en-us\/library\/system.appdomain.unhandledexception(v=vs.110).aspx\">system default handler<\/a>, this is classified as an \u201cunhandled\u201d exception. \n<ul>\n<li>An unhandled exception will crash the application.<\/li>\n<li>The debugger will break for all unhandled exceptions so that you get a chance to examine the state of your application that lead to the crash.<\/li>\n<li>Once broken due to a completely unhandled exception, you cannot continue debugging.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h2><a name=\"break-when-thrown\"><\/a>Configuring the debugger to break for first chance exceptions To change when the debugger breaks, go to Debug->Windows->Exception Settings<\/h2>\n<p align=\"center\">\n  <a href=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2015\/01\/0121.ToolWindow2.png\"><img decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2015\/01\/0121.ToolWindow2.png\" alt=\"\" border=\"0\" \/><\/a>\n<\/p>\n<p>When you first open this window you will see that there is a tree grid with one column and checkboxes.<\/p>\n<ul>\n<li><strong>Break when Thrown<\/strong>. This includes a default list of exceptions known by the debugger, grouped by category. Note: The possible exceptions that could break from this list is determined by the runtime you are debugging. For example, if you are using managed-only debugging then the debugger will never break for C++, Win32 Exceptions, etc. even if they are configured to break when thrown<a><span style=\"color: #000000;\">.<\/span><\/a><\/li>\n<li><strong>Checkboxes<\/strong>. If you check the box for a category, then the debugger will break for all First Chance Exceptions while debugging. If you don\u2019t want to enable all First Chance Exceptions, you can find the specific exception types that you wish to configure by using the search box. Using the context menu, you can show the Additional Actions column and also configure the behavior for user-unhandled exceptions. <\/li>\n<\/ul>\n<p><img decoding=\"async\" style=\"margin-right: auto; margin-left: auto;\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2015\/01\/6431.ContextMenu2.png\" alt=\"\" border=\"0\" \/> \n*   <strong>Additional Actions<\/strong>. This column is only available if Just My Code is enabled. User-unhandled exceptions only make sense for Common Language Runtime Exceptions and JavaScript Runtime Exceptions, the option to configure this for other runtimes is not available because the debugger does not make distinctions between user code and External Code. As per my earlier comments, you typically do not want to turn this off. If you do wish to turn this off, you can do so by selecting \u201cContinue when unhandled in user code\u201d from the context menu. This list is not an exhaustive master list of every possible exception. You can use Add and Remove to manage exceptions in this default list. This configuration is saved with your solution. You can also use search to locate all of the exceptions with specific keywords, e.g. \u201cnull\u201d. Lastly you can use Reset All to restore the list to its default state.<\/p>\n<h2><a name=\"example\"><\/a>Example For this example we are using a simple WPF app that is supposed to draw a shape in the window when the user clicks a button. This app has been implemented to display \u201cFailure\u201d text in the view when something goes wrong and \u201cSuccess\u201d when everything has gone right. You can follow along with the<\/h2>\n<p><a href=\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/6\/2019\/02\/WpfShapes.zip\">code attached to this post<\/a>. Let\u2019s pretend I was given this app to test out and make sure everything was working. \n*   I start debugging (F5) to run the app.\n*   Click on \u201cDraw Half Octagon\u201d.\n*   Observe Failure Message.<\/p>\n<p align=\"center\">\n  <a href=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2015\/01\/4743.AppFailure_thumb_04D11827.png\"><img decoding=\"async\" style=\"padding-top: 0px; padding-left: 0px; padding-right: 0px; border-width: 0px;\" title=\"AppFailure\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2015\/01\/4743.AppFailure_thumb_04D11827.png\" alt=\"AppFailure\" width=\"294\" height=\"211\" border=\"0\" \/><\/a>\n<\/p>\n<p>The app did not crash and the debugger did not break, but I am seeing the app\u2019s failure message and no half octagon shape, so what happened? I could start by going to the Output window or IntelliTrace to investigate. Let me start with the Output window and at the end of the post I\u2019ll diagnose the issue with IntelliTrace.<\/p>\n<p><em>TIP: the output window and IntelliTrace are great places to start when you think something has gone wrong.<\/em> \u00a0 <em><img decoding=\"async\" style=\"float: none; padding-top: 0px; padding-left: 0px; margin-left: auto; padding-right: 0px; margin-right: auto; border-width: 0px;\" title=\"Output\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2015\/01\/6646.Output_thumb_6D68C615.png\" alt=\"Output\" width=\"564\" height=\"190\" border=\"0\" \/><\/em> In the output window, I see that \u201cA first chance exception of type \u2018System.NullReferenceException\u2019 occurred\u2026\u201d If I press \u201cDraw Half Octagon\u201d again I do not see any more first chance exceptions occurring, so I conclude that this exception occurred on the startup path. But where exactly did it occur? \n*   I could use code inspection to try to hunt down the issue, or step through the initialization logic.\n*   Instead I will open the Exception Settings (Ctrl+Alt+E), and configure the debugger to break for the first chance System.NullReference Exception. I use the search box to find the \u201cSystem.NullReferenceException\u201d.<\/p>\n<p><img decoding=\"async\" style=\"margin-right: auto; margin-left: auto;\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2015\/01\/2816.SearchNull.png\" alt=\"\" border=\"0\" \/> I check the box to break when this exception type is thrown. <em>TIP: From the search box, you can press the down arrow to select items in the list and then use the space bar to toggle the checkbox state.<\/em> After I restart debugging, the debugger breaks when the exception was thrown and I can quickly verify that the exception was \u201chandled\u201d by an empty catch block and not really dealt with, which is what lead to the \u201cFailure\u201d message in my application. <em>TIP: The *<a href=\"http:\/\/msdn.microsoft.com\/en-us\/library\/2ww37f14.aspx\"><em>Exception Assistant<\/em><\/a><\/em> can provide you with useful information if you are unfamiliar with a particular type of exception. Notice that I can also configure my exception setting from here by using the \u201cbreak when this exception type is thrown\u201d checkbox.* <img decoding=\"async\" style=\"float: none; padding-top: 0px; padding-left: 0px; margin-left: auto; padding-right: 0px; margin-right: auto; border-width: 0px;\" title=\"ExceptionAssistant\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2015\/01\/6242.ExceptionAssistant_thumb_5DC8BB04.png\" alt=\"ExceptionAssistant\" width=\"528\" height=\"217\" border=\"0\" \/> Since I am broken on this first chance exception, I can go to the Locals window where I can see that the value of \u201cm_halfOctagon\u201d is null. Looking at the code, I see that the variable was never initialized. <img decoding=\"async\" style=\"float: none; padding-top: 0px; padding-left: 0px; margin-left: auto; padding-right: 0px; margin-right: auto; border-width: 0px;\" title=\"Locals\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2015\/01\/6712.Locals_thumb_49804319.png\" alt=\"Locals\" width=\"539\" height=\"100\" border=\"0\" \/> I add one line of code to initialize the variable. <img decoding=\"async\" style=\"float: none; padding-top: 0px; padding-left: 0px; margin-left: auto; padding-right: 0px; margin-right: auto; border-width: 0px;\" title=\"Code\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2015\/01\/4276.Code_thumb_1473B3E9.png\" alt=\"Code\" width=\"387\" height=\"104\" border=\"0\" \/> Then I restart debugging and observe that my application is working successfully.<\/p>\n<p align=\"center\">\n  <a href=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2015\/01\/7823.Success_thumb_3B41CA29.png\"><img decoding=\"async\" style=\"padding-top: 0px; padding-left: 0px; padding-right: 0px; border-width: 0px;\" title=\"Success\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2015\/01\/7823.Success_thumb_3B41CA29.png\" alt=\"Success\" width=\"320\" height=\"230\" border=\"0\" \/><\/a>\n<\/p>\n<h2 align=\"left\">\n  Using IntelliTrace to Diagnose the Same Issue\n<\/h2>\n<p>The experience described above works for all languages and for all editions\/SKUs of Visual Studio. However there are applications which throw exceptions very often and they don\u2019t necessarily represent failure. In those cases it\u2019s much more efficient to use IntelliTrace to diagnose the issue. IntelliTrace is available when using Visual Studio Ultimate edition and also using .NET. Now let me show you how I would use IntelliTrace to find this problem. Let\u2019s pick up from the first time I observe the \u201cFailure\u201d message in the UI. Instead of opening the Output window and looking for first chance exceptions there, I can hit the \u201cBreak All\u201d button on the toolbar (the \u201cpause\u201d icon) and then look at the Diagnostic Tools window to view my debugging history<\/p>\n<p align=\"center\">\n  <a href=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2015\/01\/6735.Pause_thumb_620FE069.png\"><img decoding=\"async\" style=\"padding-top: 0px; padding-left: 0px; padding-right: 0px; border-width: 0px;\" title=\"Pause\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2015\/01\/6735.Pause_thumb_620FE069.png\" alt=\"Pause\" width=\"255\" height=\"93\" border=\"0\" \/><\/a>\n<\/p>\n<p align=\"center\">\n  <a href=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2015\/01\/8030.DiagTools.png\"><img decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2015\/01\/8030.DiagTools.png\" alt=\"\" border=\"0\" \/><\/a>\n<\/p>\n<p>By looking at the IntelliTrace event list, I can see that as soon as my application starts an exception is swallowed. I\u2019m going to start there. Now I select the \u201cThrown:\u201d event and Activate Historical Debugging.<\/p>\n<p align=\"center\">\n  <a href=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2015\/01\/3157.Debugging.png\"><img decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2015\/01\/3157.Debugging.png\" alt=\"\" border=\"0\" \/><\/a>\n<\/p>\n<p>Historical Debugging takes me to the line of code that threw the exception. I have again found the null reference that caused my application to fail, just like before, but this time because I used IntelliTrace I did not have to repro the issue, restart debugging, or configure the exception to break when thrown!<\/p>\n<h2>Your Feedback on Setting Exceptions Please visit<\/h2>\n<p><a href=\"http:\/\/visualstudio.uservoice.com\/forums\/121579-visual-studio\">User Voice<\/a> and vote on what you think needs to be improved about this experience, or create your own suggestion and get others to vote for it. If you run into issues, or have any other feedback you\u2019d like to share, please let me know in the comments below, through <a href=\"http:\/\/msdn.microsoft.com\/en-us\/library\/zzszcehe.aspx\">Visual Studio\u2019s Send a Smile feature<\/a>, or in our <a href=\"http:\/\/social.msdn.microsoft.com\/Forums\/en-US\/vsdebug\/threads\">MSDN forum<\/a>. <a href=\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/6\/2019\/02\/WpfShapes.zip\">WpfShapes.zip<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>This post has been updated to reflect *the experience while using Visual Studio 2015.* If you have spent any time coding, odds are that you have had to deal with Exception Handling. In Visual Studio, when exceptions are thrown or end up unhandled, the debugger can help you debug these by breaking just like it [&hellip;]<\/p>\n","protected":false},"author":181,"featured_media":45953,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1,225],"tags":[],"class_list":["post-123","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops","category-git"],"acf":[],"blog_post_summary":"<p>This post has been updated to reflect *the experience while using Visual Studio 2015.* If you have spent any time coding, odds are that you have had to deal with Exception Handling. In Visual Studio, when exceptions are thrown or end up unhandled, the debugger can help you debug these by breaking just like it [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/posts\/123","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/users\/181"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/comments?post=123"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/posts\/123\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/media\/45953"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/media?parent=123"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/categories?post=123"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/tags?post=123"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}