Share via

C# VS2019 debugger quits after exception

Tony Upchurch 1 Reputation point
2021-02-05T17:33:34.197+00:00

I upgraded from VS2015 to VS2019 and now when I hit an exception and hit continue, debugging stops. In VS2015 it would try to execute the line again and if it was still a problem it would rethrow the exception. This is the desired behavior in my case because the exception sometimes occurs on a file lock or something and re-executing would allow the program to complete a lengthy process which otherwise would need to be completely re-ran. Regardless of the reason, how can I get the VS2015 behavior in VS2019? I have seen some mentions to unwind call stack in debug options, but I don't see it.

Visual Studio Debugging
Visual Studio Debugging
Visual Studio: A family of Microsoft suites of integrated development tools for building applications for Windows, the web and mobile devices.Debugging: The act or process of detecting, locating, and correcting logical or syntactical errors in a program or malfunctions in hardware. In hardware contexts, the term troubleshoot is the term more frequently used, especially if the problem is major.
967 questions

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Michael Taylor 51,346 Reputation points
    2021-02-05T18:14:11.937+00:00

    The debugger breaks on an exception (by default) based upon the rules of exception handling defined by the system. When an exception first occurs (first chance exception) then the debugger may or may not break in depending upon your exception settings. Most of the time we don't have that set because it would cause too many interruptions. If you resume from that exception (or you didn't configure it to stop) then the debugger continues and if the exception isn't handled you get the second chance (second chance exception). At this point your app is going to terminate and the debugger is giving you one last chance to look at the exception before your app goes away. If you resume from this your app terminates and the debugger will exit. The debugger settings have changed over the years but the overall behavior is the same. More importantly the debugger now allows you to adjust the behavior based upon the module it is coming from. For example you probably don't want to ignore exceptions in your code but you are fine not getting notified about handled exceptions in system code.

    The first question I have is whether the exception is a first chance or second chance exception. In other words do you have a try-catch around the code that is ultimately failing and therefore your app is trying to handle it. If that is the case then the debugger is currently configured to break on a thrown exception. In the exception settings that appears when this happens is an option to ignore throwing that exception completely or in the current module. If, however, you don't have a try-catch then this is a second chance and the debugger should always break. Your app is going away so running the debugger again will terminate it.

    Going back to your specific scenario it seems like your code should already have a try-catch around the call that may fail. The catch block will handle it so if you set a breakpoint inside there then when it catches the exception you can then drag the IP (the yellow arrow) back to the call that failed so it'll try to run it again.

    I should also point out that some debugger settings are new and may impact the behavior. This includes whether you have enabled the Just My Code option, whether the exception is occurring in a separate process and you have enabled the option to break across boundaries, etc.

    1 person found this answer helpful.