Welcome Sign in
Visual Studio 2005 Developer Center
Click to Rate and Give Feedback
This page is specific to
Microsoft Visual Studio 2005/.NET Framework 2.0

Other versions are also available for the following:
Visual Studio Debugger
Error: Unable to Start Debugging on the Web Server

When you try to debug an application running on a Web server, you may sometimes get this error message:

Unable to start debugging on the Web server

If your message is longer than that, it is covered by a subtopic of this one.

If you encounter this error, there are several things to consider. First go to Things to Check, and then consider the remaining items based on your hardware and software configuration.

Try checking the following things:

  • Review the procedures for setting up ASP.NET or ATL Server. For more information see Getting Ready to Debug ASP.NET Applications.

  • Do you have the necessary access privileges for debugging? For more information see the Security Requirements section in ASP.NET Debugging: System Requirements.

  • Are you running a version of Windows that allows the Visual Studio debugger to automatically attach to a Web application? If not, you need to launch the application without debugging and manually attach to it. (For more information, see Manually Attaching and ASP.NET Debugging: System Requirements.)

  • Does your Web application have a Web.config file?

    • Does the Web.config file enable debug mode by setting the debug attribute to true? For more information, see How to: Enable Debugging for ASP.NET Applications.

    • Does the Web.config file contain any syntax errors? You can check for syntax errors by running the Web application without debugging. (From the Debug menu, choose Start Without Debugging.) If there are syntax errors in Web.config, detailed information will be displayed.

  • Did you create the project by specifying a specific IP address (100.20.300.400, for example)? Debugging a Web server requires NTLM authentication. By default, IP addresses are assumed to be part of the Internet, and NTLM authentication is not done over the Internet. To correct this problem:

    • When creating the project, specify the name of the machine on your intranet.

      -or-

    • Add the IP address (http://100.20.300.400) to the list of trusted sites on your computer. (From the Internet Explorer Tools menu, choose Internet Options, and then select the Security tab).

    Are the necessary extensions registered on the server machine? If not, re-register ASP.NET as described in the procedure below.

  • Was IIS installed on the local machine (the machine running Visual Studio) after Visual Studio was installed? IIS should be installed before Visual Studio. If it was installed afterwards, you may need to re-register ASP.NET.

    To re-register ASP.NET

    1. From a command prompt window, run the following command: systemroot\Microsoft.NET\Framework\ versionNumber \aspnet_regiis -i

      Note   With Windows Server 2003, you can install ASP.NET using the Add or Remove Programs Control Panel.

    2. Insert the Visual Studio disc, run the setup program, and select Repair/Reinstall. This step will create the wwwroot$ share and add the appropriate permissions.

  • Is the URL for the project start page properly specified? Are the extension and project directory correct?

  • Verify the IIS settings for the Web application. For more information see How to: Verify IIS Property Settings.

  • If you have two versions of the .NET Framework installed on the Web server, verify the correct version is set in the IIS Settings. For more information see How to: Verify IIS Property Settings.

If the Web application is on a remote server, first make sure you have gone through the items in Things to Check. Next check the following:

  • Does the machine running IIS server have the Visual Studio Remote Components installed? For more information see Getting Ready to Debug ASP.NET Applications.

  • Do you have the necessary access privileges for debugging? For more information see the Security Requirements section in ASP.NET Debugging: System Requirements.

  • Are you using Terminal Server to try to debug a Web application on a remote machine? Remote debugging of native Web applications using Terminal Server is supported under Windows XP. It is not supported under Windows 2000 or Windows NT.

If the Web application is stored in Visual SourceSafe and uses FrontPage Server Extensions as its Web Access mode, check the following:

  • Is Visual SourceSafe located on the same machine as the FrontPage Server/Web server? If so, you can debug using Integrated Authentication. To check the Integrated Authentication setting, see the procedure To check IIS security settings for the web application located in the following topic: How to: Verify IIS Property Settings.

Sometimes, the server cannot process a debug request due to bad syntax. Bad request syntax may be caused by mistakes in the machine.config file. If the machine.config file sets maxRequestLength to a ridiculously large value (40,960,000, for example), this error occurs.

If you follow the troubleshooting steps and still get an error message when you start debugging, you may want to try debugging your application by manually attaching.

To manually attach

  1. Start the application without debugging. (From the Debug menu, choose Start Without Debugging.)

  2. Determine the name of the appropriate IIS process or worker process. ATL Server applications are named inetinfo.exe by default. To determine the name of the ASP.NET worker process, see How to: Find the Name of the ASP.NET Process. 

    Use one of the following procedures to determine which process an ASP.NET or ATL Server application runs under.

  3. Attach to the process determined by the preceding step. For more information, see How to: Attach to a Running Process.

To check which process an ASP.NET application runs under

  1. Use Visual Studio or another text editor to open the machine.config file for the application.

  2. Inside the system.web node, find the ProcessModel node, and examine its enable attribute:

    If enable is set to TRUE, the application runs under aspnet_wp.exe or w3wp.exe. (This is also the default setting.)

    If enable is set to FALSE, the application runs under inetinfo.exe.

To check which process an ATL Server application runs under

  1. In Solution Explorer, right-click the project name and choose Properties from the shortcut menu.

  2. In the <Project> Property Pages dialog box, open the Web Deployment folder and choose General.

  3. Look at the Application Protection setting.

    If the setting is Low (IIS Process), the application runs under inetinfo.exe.

    If the setting is Medium (Pooled), the application runs under a dllhost.exe process (in common with other pooled ATL Server applications).

    In the setting is High (Isolated), the application runs under a dllhost.exe process (separate from other ATL Server applications).

  4. Click OK to close the <Project> Property Pages dialog box.

Tags What's this?: Add a tag
Community Content   What is Community Content?
Add new content RSS  Annotations
Error: Unable to Start Debugging on the Web Server - Things to Check      RonAvraham   |   Edit   |  
  • Verify the HTTP Keep-Alives is checked
    HTTP Keep-Alives Enabled
    Allows a client to maintain on open connection with your server, rather than re-opening the
    client connection with each new request.

    A typical Web page is made up of a number of elements (.htm files and .gif or .jpeg files),
    Enabling HTTP keep-alives will mean IIS keeps the connection open so the Web browser can
    download an entire Web page made up of different elements without having to remake
    a connection for each one, and i guess after connection close the IIS the element will lose too,
    so the debugger need them all "alive".
    NOTE: Disabling Keep-Alives may degrade server performance.
    HTTP Keep-Alives are enabled by default in IIS

    verifying the Enable HTTP Keep-Alives  is checked
    1.
       Open the Internet Information Services (IIS),
       click the tree control node for your machine,
       click the Web Sites node,
       Right-click the Default Web Site node and on the shortcut menu, click Properties.
    2.
       On the Web Site tab, in the Connection section,
       verify that Enable HTTP Keep-Alives checkbox is checked.

 

 

 

Tags What's this?: Add a tag
Flag as ContentBug
IP addresses      kidajo   |   Edit   |  

It is helpful to know that the IP address specified in the article, 100.20.300.400, is not to be taken literally. In fact, it is not a valid IP address.

You should replace the 100.20.300.400 given with a valid IP address, the IP address of your computer. This may be found with the following line at the command prompt:

 ipconfig /all
Tags What's this?: Add a tag
Flag as ContentBug
vs05 error      southgate17   |   Edit   |  

What about this error?

Tags What's this?: Add a tag
Flag as ContentBug
Startup options -> specific page value      RPMPD   |   Edit   |  

If in the projects properties the Startup Options has the Specific Page value selected and set the value must contain a filename at the very least. If the value only contains a set of query string values (ie "?Language=EN&sid=12345") then the debugging error will be displayed. I beleive this is an incorrect error for this case and hopefully will be adjusted with a service pack update beyond SP1.

Tags What's this?: Add a tag
Flag as ContentBug
Unable to Start Debugging on the Web Server - Important hints      gnesland   |   Edit   |  

1. Check that the web project runs as a project of its own. This means that you have to create a default web site for the project on the Internet Information Server.

2. Access "Properties" for the web project within the IIS administration window. Choose the "ASP.NET" tab. Check that the project is running the correct ASP.NET version.

Tags What's this?: Add a tag
Flag as ContentBug
© 2008 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Page view tracker