I still haven't been able to determine what caused the original problem, but there's a short-term fix available for anyone also facing this issue.
After you build your project (by selecting Bulid » Build Solution or just clicking Start Debugging), you can attach the debugger to your instance of the ASP.NET Development Server.
Go to Debug » Attach to Process and scroll down until you see the process WebDev.WebServer.EXE. It will be labelled: ASP.NET Development Server - Port XXXX. It's usually the last or very near the last item in the list.
Select this process and click Attach. You'll then have all the usual debugging tools available and can step through code after throwing exceptions or hitting breakpoints.
This isn't a permanent fix! You'll have to go back through the same process every time you build or re-build your project. A pain, yes, but still a useful workaround.
Update - 10/5/10
I received an email yesterday from someone who was suffering from the same problem. We determined that it was an issue in
web.config that seems to have been added by VS. In both cases, significant portions of the
web.config file was enclosed in a
<location> block with the
inheritInChildApplications property set to "false."
Apparently, this is a setting used in .NET 4, but which is illegal in .NET 3.5 ... since VS 2008 can't build to .NET 4 in the first place, how these lines were added is a mystery.
<location path="." inheritInChildApplications="false"> and
</location> tags resulted in a working
web.config file, a complete build of the website, and an attached debugger. Finally, a full, permanent solution!