92

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.

abatishchev
  • 98,240
  • 88
  • 296
  • 433
Dan C
  • 2,236
  • 2
  • 19
  • 30
  • 1
    Just to be clear when you started Visual studio you right clicked on it and choose the Run As Administrator option? – Aaron Carlson Jan 11 '11 at 02:59
  • Have you checked out this link yet? http://msdn.microsoft.com/en-us/library/dwesw3ee.aspx – Aaron Carlson Jan 11 '11 at 03:04
  • @Aaron, Yes, I actually have VS set to always run as Administrator. – Dan C Jan 11 '11 at 03:11
  • @Aaron, I explicitly went through that page and its children before posting here and nothing stood out that I needed to do. My system meets the requirements and debugging is turned on for the site. I don't have Windows Server 2003 so no configuring IIS done there. Haven't touched any security settings on anything since I don't know if I need to. – Dan C Jan 11 '11 at 03:21
  • Not sure if this helps, but I tried to create a new test ASP.NET 3.5 Web Site in VS 2010, added it to IIS 7 without any special configs and was able to debug it fine. Something with my main application with how it's configured in VS, IIS, or perhaps even the file system. Just not sure where to begin looking. – Dan C Jan 11 '11 at 03:22
  • I know you said you went through the whole article but did you attempt to use the attach to process method? – Aaron Carlson Jan 11 '11 at 04:44

31 Answers31

239

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.

Trey Copeland
  • 3,387
  • 7
  • 29
  • 46
  • Thanks, wish i have found this post Friday! the Pool was stop and i encounter the first error – Christopher Cabezudo Rodriguez Mar 18 '13 at 14:51
  • In my case I had to allow ASP.NET v4.0.30319 in ISAPI and CGI Restrictions – Adi Feb 20 '14 at 09:02
  • 15
    +1 Bad username/password used for authentication of the App Pool. – P.Brian.Mackey Jun 02 '14 at 18:05
  • 3
    In my case the pool was already started, but after Stopping and Starting it again, it worked. – Serj Sagan Jun 20 '14 at 15:48
  • 1
    Thanks. This solution worked for me perfectly. I had to restart the application pool in additional. – Sunil Feb 16 '15 at 12:18
  • +1 The DefaultAppPool was stopped, and I was trying to run the project from OneDrive, to which the associated AppPoolIdentity did not have permissions. – Tim Jul 15 '15 at 16:32
  • Website was stopped in my case. – Holf Feb 09 '16 at 11:15
  • 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: https://support.microsoft.com/en-us/kb/973094 – huha Mar 24 '16 at 09:25
  • I had set the application pool with my Windows credentials and I forgot to change it in the pool, so it was stopped. – Francisco G Apr 14 '16 at 15:56
  • In my scenario, everything works fine after killing all `w3wp.exe` process in task manager (ctrl+shift+esc). – 1_bug Sep 05 '17 at 10:55
46

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!

Dan C
  • 2,236
  • 2
  • 19
  • 30
  • 6
    Yes but you must be sure application pool is running, also your portal. – Junior Mayhé Sep 08 '11 at 20:03
  • On that note, my issue was in the web.config under: . I was using that to show a splash screen while the application was initializing. – Nick Oct 13 '15 at 16:53
  • 6
    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. – Kat Mar 18 '16 at 19:30
  • Just wanted to add that for me it was similar but the SSL rewrite we had meant thta our start path was http://localhost/appname but as the redirect sent you to https://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!.. – Liam Wheldon Sep 01 '16 at 09:39
  • Same problem here (IIS Url Rewrite module). I solve it by moving my rules to my `Web.Release.config`. See https://weblogs.asp.net/srkirkland/common-web-config-transformations-with-visual-studio-2010 and https://stackoverflow.com/questions/11032868/web-config-transformation-to-add-a-child-element. – Swisher Sweet Jun 18 '17 at 21:21
43

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.

Kirk Woll
  • 76,112
  • 22
  • 180
  • 195
  • 1
    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. – Matt Dec 14 '12 at 20:41
  • Might want to try the solution from here: http://stackoverflow.com/a/30813200/375303. Works like a charm for me. – jerhewet Jun 12 '15 at 22:49
  • 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.) – Brandon S Mar 22 '16 at 18:53
  • In my case, the root cause is correct, but not the resolution. For me, this worked: ` ` – Tasos K. May 30 '16 at 09:35
  • for me problem was because of "/debugattach.aspx" but solution was changing erroMode to "DetailedLocalOnly" as well. – EMalik Sep 25 '17 at 17:51
  • This SHOULD BE THE ACCEPTED ANSWER because it details the problem, exactly. In our case, all `.aspx` requests were being redirected to `index.aspx`. We added a similar rule that stopped processing for any request that matched ``. – sthames42 May 23 '23 at 18:17
30

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.

Breeno
  • 3,007
  • 2
  • 31
  • 30
21

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

Hello World
  • 211
  • 2
  • 4
20

For my scenario it was changes to the httpErrors section in web.config, setting it like this:

<httpErrors mode="Custom"> 

caused the "Unable to start debugging on the web server" issue. Setting it back to the previous value of "DetailedLocalOnly" fixed the issue. Digging a little deeper I discovered that it was actually just the 401 error setting that was causing this:

<httpErrors mode="Custom"> 
    <error statusCode="401" prefixLanguageFilePath="" path="/masterpages/500.html" responseMode="ExecuteURL" />
<httpErrors mode="Custom"> 

Commenting out the 401 error line fixed the issue as well, I went with that since I can then maintain the custom error handling and start with debugging.

I still have no idea why this is happening.

  • 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. – Frédéric Sep 03 '14 at 13:34
  • This was the fix for me as well, only I have a default error path set instead of explicitly defining one for 401. – tuespetre Jan 22 '15 at 17:23
  • 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. – Nicholas Westby Jun 12 '15 at 15:31
  • This is what worked for me to. then i changed my custom error as @Pablo Romeo writed in this answer: http://stackoverflow.com/a/13905859/4489664 – Bondaryuk Vladimir Dec 29 '15 at 12:31
  • 2
    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 Sep 25 '17 at 17:47
13

Plase check application pool. if it is stoped. restart it.

user3206598
  • 147
  • 1
  • 2
11

Had the same issue trying to debug a DNN (Dot Net Nuke) module. Turned out you need to have compilation debug="true":

<compilation debug="true" strict="false" targetFramework="4.0"> 

in your web.config. By default it is false in DNN. Original source here: http://www.dnnsoftware.com/forums/forumid/111/postid/189880/scope/posts

Zar Shardan
  • 5,675
  • 2
  • 39
  • 37
  • 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! – colincameron May 11 '17 at 16:30
8

I have exactly the same problem after implementing the rewrite module.

If I remove the rewrite entries from my web.config file, debugging works perfectly.

To get around this, I just to comment out the rewrite tags while debugging, like this...

<rewrite>
    <rules>
        <rule name="LowerCaseRule_1" stopProcessing="true">
            <match url="[A-Z]" ignoreCase="false" />
            <action type="Redirect" url="{ToLower:{URL}}" />
        </rule>
        <rule name="RedirectDefault.aspx_1" stopProcessing="true">
            <match url="(.*)default.aspx" />
            <action type="Redirect" url="{R:1}" redirectType="Permanent" />
        </rule>
    </rules>
</rewrite>

I then remove the comments after debugging.

Must be an bug in visual studio 2010.

abatishchev
  • 98,240
  • 88
  • 296
  • 433
geofili
  • 81
  • 1
  • 1
  • 1
    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. – Jon Adams Jul 19 '11 at 19:49
  • 1
    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. – shalke May 03 '12 at 08:46
  • Maybe just excluding /debugattach.aspx does it. Look at Peter Monks comment – Daniel Fisher lennybacon Jul 23 '14 at 13:26
6

I got the same error since Application pool was stopped in IIS. After starting the App Pool, the issue was resolved.

Ovini
  • 351
  • 5
  • 13
  • Solved my issue too! I found out that my DefaultAppPool has stopped. Thanks for sharing this. I can't understand why it stopped. – Jobert Enamno Jan 06 '14 at 07:36
5

Just finally fixed this for my single solution that was having this. Two of the projects in the solution were set as sites in IIS. I went in and enabled ASP.Net Impersonation under Authentication for both projects...and VIOLA! FINALLY, no more of this annoying error!

Todd Vance
  • 4,627
  • 7
  • 46
  • 66
5

Here is what I did to clear the error you noted. Locate the web folder for the app within the file system, go to Properties=>Security click the Advanced button then click the Owner tab, click the Edit button and change the owner (with the correct permissions) of the folder and checked the "Repalce owner on subcontainers and objects" checkbox. Click "Apply" and then I was in business (able to debug).

Hope this works for someone else.

Moe Howard
  • 498
  • 7
  • 12
3

If App Pool has trouble restarting or simply doesn't want to restart, verify if windows made recent update on ASP.NET v4.0 or other App Pool. That is what happend in my case. I simply restarted my computer, then restarted ASP.NET v4.0 App Pool and everything was working again!

3

I was getting the same error message in VS 2012, but was not running as Administrator. When I ran the app as administrator, I got a different and slightly more helpful message (which I was able to figure out). HTH

Tom Gerken
  • 2,930
  • 3
  • 24
  • 28
2

Had the same problem with Windows 10 when turned on all IIS windows features. Switched to Windows 8.1 and got problem again. The root was in web site name "http://MySite.local" (not related to OS version).

And solution is simple

  • Edit hosts file in %SystemRoot%\System32\drivers\etc\

  • Add line with ip binding: 127.0.0.1 MySite.local

Artur A
  • 7,115
  • 57
  • 60
  • 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. – CDerrig Jun 22 '16 at 21:26
2

Dan,

In addition to Aaron's suggestions, try the following

  • Check that integrated windows authentication is selected in your IIS website
  • Can you debug using Cassini instead of IIS?
Keefu
  • 124
  • 8
  • I followed the steps here to turn on integrated windows authentication: http://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. – Dan C Jan 11 '11 at 04:03
  • 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. – Keefu Jan 11 '11 at 04:52
  • 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 (http://www.codeproject.com/KB/web-security/WebPageSecurity_v2.aspx). – Dan C Jan 11 '11 at 22:15
  • Cassini does not support the Url Rewrite 2 Module – citronas Mar 14 '11 at 22:14
1

I had this error come up today due to a defect in code that was posting back a tremendous amount of times causing IIS to be flooded with requests. This essentially locked up IIS and so when I tried to debug, it 'timed out' trying to start the debugger. I simply restarted IIS, which took a few minutes, and it solved the issue.

I sure do wish this error was less generic, seems like there are several different ways to produce it.

ammills01
  • 709
  • 6
  • 28
1

I had the same problem in Visual Studio 2012 and 2013 on Windows 8.1. For me the fix was to add Windows Authentication to IIS using 'Turn Windows features on or off'

Turn Windows features on or off screenshot

dumbledad
  • 16,305
  • 23
  • 120
  • 273
1

Be sure your site's Application Pool uses the correct framework version. I got the "Unable to start debugging" error on an ASP.Net 2005 site. It was incorrectly using the DefaultAppPool on Windows 7 (which I believe was using .Net Framework 4). I created a new a App Pool based on .Net Framework 2 and assigned it to the problem web site. After that debugging worked fine.

DeveloperDan
  • 4,626
  • 9
  • 40
  • 65
1

Check if your website on IIS is not stop.

I fixed it put my web site to run. :D

AFetter
  • 3,355
  • 6
  • 38
  • 62
1

I had the same issue and found that it was caused because i had a character mistakenly typed in my Web.config after the end tag. My Web.config looked like this right at the end: </section>h. The "h" was an extra character after the closing tag.

silkfire
  • 24,585
  • 15
  • 82
  • 105
Lavanya
  • 11
  • 1
1

I had this problem and eventually realized that I ASP.net is not registered properly with IIS. This can happen when IIS server is installed before Visual Studio. To fix this issue, use the command aspnet_regiis -i Further information can be found in the link

karpanai
  • 235
  • 4
  • 14
1

had same issue. If you have SSL certificate installed on IIS and if you are trying to debug it from Visual Studio then you need to set your application on IIS to ignore certificate.

akd
  • 6,538
  • 16
  • 70
  • 112
0

remove sting like this: targetFramework="4.0" in web.config or change AppPool to appropriate framework version.

Slava
  • 3,445
  • 1
  • 20
  • 16
0

Uninstalling the IIS UrlScan Extension solved the problem for me.

Thomas
  • 11
  • 1
0

I had faced the same problem but it was on Visual studios's own web development server instead of IIS.The get around is to uncheck the option in Web tab under project properties, Apply server settings to all users(store in project file.).Hope it will save some one's valuable time.

0

I had the same problem. All the answers above did not work for me. The solution was to delete the bin and obj folder manually.

user1949096
  • 91
  • 1
  • 1
  • 4
0

I found this issue too but it was most similar to what @Kirk explained and URL rewriting.

In my case someone had checked in this change to the web.config file for a MVC project:

<system.webServer>
    <security>
        <requestFiltering>
            <fileExtensions>
                <add fileExtension=".aspx" allowed="false" />
            </fileExtensions>
        </requestFiltering>
    </security>
</system.webServer>

Because .aspx file extensions were not allowed on the web server, the /debugattach.aspx URL was denied, preventing the debugger from running. Once I removed this configuration it worked again.

Peter Monks
  • 4,219
  • 2
  • 22
  • 38
0

I had the same problem when I created application in Visual Studio, and then in properties created virtual directory for use with local IIS. If someone has this error it is because VS creates application under wrong AppPool, i.e. under AppPool which doesn't suit your needs.
If this is the case, go to IIS Manager, select App, Go to Basic settings and change AppPool for App and you are good to go.

Willow
  • 59
  • 1
  • 9
0

I got this same error recently and in my case it turned out that there were duplicate MIME types. I had recently added two that didn't show up in the list initially. IIS let me add them and it was only when I decided to check the MIME types for the site again as part of my diagnostic process that I got an error in IIS as well. It referenced duplicates in web.config. Once I went back into the web.config file I noticed that a new section called had been added, which included the two recently-added MIME types. Deleted that section and life is good again! Hoping this may help others who haven't managed to fix the issue with any of the other suggestions.

Mike
  • 417
  • 7
  • 28
-5

Instead of using the IIS, just use IIS Express.