What is debugattach.aspx and why can't the server find it?

Question

I\'m developing on an XP (SP3) machine with VS 2010 and IIS 5.

I have two versions of the same site. We\'ve released our first production version, so I forked the c

Answer 1

In my case I had created an Empty Web Application with VS2017 on Windows 10. When I unchecked the box for ASP.NET Debugger under Project Settings -> Web the problem went away. Before that I tried almost every suggestion out there to resolve the problem.

Answer 2

I just ran into this as well. I had turned off the Allow unlisted file name extensions setting under Request Filtering on my local IIS server (in order to match our security hardened settings in other environments). Turns out .aspx was being blocked. I turned the setting back on and could attach with the debugger. So I turned it back off, and added an allowance at the site level for .aspx and I can attach with the debugger once again.

I'm curious as well why the debugger is looking for debugattach.aspx, and failing with this error. Especially since my app is MVC and I don't need to serve .aspx.

Answer 3

If you're running VS2010 or later, and have installed .Net 4.x or later, try renaming the "v3.0" subdirectory (e.g. "rename C:\Windows\Microsoft.Net\Framework\v3.0 v3.0.ORIGINAL"), reboot your machine, and try debugging again in Visual Studio.

This has been working like a bloody charm for me, but your mileage may vary, depending on what kind of development you're doing.

I've been running Visual Studio 2012 for two weeks like this, and I seriously cannot believe how fast things are (again!). Launching the debugger with F5 is instantaneous now, and stopping the debug session is also instantaneous. All sorts of buggy and laggy behaviours have ceased, and so far I haven't seen a single side effect.

Answer 4

Add <compilation debug="true"> to your Web.config.

Answer 5

Based on this old posting, DebugAttach.aspx is implemented by the HTTP handler System.Web.HttpDebugHandler. I did not actually see this handler referenced anywhere in IIS7 though - it's possible that this implementation was merged into some other handler down the road. Definitely some sort of handler though. When it's working, you see 200 (success) messages in the logs.

I had this same problem 2 different ways, where F5 debugging failed in VS2010 because of a problem reaching the debug handler. Using the IIS Failed Request Tracing logs, I was able to see instances where IIS modules were interfering. In once case, UrlScan.dll was blocking the DEBUG verb. In another, a redirect from HTTP to HTTPS was causing the debug handler to return a 302. In both cases, VS barfed with a similar dialog.

At any rate, the trick here seems to be figuring out how a DEBUG request to this URL can be blocked.

Answer 6

I had a wildcard script map for the .NET 4 version of aspnet_isapi.dll that was causing this. I was able to change the script mapping to ignore the DEBUG verb (by only using the verbs I needed for my app) and that enabled VS to attach automatically.

Having said that, I ended up using either the VS development web server or IIS Express to get my site working on an XP machine, because IIS 5.1 didn't like the combo of the wildcard script map and ASP.NET routing.