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 code into a new directory tree, and set up new virtual directories in IIS to point to the new trees. The projects are set up to run in the IIS rather than VS's server. The main site is an MVC 2 based project.

My problem is that, when I hit F5 in Visual Studio 2010 to begin debugging the new version, I get a "Unable to start debugging on the Web Server. The web server could not find the requested resource." I spent the better part of yesterday trying to figure out what resource it was looking for that it couldn't find. This occurs before it ever gets to "Application Start". I finally thought of looking in the Web logs, and found that whenever I hit the F5 key, the web log shows a DEBUG request for /debugattach.aspx, with a return code of 404 (not found). If I run the same sequence on the old version, it shows the same thing, but first with a 401 code, and then the request repeated with a 200 code.

My first thought was that VS must be writing out a "debugattach.aspx" file, and then invoking it, and maybe it doesn't have write permission to the directory, but, as far as I can tell, it does.

I've googled debugattach.aspx, and the first several pages of articles that are returned all seem to refer to lockup's and timeouts, mostly on IIS 7 and VS 2005. Nothing that seems to apply to this situation.

Looking at what's different between the old version that works and the new version that doesn't, the only things are the IIS setup of the virtual directories, and the web.config on the code itself. But I've gone over the two sites side by side, and can't find any differences that account for this behavior.

Does anybody have a clue they can share with me? Or can anyone point me to any documentation on what exactly debugattach.aspx is/does, and what a DEBUG HTTP request does, and/or how VS uses them?

Thanks in advance.

Gregoire

Please disregard. I found the solution. I don't understand it, but I got it to work. I went back once again and compared the IIS properties of the two sites side by side, and discovered a difference. In the application extension mapping, where I had added aspnet_isapi.dll as a wild card mapping so that extensionless URL's would be run through the MVC mapping, the "Scripting Engine" check box was checked on the site that was not working, and not checked on the site that was. I removed that, and tried again, and debugging started. – Gregoire

though this is an old post, you can still get credit for posting your own answer =) – Romanist

Answer 1

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.

Romanist

Visual Studio will log errors relating to DebugAttach.aspx here: %UserProfile%\AppData\Local\Temp\Visual Studio Web Debugger.log (If you don't have that file -- or if it's an old file -- then your issue is probably not related to DebugAttach.aspx.) – Tannenwald

Answer 2

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.

Unloose

+1 ty sir. Fixed my issue that chewed up hours. My official error was Error: Unable to Start Debugging on the Web Server. The remote server returned an error: (403) Forbidden – Cardiovascular

Answer 3

For performance reasons we removed all the handlers from the <system.webServer> element of our MVC 5 project's web.config except for StaticFile and ExtensionlessUrlHandler-Integrated-4.0, and then started getting this error when debugging from Visual Studio.

After some investigation, we discovered that in normal use, whatever module that handles this request simply causes HTTP error 401 (unauthorized) to be returned. I was not able to find out exactly which module it was, but I was able to find the class that is responsible: System.Web.HttpDebugHandler.

Therefore, we added the following line into our web.config handlers:

<add name="DebugAttachHandler" path="DebugAttach.aspx" verb="DEBUG"
    type="System.Web.HttpDebugHandler" resourceType="Unspecified" requireAccess="Script"
    preCondition="integratedMode,runtimeVersionv4.0" responseBufferLimit="0" />

When that URL is hit, IIS gives out a 401 just as when all handlers are enabled, so Visual Studio is happy again.

See also: https://developercommunity.visualstudio.com/content/problem/464980/unable-to-start-debugging-a-web-project-when-vs-ge.html

Daliladalis

Answer 4

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.

Cristencristi

Answer 5

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.

Masaryk

Answer 6

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.

Rifkin

Answer 7

The solution that works for me was to restart VStudio in Run As Administrator Mode.

Balneology

Answer 8

I ran into this debugattach.aspx file issue just recently. For me, this started with a error message trying to debug an ASP.NET application through VS 2017. After spending two days following all of the suggestions out on the net, I finally stumbled on this debugattach.aspx thing. I, too, wanted to know what it was and why IIS was returning a 403-Forbidden response to requests for it.

Long story short, this happened to me because the application I wanted to debug happened to be in a virtual directory under another web application. I had to make sure the <compilation debug="true" flag was set on the 'parent' application, even though I wasn't interested in debugging that one.

A head-slapper in the end. Hopefully, this helps someone else out whose trying to track down issues surrounding debugattach.aspx.

Spume

Answer 9

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

Josey

SLaks, I appreciate the response, but debug has been set to true since day one of this project. – Gregoire