59

When I debug a C# program and I get an exception throwed (either thrown by code OR thrown by the framework), the IDE stops and get me to the corresponding line in my code.

Everything is fine for now.

I then press "F5" to continue. From this moment, it seams like I'm in an infinite loop. The IDE always get me back to the exception line. I have to Shift + F5 (stop debugging/terminate the program) to get out of his.

I talked with some co-workers here and they told me that this happens sometime to them too.

What's happening?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
vIceBerg
  • 4,197
  • 5
  • 40
  • 53

7 Answers7

49

You probably have the option "Unwind the callstack on unhandled exceptions" checked in Visual Studio. When this option is on Visual Studio will unwind to right before the exception, so hitting F5 will keep ramming into the same exception.

If you uncheck the option Visual Studio will break at the exception, but hitting F5 will proceed past that line.

This option is under menu Tools → Options → Debugging → General.

Update: According to Microsoft, this option was removed from Visual Studio in VS2017, and maybe earlier.

StayOnTarget
  • 11,743
  • 10
  • 52
  • 81
Matt Woodard
  • 1,956
  • 1
  • 16
  • 13
  • Excellent point! Note that you can change the values of the problematic exception causing variables, either via the Immediate Window or simply through the variable watches and hence get your program to keep on chugging – information_interchange May 03 '18 at 15:44
  • 11
    Any idea what this option is now called, or where it's located, in VS 2017? – HardCode Oct 24 '19 at 14:22
  • 2
    It seems it was removed a while ago https://github.com/MicrosoftDocs/visualstudio-docs/issues/305 – mnaoumov Jun 20 '21 at 06:37
  • 1
    Is there a solution to this? I'm debugging an ASP.net website and I want the exception to "bubble up" to IIS instead of forcing me to stop debugging, re-attach, and try again. – Tomas Beblar May 16 '23 at 18:38
20

This is because the exception is un-handled and Visual Studio can not move past that line without it being handled in some manner. Simply put, it is by design.

One thing that you can do is drag and drop the execution point (yellow line/arrow) to a previous point in your code and modify the in memory values (using the Visual Studio watch windows) so that they do not cause an exception. Then start stepping through the code again1.

It is a better idea though to stop execution and fix the problem that is causing the exception, or properly handle the exception if the throw is not desired.

1 This can have unintended consequences since you are essentially re-executing some code (not rewinding the execution).

Palec
  • 12,743
  • 8
  • 69
  • 138
Eric Schoonover
  • 47,184
  • 49
  • 157
  • 202
  • 5
    i do not get the yellow line, instead it shows the green line with a green arrow where the exception occured, and i can't move the green arrow to anywhere. What do i do in that case? – Anirudh Goel Jun 01 '11 at 04:15
  • @Anirudh Goel, same problem here. – Pedro77 Jun 03 '13 at 18:52
  • 5
    This seems odd... sometimes we want to see what happens when an un-handled exception is hit – Don Cheadle Jan 17 '17 at 19:31
  • 1
    Wow, did not know that you could just drag the yellow arrow around! – information_interchange May 03 '18 at 15:40
  • 4
    This is not true. It is supposed to go to the yellow screen of death when you continue. It has worked that way for me since the earliest version of Visual Studio I remember. However, it is now doing the infinite loop for me in VS2022, and I don't know why. Does anyone know what changed? – SpeedRacer350 Nov 07 '22 at 17:48
  • 1
    Yeah, earlier when pressing f5/continue it was just crashing, now you have to exit debug to continue, which is wildly annoying – Contra Mar 10 '23 at 12:52
  • You just got to love Visual Studio's developers breaking more and more of the age old debugging experience with each new update. The fact that you have to explicitly break on exceptions in order to be able to view the values of method parameters and locals when they occur is another debugging annoyance that they introduced for no reason – Tom Lint Jul 28 '23 at 10:27
7

Some said that is by design, but it was never been before. You were able to F5 again and the code would continue until the end or next exception catch.

It was an useful behavior that worked well, and as developers, I think we should not reach artificial barriers while we are debugging and investigating issues in an application.

That said, I found a workaround to this (sort of):

  • press Ctr+Shift+E (Exception settings)
  • uncheck the "Common Language Runtime Exceptions" box
  • press F10 to continue only the exception you are stuck
  • check "Common Language Runtime Exceptions" again, if you want the breaks to happen again

That seems dirty, too much work for a thing that is used to be simpler, but I guess that is what we have for today.

Cesar
  • 420
  • 6
  • 12
  • yep, it was perfect the way it was. just f5 to make it crash. now i have to exit debugging, or use the workaround you mentioned – Contra Mar 10 '23 at 12:53
5

When the IDE breaks on the offending line of code, it stops just before executing the line that generated the exception. If you continue, it will just execute that line again, and get the exception again.

If you want to move past the error to see what would have happened, had the error not occurred, you can drag the yellow-highlighted line (the line that will execute next) down to the next line of code after the offending one. Of course, depending on what the offending line failed to do, your program may now be in a state that causes other errors, in which case you haven't really helped yourself much, and probably should fix your code so that the exception either doesn't occur, or is handled properly.

Joel Mueller
  • 28,324
  • 9
  • 63
  • 88
3

Once you get an exception Visual Studio (or whatever IDE you might be using) will not let you go any further unless the exception is handled in your code.

This behaviour is by design.

Peter Hession
  • 501
  • 5
  • 9
2

An uncaught exception will bring down your app. Instead of this, VS will just keep you at the uncaught exception, You will have to terminate or backwind your app.

Mark Brackett
  • 84,552
  • 17
  • 108
  • 152
0

In an ASP.NET application, as a workaround, you could call Response.End() from the Immediate Window, and then continue the debug session. You won't get served the error page in the browser like before, but at least now you can try another request without having to restart the debug session.

I really have no idea when and why Microsoft changed this behavior. Would love to know if there is a setting or something to revert back to the old default behavior.

Protector one
  • 6,926
  • 5
  • 62
  • 86