Table of Content
Debugging is a very powerful option for the developers and it helps the developers in finding and analyzing the defects and other issues with the code.
NOTE: Enabling debug mode will greatly affect the performance of your ASP.NET application. Remember to disable debug mode before you deploy a release application or conduct performance measurements.
Proper configuration settings of the machine, users and the project are required to enable the Visual Studio 2005 debugging. VS displays following error message when debugging is not enabled and user try to debug an ASP.NET web application.
Error: Unable to Start Debugging on the Web Server
This step-by-step article describes how to configure the server, users and project to debug the ASP.NET Web applications. This document compile the findings from various websites primarily Microsoft websites and various groups.
Enabling the ASP.NET debugging can be divided into the following sub tasks:
1. Checking the configuration setting of the machine, users and the project.
2. Debugging your application by Manually Attaching
3. Appendix – general information and solution for some common errors.
1. ASP.NET debugging must be enabled in Project Properties. Following are the steps to enable debugging for Web application in the project properties.
a. Open the Property Pages by right-clicking the project name in Solution Explorer, and selecting Property Pages.
b. Click the Start Options tab.
c. Under Debuggers, make sure the ASP.NET box is selected.
2. The configuration file of your application (Web.config) must be set to debug mode.
Debug mode causes ASP.NET to generate symbols for dynamically generated files and enables the debugger to attach to the ASP.NET application. Visual Studio sets this automatically when you start to debug, if you created your project from the Web projects template.
Following are the steps to enable debugging in the web.config file.
a. Verify your web application have a Web.config file.
b. Open the web.config file using any standard text editor or XML parser.
c. Look for the
d. Attributes are case sensitive, so be sure to specify "debug", not "Debug" or "DEBUG."
e. Set debug to true, as shown in the following code example.
f. If you do not set the debug attribute to true and attempt to debug, a dialog box will appear offering to create a web.config file with the attribute set. Accept, and continue debugging.
g. If the Web.config file contains any syntax errors then you will not able to debug. 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.
3. Web site or virtual folder must be configured as an application in IIS
Make sure the website or the virtual folder for the application has an Application Name set in IIS
a. Right-click Web Site/Virtual Directory and choose Properties.
b. In the Properties window, select the Directory tab.
c. Under Application Settings, look for the Remove or Create button.
d. If the button says Remove, your website is already configured as an application.
e. If the button says Create, click the button to configure your website as an application.
f. Click OK.
g. Verify that the name in the Local path matches the name of the directory where the application was actually deployed.
h. Under Application Settings, type the name of the root directory that contains the application.
4. Verify correct version of ASP.NET specified
a. If you have two versions of the .NET Framework installed on the web server, verify the correct version is set in the IIS Settings.
b. In the Web application Properties window, select the Directory tab and verify that the correct version of ASP.NET is specified.
c. Click OK to close the Properties dialog box.
5. Solution for error “ASP.NET Not Installed”
This error occurs when ASP.NET is not installed properly on the machine you are trying to debug. This may mean that ASP.NET was never installed or that ASP.NET was installed first and IIS was installed later. IIS should be installed before Visual Studio. If it was installed afterwards, you may need to re-register ASP.NET.
To reinstall the ASP.NET
a. From a command prompt window, run the following command.
systemroot\Microsoft.NET\Framework\versionNumber \aspnet_regiis -i
E.g. C:\WINNT\Microsoft.NET\Framework\version\aspnet_regiis –i
b. Where version represents the version number of the .NET Framework installed on your machine, such as v1.0.370.
c. Note - With Windows Server 2003, you can instaall ASP.NET using Add or Remove Programs in Control Panel. 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.
6. Adequate permissions is configured for the authentication methods for the Web application
a. Open the IIS web application property page. In the Web application Properties window, click the Directory Security tab, and click Edit.
b. In the Authentication Methods dialog box, select Enable Anonymous Access and Integrated Windows authentication if they are not already selected.
c. Click OK to close the Authentication Methods dialog box.
7. Adequate permissions is configured for the ASP.NET worker process
a. To debug the ASP.NET worker process you must have permission to debug that process. ASP.NET applications run as the ASPNET user by default. If the worker process is running as ASPNET, or as NETWORK SERVICE, you need Administrator privileges to debug it.
b. The name of the ASP.NET worker process varies by debugging scenario and by version of IIS. Also applications built using VS 2005, the ASP.NET code can reside on the file system and run under the test server WebDev.WebServer.exe.
c. You can change the user that the ASP.NET worker process runs under. On Windows 2000 and XP, you do this by editing the machine.config file on the IIS server machine. On Windows Server 2003, you do this by using the Internet Information Services (IIS) Manager.
d. If you change the user to your own user account, you do not need to be an Administrator on the IIS server machine. If you change it to anything else, you have to be a member of the Administrators group in order to debug.
Note - You should consider the consequences of the ASP.NET worker process getting hacked. The users ASPNET and NETWORK SERVICE have minimal permissions, which reduce the impact of successful hacking. If you must change the user to one with more permission, then carefully consider the security implications.
8. Error: Site Uses IP Address
This error occurs when the debugger tries to auto-attach to a Web application that is using an IP address. This occurs if you change Web site identification to use specific IP address in IIS.
For auto-attach to work, you need to create the project with the specific IP address rather than just the machine name. Otherwise, the debugger will change the machine name to localhost, which will cause a failure to send the debug verb to IIS.
To correct this error
a. Use manual attach instead (from the Debug menu, choose Attach to Process).
c. Change the IIS Web site identification setting.
9. IP address is added to the list of trusted sites on your computer
d. Debugging a Web server requires NTLM authentication.
e. Incase you create the project by specifying a specific IP address (100.20.300.400, for example) then 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).
The reason for that is that by default, IP addresses are assumed to be part of the Internet, and NTLM authentication is not done over the Internet. This is not required if project is created by specifying the name of the machine on your intranet.
10. Debug Request Could Not Be Processed By the Server Due to Invalid Syntax
- 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.
11. PRB: Cannot Debug ASP.NET Web Application http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q318465
When you debug an ASP.NET application in Microsoft Visual Studio .NET, you may receive the following Microsoft Development Environment error message:
Error while trying to run project: Unable to start debugging on the web server. The server does not support debugging of ASP.NET or ATL Server applications. Run setup to install the Visual Studio .NET server components. If setup has been run, verify that a valid URL has been specified.
You may also want to refer to the ASP.NET and ATL Server debugging topic in the online documentation. Would you like to disable future attempts to debug ASP.NET pages for this project?
To resolve this problem, use the Aspnet_regiis.exe administration utility that manages the installation and uninstallation of multiple versions of ASP.NET on a single computer.
To use the Aspnet_regiis.exe utility, follow these steps:
- Click Start, and then click Run.
- Type cmd in the Open box, and then click OK to open a command prompt.
- At the command prompt, use the cd command to change to the following directory:
- C:\Windows Directory\Microsoft.Net\Framework\Version
- Note: You must replace Windows Directory in this path with the correct directory for your system and replace Version with the version of the .NET Frame work installed on your system.
- Type aspnet_regiis -i to configure the required application mappings correctly.
12. Check Secure Communication
- I noticed this problem went away after I went to IIS and the app's virtual directory, properties and then went to the Directory Security tab, clicked Edit under Secure Communication and turned OFF Require SSL!
- Right-click Web Site/Virtual Directory and choose Properties.
- In the Properties window, select the Directory Security tab.
- Under Secure Communication, click at the Edit button.
- turned OFF Require SSL
- Click OK.
13. Error 401.1 (http://support.microsoft.com/?kbid=896861)
When you use the fully qualified domain name (FQDN) to browse a local Web site that is hosted on a computer that is running IIS 5.1 or IIS 6, you may receive an error message that is similar to the following:
HTTP 401.1 - Unauthorized: Logon Failed
This issue occurs when the Web site uses Integrated Authentication and has a name that is mapped to the local loopback address.
You may also receive an error message that is similar to the following when you try to debug a Microsoft ASP.NET project in Microsoft Visual Studio 2003:
Error while trying to run project: Unable to start debugging on the web server. You do not have permissions to debug the server.
Verify that you are a member of the 'Debugger Users' group on the server.
Note The word "Web" is incorrectly capitalized in this error message.
Cause - This issue occurs if you install Microsoft Windows XP Service Pack 2 (SP2) or Microsoft Windows Server 2003 Service Pack 1 (SP1). Windows XP SP2 and Windows Server 2003 SP1 include a loopback check security feature that is designed to help prevent reflection attacks on your computer. Therefore, authentication fails if the FQDN that you use does not match the local computer name.
Method 1: Disable the loopback check
- Click Start, click Run, type regedit, and then click OK.
- In Registry Editor, locate and then click the following registry key:
- Right-click Lsa, point to New, and then click DWORD Value.
- Type DisableLoopbackCheck, and then press ENTER.
- Right-click DisableLoopbackCheck, and then click Modify.
- In the Value data box, type 1, and then click OK.
- Quit Registry Editor, and then restart your computer.
Method 2: Specify host names
To specify the host names that are mapped to the loopback address and can connect to Web sites on your computer, follow these steps:
- Click Start, click Run, type regedit, and then click OK.
- In Registry Editor, locate and then click the following registry key:
- Right-click MSV1_0, point to New, and then click Multi-String Value.
- Type BackConnectionHostNames, and then press ENTER.
- Right-click BackConnectionHostNames, and then click Modify.
- In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
- Quit Registry Editor, and then restart your computer.
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. It should be aspnet_wp.exe, w3wp.exe or inetinfo.exe by default. (See appendix - How to: Find the Name of the ASP.NET Process).
3. Check which process an ASP.NET application runs under
a. Use Visual Studio or another text editor to open the machine.config file for the application.
b. Inside the system.web node, find the ProcessModel node, and examine its enable attribute:
c. If enable is set to TRUE, the application runs under aspnet_wp.exe or w3wp.exe. (This is also the default setting.)
d. If enable is set to FALSE, the application runs under inetinfo.exe.
4. Attach to the process determined by the above step.
a. From the Debug menu, choose Attach to Process. (If no project is open, choose Attach to Process from the Tools menu.)
b. In the Attach to Process dialog box, find the program you want to attach to from the Available Processes list.
i. If the program you want to debug is running on another machine, you must first select the remote machine. (For more information, see How to: Select a Remote Machine.)
ii. If the process is running under a different user account, check the Show processes from all users box.
iii. If you are connected through Remote Desktop Connection, check the Show processes in all session’s box.
c. In the Attach to box, make sure that either the type of code you will debug is listed or that Automatic: Managed code appears. If it doesn't:
i. Click Select.
ii. In the Select Code Type dialog box, click Debug these code types and select the types to debug.
iii. Click OK.
d. Click the Attach button.
e. You can be attached to multiple programs when you are debugging, but only one program is active in the debugger at any given time. You can set the active program in the Debug Location toolbar.
i. From the Debug menu, click Windows and choose Processes (if the Processes window is not already displayed).
ii. In the Processes window, double-click on the process you want to make active.
iii. On the Debug Location toolbar, select the Process list box and choose the process that you want to make current.
Appendix - General information and solution foor some common errors
1. How to open the IIS web application property page:
- Click the Web Sites node, and select the Web application's node. It will either be a Web site node, and thus a sibling of the Default Web Site node, or a virtual directory node underneath an existing Web site node.
- Right-click the Web application, and on the shortcut menu, click Properties.
2. How to: Find the Name of the ASP.NET Process
To attach to a running ASP.NET application, you need to know the name of the ASP.NET process.
a. If you are running IIS 6.0, the name is aspnet_wp.exe.
b. If you are running an earlier version of IIS, the name is aspnet_wp.exe.
c. For applications built using VS 2005, the ASP.NET code can reside on the file system and run under the test server WebDev.WebServer.exe. In that case, you need to attach to WebDev.WebServer.exe instead of the ASP.NET process. This scenario applies only to local debugging.
3. To run aspnet_wp.exe under a user account
Explains how to set up your machine so you can run aspnet_wp.exe under a user account
a. Open the machine.config file, located on your machine in the CONFIG folder under the path where you installed the runtime.
b. Find the
c. Save the machine.config file.
d. On Server 2003, IIS 6.0 is installed by default. The corresponding worker process is w3wp.exe.To run in IIS 5.0 mode with aspnet_wp.exe as the worker process, you must do the following steps:
1. From the Start menu, click Administrative Tools and then choose Internet Information Services.
2. In the Internet Information Services dialog box, right-click the Web Sites folder and choose Properties.
3. In the Web Sites Properties dialog box, choose Service.
4. Select Run WWW service in IIS5.0 isolation mode.
5. Close the Properties dialog box and Internet Services Manager.
e. Open a Windows Command Prompt and reset the server by running:
net stop iisadmin /y
net start w3svc
f. Find the Temporary ASP.NET Files folder, which should be in the same path as the CONFIG folder. Right-click the Temporary ASP.NET Files folder and choose Properties from the shortcut menu.
g. In the Temporary ASP.NET Files Properties dialog box, choose the Security tab.
h. Click the Advanced button.
i. In the Advanced Security Settings for Temporary ASP.Net Files dialog box, click the Add button.
k. In the Select User, Computer, or Group dialog box, enter the user name (in the form DomainName\UserName) in the Enter the object name to select box, and then click OK.
l. In the Permission Entry for Temporary ASP.NET Files dialog box, give the user Full Control, and then click OK to close the Entry for Temporary ASP.NET Files dialog box.
m. A Security dialog box will appear, asking if you really want to change the permissions on a system folder. Click Yes.
n. Click OK to close the Temporary ASP.NET Files Properties dialog box.
4. Determining if project code resides on the file system or IIS
- In Visual Studio 2005, open Solution Explorer if it is not already open.
- Select the top node that contains the name of the application.
- If the Properties window title contains a file path, the application code resides on the file system.
- Otherwise the Properties window title will contain the name of the Web site.
5. 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. Check the Integrated Authentication setting in the IIS Property Settings.
6. How to: Debug Web Applications on a Remote Server
With the Visual Studio debugger, you can debug a Web application transparently on the local machine or a remote server. This means that the debugger functions the same way and allows you to use the same features on either machine.
For remote debugging to work properly, however, there are some prerequisites.
- Visual Studio remote debugging components must be installed on the server you want to debug.
- By default, the ASP.NET worker process runs as an ASPNET user process. As a result, you must have Administrator privileges on the machine where ASP.NET runs to debug it.
- 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.
7. Error: The Web Server Could Not Find the Requested Resource
If you install URLScan, you may encounter this error if you don't configure the urlscan.ini configuration file properly. URLScan is an Internet Server API (ISAPI) filter that screens and monitors HTTP requests for IIS 4.0, IIS 5.0, and IIS 5.1. URLScan is used to reduce the exposure of IIS to potential Internet attacks.
By default, URLScan does not make special accommodations for file name extensions that ASP.NET Web applications use. You can change the URLScan configuration to add an extra layer of security for these applications. You must disable or enable different file name extensions for application level tracing, XML Web services, and remoting.
HOW TO: Configure URLScan to Protect ASP.NET Applications
To configure URLScan to enable standard ASP.NET file name extensions that users may requested, follow these steps:
- Install the URLScan tool. For information and instructions, visit the following Microsoft Web site: http://www.microsoft.com/technet/security/tools/urlscan.mspx
- Open the Urlscan.ini file in a text editor (such as Notepad). This file is located in the \System Root\System32\Inetsrv\Urlscan\ folder.
- In the [AllowExtensions] section, add the following file name extensions:
- In the [DenyExtensions] section, add the following file name extensions: • .asax
- To turn on application level tracing, add the .axd file name extension to the [AllowExtensions] section. If you do not want to turn on application level tracing, add .axd to the [DenyExtensions] section.
- To allow Web services, add the .asmx file name extension to the [AllowExtensions] section. If you do not want to allow Web services, add .asmx to the [DenyExtensions] section.
- To turn on remoting, add the .rem file name extension and the .soap file name extension to the [AllowExtensions] section. If you do not want to turn on remoting, add .rem and .soap to the [DenyExtensions] section.
- Save and then close the Urlscan.ini file. You must restart IIS for the changes to take effect.
If your application is running on IIS 6.0 on Windows Server 2003, you do not need to run the IIS Lockdown tool because IIS 6.0 provides the same functionality. You may decide not to install URLScan, since most of its functionality is also provided by IIS 6.0.
- ASP.NET automatically detects any changes to Web.config files and applies the new configuration settings. You do not have to reboot or restart the IIS server for changes to take effect.
- A Web site can contain multiple virtual directories and subdirectories, and Web.config files may exist in each one. ASP.NET applications inherit settings from Web.config files at higher levels in the URL path. Hierarchical configuration files allow you to change settings for several ASP.NET applications simultaneously, such as for all applications below it in the hierarchy. However, if debug is set in a file lower in the hierarchy, it will override the higher value.
- Enabling debug mode will greatly affect the performance of your ASP.NET application. Remember to disable debug mode before you deploy a release application or conduct performance measurements.