I was debugging an ASP.NET Web Application Project today and when I got to a breakpoint and then clicked the Stop Debugging tool button, it appeared to stop just fine, closing Internet Explorer and returning me to my editor. But what really happened was that the code had continued to run. I thought I had seen this behavior before, but this time I had conclusive proof because it updated 45 records in my database with data representing the bug which had led me to want to stop in the first place.
So what happened? I thought when I told the debugger to Stop, that it really would stop and not do any more work. But that’s not the case. After some searching around, I found this posting on Microsoft Connect that states that this is by design. At first, that sounded ridiculous and like a lame excuse, but if you read the details, it actually makes sense. And it points you to the solution which is to use the Terminate All action on the Debug menu rather than the Stop Debugging command.
Now, I’m not saying you should use Terminate All all the time, because in many situations, it doesn’t really matter if the page code is allowed to run its course before closing. But in situations, such as mine where I wanted to prevent it from running to completion and tweaking my test data, it is the perfect solution. I customized the debug toolbar to add this button right next to the Stop button so now it reminds me to decide which level of interruption I really want.
One side-note is that the Terminate All command will not only stop your code execution at that exact location, and close the browser window, it also terminates the Visual Studio Web Server, so there will be a little extra overhead the next time you start the debugger as it has to restart the web server. But that’s a small price to pay for the benefit of knowing your processing actually stopped where you wanted it to.
posted @ Wednesday, September 16, 2009 10:03 PM