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

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.

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.

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!

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.

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.

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

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.

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

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

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.

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

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.

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!

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!

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

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?

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

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.

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'

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.

Check if your website on IIS is not stop.

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

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.

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

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.

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

Uninstalling the IIS UrlScan Extension solved the problem for me.

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.

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.

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.

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.

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.

Instead of using the IIS, just use IIS Express.