[Microsofts_C_Sharp] Unable to start Debugging on WebServer

Thu, 17 Mar 2005 06:49:04 -0800

 
Hi folks,
 
Now this is a really seriously smart question!
 
Well, I have been going through all the MSDN Help documentation to resolve this, and I'm still unable to get the debugging working on my local machine for the ASP.NET application that is on the webserver.
 
Here is the quick rundown,
 
I have attached the html help file on this topic, to demonstrate what steps I actually have taken to resolve this, and no joy.
 
Only one thing I must mention is that in the section where it says:
 
To configure IIS after running setup on Windows Server 2003
1
2
3<<<<< here where I don't find Security option on the right click on the machine name...
 
 
But then the .NET was installed after IIS anyway..so what am I missing guys???
 
Thanks alot in advance guys..
 
 
 
 
 
Visual Studio  

Error: Unable to Start Debugging on the Web Server

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

Unable to start debugging on the Web server

If you encounter these errors, there are several things to consider:

Things to Check

If you get an "Unable to start debugging on the Web server" error, try checking the following things:

  • 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 Debug Mode in 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.
  • You need to be a member of the Debugger Users group or an administrator if the ASP.NET worker process runs under your own user account.
  • You need to be a member of the Administrators group if the ASP.NET worker process runs under any other user account besides your own.
  • 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).
  • Does the machine running IIS server have Visual Studio .NET Remote Components installed?
  • Was IIS installed on the local machine (the machine running Visual Studio .NET) after Visual Studio .NET was installed? IIS should be installed before Visual Studio .NET. If it was installed afterwards, you may need to repair the .NET Framework.

    To repair the .NET Framework

    • Insert the Visual Studio .NET disc and enter as one line at the command line: 
      <DVD Drive>:\wcu\dotNetFramework\dotnetfx.exe /t:c:\temp 
/c:"msiexec.exe /fvecms c:\temp\netfx.msi"

      âorâ

      Insert the Visual Studio .NET Requirements disc and enter as one line at the command line: 

      <CD Drive>:\dotNetFramework\dotnetfx.exe /t:c:\temp 
/c:"msiexec.exe /fvecms c:\temp\netfx.msi"
  • Is the URL for the project start page properly specified? Are the extension and project directory correct?
  • Are the IIS security settings set up properly? To verify this, check the Default Web Site settings.

To check IIS security settings for the Default Web Site

  1. From the Start menu, choose Programs, then Administrative Tools, and click Internet Services Manager (Windows 2000) or Internet Information Services (Windows XP).
  2. In the Internet Services Manager or Internet Information Services dialog box, click the tree control for your machine. In the Web Sites folder, find Default Web Site.
  3. Right-click Default Web Site and choose Properties.
  4. In the Default Web Site Properties window, select the Directory Security tab and click Edit.
  5. In the Authentication Methods dialog box, select Anonymous Access and Integrated Windows Authentication (if not already selected).
  6. Click OK to close the Internet Services Manager or Internet Information Services dialog box.
  7. Click OK.
    • For an ATL Server application, verify that the DEBUG verb is associated with your ISAPI extension.
    • For an ASP.NET application, make sure the virtual folder for the application has an Application Name set in Internet Services Manager or Internet Information Services.

To designate the virtual folder for the Web application

  1. From the Start menu, choose Programs, then Administrative Tools, and click Internet Services Manager (Windows 2000) or Internet Information Services (Windows XP).
  2. In the Internet Services Manager or Internet Information Services dialog box, click the tree control for your machine. In the Web Sites folder, find the Web application.
  3. Right-click the Web application and choose Properties.
  4. In the Web application Properties window, select the Directory tab.
  5. Under Application Settings, click Create.

    The application name appears in the box.

  6. Click OK to close the Properties dialog box.
  7. Click OK to close the Internet Services Manager or Internet Information Services dialog box.

Web Applications on Remote Servers

If the Web application is on a remote server, check the following:

  • Were the proper setup programs run to install ASP.NET or ATL Server and remote debugger components on the server?
  • Do you have the necessary access privileges to debug processes running under the system account? You need to be a member of the Debugger Users group or an administrator if the ASP.NET worker process runs under your own user account. You need to be a member of the Administrators group if the ASP.NET worker process runs under any other user account besides your own. (See Adding Debugger Users and Configuring DCOM for procedural information.)

    ASP.NET applications run as ASPNET by default. To debug an application running under aspnet_wp.exe, you need Administrator privileges or edit the machine.config file for aspnet_wp.exe so that aspnet_wp.exe runs under your user account. (On Windows Server 2003, the worker process is called w3wp.exe rather than aspnet_wp.exe, and you can change the account it runs under using IIS.) To debug an application running under inetinfo.exe, you need to be Administrator on the machine running inetinfo.exe.

    ATL Server applications run under inetinfo.exe or the ATL worker process dllhost.exe, depending on security settings. To debug an application running under inetinfo.exe, you must be an Administrator on the machine running inetinfo.exe, or you can configure dllhost to run as a particular user using the common language runtime application settings

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

IIS on Windows Server 2003

When you install Visual Studio .NET on Windows Server 2003, ASP.NET is not enabled by default. To develop Web projects, you must run the Security Lockdown Wizard after completing Visual Studio .NET Setup.

If you run the Security Lockdown Wizard before Visual Studio .NET setup is complete, the correct version of ASP.NET may not be enabled. Visual Studio .NET Setup installs a new version of ASP.NET. To ensure that the latest version of ASP.NET is enabled, you must run the Security Lockdown Wizard after setup has finished.

To configure IIS after running setup on Windows Server 2003

  1. From the Start menu, choose All Programs.
  2. Choose Administrative Tools and then choose Internet Information Services.
  3. Right-click your machine name in the left pane and choose Security.
  4. On the first screen of the IIS Security Lockdown Wizard, click Next.
  5. Verify that HTTP is set to Automatic and click Next.
  6. In the Request Handlers list, check ASP.NET and each instance of n:\WINDOWS\Microsoft.NET\Framework\<version number>\aspnet_isapi.dll.
  7. Click Next.
  8. Click Finish to complete the wizard

Web Applications Stored in Visual SourceSafe and Using FrontPage Server Extensions

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 Default Web Site earlier.)

Manually Attaching

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. Attach to the appropriate IIS process or worker process. By default, inetinfo.exe for ATL Server applications or aspnet_wp.exe for ASP.NET applications (w3wp_wp.exe for ASP.NET applications under Windows Server 2003).

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

To check which process an ASP.NET application runs under

  1. Use Visual Studio .NET or another text editor to open the machine.config file for the application.
  2. Find this process model attribute: 
    enable

    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.

See Also

Debugging Script and Web: Errors and Troubleshooting


Send feedback on this topic to Microsoft

 Microsoft Corporation. All rights reserved.
Yahoo! Groups Sponsor
ADVERTISEMENT
click here

Yahoo! Groups Links

Reply via email to