Unable to start debugging on the web server. Could not start ASP.NET debugging VS 2010, II7, Win 7 x64

Question

I am running Visual Studio 2010 (as Admin), IIS 7 on Windows 7 x64. I am able to run the ASP.NET web site in IIS 7 without debugging just fine, but when I press F5 to debug it, I get:

Unable to start debugging on the web server. Could not start ASP.NET debugging. More information may be available by starting the project without debugging.

Unfortunately the help link is not helping me much and leads down a heck of a large tree of things.

I checked the following:

• Security requirements — I don't recall having to do anything special before. The worker process in IIS7 is w3wp.exe. It says that if it's running as ASPNET or NETWORK SERVICE I must have Administrator privileges to debug it. How do I find out if I need to change something here?

• Web site Property Pages > Start Options > Debuggers > ASP.NET is checked. Use custom server is set to the URL of the site (which works fine without debugging).

• Debugging is enabled in web.config.

• Application is using ASP.NET 3.5 (I want to move to 4.0 eventually but I have some migration to deal with).

• Application pool: Classing .NET AppPool (also tried DefaultAppPool).

Any ideas where I can check next?

Surely it shouldn't be that hard to install IIS, VS, create a web site, and start testing it?

Thanks in advance.

Solution 1

Turns out that the culprit was the IIS Url Rewrite module. I had defined a rule that redirected calls to Default.aspx (which was set as the start page of the web site) to the root of the site so that I could have a canonical home URL. However, apparently VS had a problem with this and got confused. This problem did not happen when I was using Helicon ISAPI_Rewrite so it didn't even occur to me to check.

I ended up creating a whole new web site from scratch and porting projects/files over little by little into my solution and rebuilding my web.config until I found this out! Well, at least now I have a slightly cleaner site using .NET 4.0 (so far, hopefully I won't run into any walls)--but what a pain!

Solution 2

Try going to IIS and checking to make sure the App Pool you are using is started. A lot of times, you will produce an error that shuts down the app pool. You just need to right click and Start and you should be good to go.

Solution 3

Visual Studio, when starting up, will (for some reason) attempt to access the URL:

/debugattach.aspx

If you have a rewrite rule that redirects (or otherwise catches), say, .aspx files, somewhere else then you will get this error. The solution is to add this section to the beginning of your web.config's <system.webServer>/<rewrite>/<rules> section:

<rule name="Ignore Default.aspx" enabled="true" stopProcessing="true">
    <match url="^debugattach\.aspx" />
    <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
    <action type="None" />
</rule>

This will make sure to catch this one particular request, do nothing, and, most importantly, stop execution so none of your other rules will get run. This is a robust solution, so feel free to keep this in your config file for production.

Solution 4

For the benefit of others, in my case I had configured the application pool to use my windows credentials in order to access a network resource share. Since debugging the solution last I had reset my windows password. Changed password stored in app pool and bada bing.

Solution 5

If ApplicationPool Identity is set custom account and computer's password is changed, you have to update your password

View more solutions

Comments

[Dan C]

I followed the steps here to turn on integrated windows authentication: msdn.microsoft.com/en-us/library/x8a5axew.aspx however I still have the same error (iis manager shows warning that I cannot use both challnge and login-based authentication- my site uses Forms Authentication). I can debug site using the web server built into VS 2010, but it is missing features.

[Keefu]

Did you try creating a new website in IIS and deploying your code there? Out of curiousity, what features would you be missing if you debugged in Cassini? To my knowledge Cassini supports forms authentication.

[Dan C]

What do you mean by "creating a new website in IIS"? This is a new computer with a new OS, VS2010, IIS installs. I created a new Application in IIS and pointed it to the actual web site's folder (retrieved from a backup). URL Rewrite does not seem to be fully working in Cassini. Also we use a custom module to automatically switch between http and https (codeproject.com/KB/web-security/WebPageSecurity_v2.aspx).

[citronas]

Cassini does not support the Url Rewrite 2 Module

[Jon Adams]

True, it's a workaround, but a poor one because it is really easy to forget to remove comments like this before a commit or publish of the site.

[Junior Mayhé]

Yes but you must be sure application pool is running, also your portal.

[shalke]

You can move these lines in web.config.release config file, so when you do publish it will be only in the published version. That's what I did.

[Matt]

this unfortunately did not work for me personally however i can verify it is definitely some sort of rewrite issue as i did comment out the rewrite section of web.config and i can run without issue.

[Christopher Cabezudo Rodriguez]

Thanks, wish i have found this post Friday! the Pool was stop and i encounter the first error

[dumbledad]

Change the owner to whom?

[Jobert Enamno]

Solved my issue too! I found out that my DefaultAppPool has stopped. Thanks for sharing this. I can't understand why it stopped.

[Adi]

In my case I had to allow ASP.NET v4.0.30319 in ISAPI and CGI Restrictions

[yairr]

+1 Bad username/password used for authentication of the App Pool.

[Serj Sagan]

In my case the pool was already started, but after Stopping and Starting it again, it worked.

[iliketurtles]

Maybe just excluding /debugattach.aspx does it. Look at Peter Monks comment

[Marissa]

Thanks for this I wasn't even using a network share but this worked great.

[Frédéric]

Same cause for me, was witnessing 401 responses in my logs when trying to start debugging, and deactivating my default error handling solved the "vs can not debug site" issue for me. I do not understand why 401 occurs even on my login page when and only when starting debug with vs, while only anonymous access and web form auth. are activated.

[tuespetre]

This was the fix for me as well, only I have a default error path set instead of explicitly defining one for 401.

[Sunil]

Thanks. This solution worked for me perfectly. I had to restart the application pool in additional.

[Nicholas Westby]

This is what worked for me (I temporarily just removed the entire httperrors section). The things I tried previously that didn't work were restarting the app pool and removing URL rewrite rules.

[jerhewet]

Might want to try the solution from here: stackoverflow.com/a/30813200/375303. Works like a charm for me.

[Tim]

+1 The DefaultAppPool was stopped, and I was trying to run the project from OneDrive, to which the associated AppPoolIdentity did not have permissions.

[Nick]

On that note, my issue was in the web.config under: <applicationInitialization remapManagedRequestsTo="/App/splash.html" doAppInitAfterRestart="true" lockAttributes=""> <add initializationPage="App/index.html" hostName="CSI" lockItem="true" /> </applicationInitialization>. I was using that to show a splash screen while the application was initializing.

[Bondaryuk Vladimir]

This is what worked for me to. then i changed my custom error as @Pablo Romeo writed in this answer: stackoverflow.com/a/13905859/4489664

[mac10688]

This is the same as the number 1 answer that was proposed a month before.

[Holf]

Website was stopped in my case.

[Fernando Torres]

OK it is that, but why it stops everytime?

[Kat]

This was it for me. The rewrite rule to send all HTTP traffic to HTTPS was causing this ugly error. I couldn't find any way to keep the rule in place for debugging.

[Brandon S]

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.)

[huha]

Here Skype was listening on port 443 which prevented the web site/app pool from running. It showed error 0x80070020 in IIS manager. Can be solved as described here: support.microsoft.com/en-us/kb/973094

[Francisco G]

I had set the application pool with my Windows credentials and I forgot to change it in the pool, so it was stopped.

[Tasos K.]

In my case, the root cause is correct, but not the resolution. For me, this worked: <location path="debugattach.aspx"> <system.webServer> <validation validateIntegratedModeConfiguration="false" /> <httpErrors errorMode="DetailedLocalOnly" existingResponse="PassThrough"> <clear /> </httpErrors> </system.webServer> </location>

[CDerrig]

This was a gem for me, completely forgot about setting up my host file and was wondering why my apis weren't working when I switched over to local iis (for https). VS worked with only one site running in it, but once I added a second, I could no longer debug, this resolved it.

[Vadzim Savenok]

Yep, had a problem, tried couple answers from here without result, your answer is what really helped me!

[Liam Wheldon]

Just wanted to add that for me it was similar but the SSL rewrite we had meant thta our start path was localhost/appname but as the redirect sent you to localhost/appname it caused VS to error as it can't handle the redirect... Took us an hour+ to find this issue as when testing in IIS locally everything worked perfectly!..

[colincameron]

Thank you!! I've been tearing my hair out all day and the fix was so simple. If only VS could give a meaningful error message!

[Swisher Sweet]

Same problem here (IIS Url Rewrite module). I solve it by moving my rules to my Web.Release.config. See weblogs.asp.net/srkirkland/… and stackoverflow.com/questions/11032868/….

[1_bug]

In my scenario, everything works fine after killing all w3wp.exe process in task manager (ctrl+shift+esc).

[EMalik]

Changing erroMode to "DetailedLocalOnly" solved for me as well. Debugger was trying to open "/DebugAttach.aspx" which made it go to Custom Error Page which it couldn't run at the given time.

[EMalik]

for me problem was because of "/debugattach.aspx" but solution was changing erroMode to "DetailedLocalOnly" as well.

[Anderson]

My application pool was running on a user who had the password changed.