Debugging with IE8
I recently upgraded to Internet Explorer 8 because I was having an issue with a collection of sites that I visit regularly (typically opening them in a tab group). There is something renegade that frequently caused IE7 to crash if I too-quickly closed a tab and tried to scroll or quickly close another tab...it was annoying, but not enough for me to truly troubleshoot and pinpoint the culprit. This didn't happen all the time, but when it did, usually that group was involved. Well, I thought maybe it was just something screwy with my dev machine, and maybe the IE8 upgrade would fix it. And it did...for a while.
You see, IE8 installs with the default action of spanning new processes for new tabs (there is some formula where it's not exactly 1-for-1, but for the first few it looks that way). Well, this apparently handled my issue such that when whichever site or sites it was that were trouble, when I closed them, the process responsible for them might crash, but it wouldn't crash the whole of Internet Explorer (and my remaining tabs). Now, I'm not here to promote Internet Explorer, but it is our company standard, so I use it because I have to develop to it. And I know someone reading this will go off about Google Chrome or whatever other favorite tabbed browser they love and how it is far superior to IE. Fine, I'm not interested. You see, I'm not zealous about my browser, and I don't care too much, as long as it let's me do what I want to do. But I'm getting off-track. I just wanted to say, "hey, I upgraded to IE8 recently".
But the point of this post is that when I upgraded to IE8 on my development machine, I ran into a very serious problem. A problem big enough that I started asking myself if I would be able to uninstall it and get back to IE7, even though the tab crashing thing was really annoying. The problem I ran into was that Visual Studio 2005 would no longer stop on any Breakpoints in my ASP.NET application. When you're in the middle of a big development effort, that's a very bad problem to have.
Fortunately, with a quick search of the Internet, I found out what the problem was. That crash-proofing feature I espoused just paragraphs ago was causing problems with the debugger. In essence, the Visual Studio 2005 debugger couldn't figure out which process to attach to. See http://weblogs.asp.net/abdullaabdelhaq/archive/2009/06/01/VS-Debug-Problem-with-IE8.aspx for another explanation. And also https://blogs.msdn.com/askie/archive/2009/03/09/opening-a-new-tab-may-launch-a-new-process-with-internet-explorer-8-0.aspx for even more details.
So, I did just as it recommended and added the registry key to tell IE to stop spawning separate processes, and PRESTO! the debugger was working again and recognizing my breakpoints. Hooray! (Unfortunately, that tab-crashing behavior came back with it. I'm not going to identify the sites in that group because I don't want to throw a bunch of innocent sites under the bus along with the guilty party. And I'm still not convinced it isn't something screwy about my own setup.)
So I'm doing my part to spread the word for developers in case you run into this problem yourself. There are notes in one of those links I provided that suggest this may not be a problem for "newer development environments" whatever that means (Visual Studio 2008? The one after that?) and I'd love to upgrade to VS 2008, but that sort of change comes with its own set of baggage and you don't just jump into something like that with a project like this, without a little planning. I'll get to that later. In the meantime, I'm back in business, and if you have the same problem, now you know how to get unstuck, too.