15

In Visual Studio 2008 while debugging an ASP.Net website I set a breakpoint in the codebehind page. I refresh the page or submit to call the method, the breakpoint is hit. Then I delete the breakpoint and continue execution. I make a change to the codebehind page and save it. I submit or refresh again and the deleted breakpoint is back! It is hit again, and I delete it again. I have tried delete, disable, nothing works it keeps coming back if I make a change to the page. It is extremely annoying and unproductive. The only way I have found to make the breakpoint permanently go away is to use the Debug menu Delete all breakpoints item, which is obviously less than ideal. I have been able to reproduce this on other developers machines also. What is going on here? Is this by design? Is it a bug in VS? How do I keep these zombie breakpoints from resurrecting?

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
Tion
  • 1,470
  • 17
  • 27
  • 1
    possible duplicate of [Question on how to remove a Visual Studio Breakpoint](http://stackoverflow.com/questions/2569631/question-on-how-to-remove-a-visual-studio-breakpoint) – womp Jun 30 '10 at 19:53

5 Answers5

3

It's probably a bug. Either use Delete All Breakpoints (Shift+F9) or try deleting the breakpoint in stopped (not Run) mode.

František Žiačik
  • 7,511
  • 1
  • 34
  • 59
  • 2
    It's not a bug, it's likely a multi-bound breakpoint. See http://connect.microsoft.com/VisualStudio/feedback/details/391642/permanently-remove-a-breakpoint-in-visual-studio-during-debugging – womp Jun 30 '10 at 19:55
2

It's because its child breakpoints persist: MSDN article.

Your options are:
- Stop your debug session, then remove the breakpoint by clicking its red glyph.
- Find the breakpoint in the Breakpoint Window list and delete it from there.
- Use a macro to clean up child breakpoints between debug sessions, then remove by clicking the glyph.[1] (Quirky, but feels good when it works.)
- Use a macro to delete a breakpoint on the currently selected line.[2]

Community
  • 1
  • 1
Protector one
  • 6,926
  • 5
  • 62
  • 86
2

It's as @sgiffinusa's link describes: it's the difference between a pending and a bound breakpoint. Before the debugger is attached, it's a pending breakpoing, once the debugger is attached, it may have more than one piece of generated code accessing it, and the debugger binds a breakpoint to each path into that code. I don't get it...but that's what seems to happen. :)

One work around that seems to work for me is to, instead of toggling the breakpoint with the mouse by clicking the margin, use the F9 key (or whatever you have it mapped to,) to toggle the breakpoint off, and then press F9 again to toggle it back on, and then F9 once more to be rid of the dang thing forever.

I've no idea why that works, but it does in this office.

Yoopergeek
  • 5,592
  • 3
  • 24
  • 29
1

I've had this problem too. If you stop debugging (click stop) before you delete the breakpoint, it should go away permanently.

Mike Comstock
  • 6,640
  • 10
  • 36
  • 41
1

I think this is by design.

Remove a breakpoint in debug mode and it's temporary. Remove a breakpoint in design mode and its permanent.

Jeroen
  • 4,023
  • 2
  • 24
  • 40