Export (0) Print
Expand All

Using the Visual Studio .NET 2003 Debugger with ASP.NET Applications

Visual Studio .NET 2003

Min Kwan Park
Visual C# Debugger QA Team
Microsoft Corporation

April 2005

Summary: Debugging ASP.NET can be difficult because the configuration and interplay of accounts can cause breaks at a number of different steps. This article outlines the more commonly seen problems associated with debugging ASP.NET applications, shows examples of the errors, and explains how to fix them. (14 printed pages)


ASP.NET Debugging
General Debugging
Causality Debugging: Stepping Between Web Service Client and Web Service
Remote Debugging


During the last several months, I have worked with many users, both internal and external to Microsoft, who have had debugging issues. I noticed there are many common mistakes and problems that can be solved if users are provided with a proper diagnosis. Hence, I've written this document to provide you with the information that will help you resolve your issues while using the debugger.

This document contains:

  • Error message dialog or description of the error situation.
  • The causes for said error.
  • Resolution for said problem.

I would like to thank the VCS debugger team and other people who helped me write this article and provided me with excellent feedback.

ASP.NET Debugging

Note   If you can't find the error message that you're looking for in this section, please check the section that deals with general debugging issues or remote debugging issues.

Message: Unable to start debugging on the Web server

Figure 1. Unable to start debugging error message

Cause 1: Your IIS application is not configured to use Integrated Windows Authentication. Make sure that the Integrated Windows Authentication checkbox on the Authentication Method dialog box is checked, as shown in Figure 2.

Figure 2. Enabling Integrated Authentication

Cause 2: Check the Enable HTTP Keep Alive option of IIS. If it is turned off, you may need to turn it on and try your debugging again.

Message: You do not have permission to debug the server

Figure 3. No Permissions to Debug

Cause 1: Make sure that Integrated Windows Authentication is enabled. The likely cause is that only Basic authentication for Directory security of IIS is enabled.

Cause 2: If you are using Integrated Windows Authentication, you need to make sure that your user account has full control on the directory of the IIS.

Cause 3: If you created the Web project with a full machine name (like machinename.domainname.something), the Web site is recognized as Internet site. So, the default setting of Internet Explorer will impact on the behavior of logging on. In this case, you need to enable logging on with your current user account in "Internet" area with the IE setting.

However, this is not the default setting of Internet Explorer, so you're better off creating a project with only the machine name and using Figure 4 as a guide for your Security Settings.

Figure 4. Setting Internet Explorer Authentication

Message: Server side-error occurred on sending debug HTTP request.

Figure 5. Server-side Error During Debugging

Cause 1: Your Web application doesn't have an Application name. To remedy this situation, check the properties of the Web project using the IIS MMC to ensure that your Web project has an application name. Your application name should appear where the red outline appears in Figure 6.

Figure 6. Setting Application Name

Cause 2: If you are using the NTFS file format, make sure that "aspnet" has proper privilege on "wwwroot" or your folder for virtual directory to access and write on the folders.

Message: The project is not configured to be debugged.

Figure 7. Project not configured for debugging

For this error message, you need to make sure that your Web is configured for debugging. To do this, you need set debug = true in the web.config file. You can find this file in your Web project folder.

You can start debugging without error messages, but breakpoints are not hit.

You started debugging using F5 key and it looks like debugging is started properly, and Internet Explorer is launched properly, but you can't hit a breakpoint on my code behind code.

Cause 1: Asp.net debugging is not enabled in the properties of project. Set this item to True as shown in Figure 8.

Figure 8. Enabling ASP.NET Debugging

In the case of VB project, the UI is different, but you can recognize the equivalent one easily.

Cause 2: Please make sure that the expected DLL is loaded with matched debug symbol file. You can check it with Modules window.

Message: The debugger is not properly installed.

Figure 9. The debugger is not properly installed

If you see this problem, check the debugging feature with in the Console Application project. If the console application project shows the error message like Figure 10, it means that your .NET Framework application is not installed properly.

Figure 10. Unable to start debugging

You need to register "mscordbi.dll" manually by executing "regsvr32 mscordbi.dll".

Message : The server does not support debugging of ASP.NET or ATL server applications.

Figure 11. Unable to start debugging

If you have a Windows XP Pro or Windows 2000 Pro installed on your machine, you may need to think about the order of installation between Visual Studio 7 and IIS. If you install IIS after Visual Studio 7, you will get this error. In this case, register "aspnet_isapi.dll" with "aspnet_regiis.exe –i".

Message: Access is denied. Verify that you are an administrator or a member of ...

Figure 12. Access is denied

You may not be the member of Debugger Users group on the machine. Add your user account into Debugger Users group on the machine to resolve this error.

To add your user account into Debugger Users group, you need to do the following:

  1. Log in as Administrator.
  2. Run Computer management in Administrator tools.
  3. Choose the Local users and groups\groups node.
  4. Double-click the Debugger Users group in right pane.
  5. Click the Add button in the Debugger users properties dialog box.
  6. Type your user account and click OK.

Message: Could not start ASP.NET or ATL server debugging.

Figure 13. ASP.NET or ATL not installed

Cause 1: You may have installed the IIS Lockdown tool. If so, find the urlscan.ini file, and add DEBUG(case sensitive) into the [allowverbs] section.

Cause 2: If you are using Domain controller as your server, and your project is created using a machine name rather than a full domain name, you may need to change the URL of the project to use full domain name.

Cause3: If your IIS is set to use dedicated IP as Web site identification(you can find this option in IIS setting with IIS MMC), you may see this error message. In this case, you need to change your project name to use the IP address directly. For existing projects, you need to change project to use the IP address rather than the machine name by editing .sln file and .webinfo file.

Cause4: The value in <httpRuntime maxRequestLength="#########" /> in the web.config file is too large. The default unit is Kbyte, not byte, so if you changed this number and used the wrong unit, it may cause debugging problems.

Message: Access is denied.

Figure 14. Access is denied

Cause: You may be a member of the Debugger Users group, but you don't have the permissions to debug the aspnet worker process because you are not the aspnet user account or the member of Administrators group. Add your user account to the Administrators group on the machine to resolve this issue.

Can't debug with an included File

Inside of ASPX, you can't debug with an included file. An included file can often result when you convert old ASP projects to ASPX.

If you include files with <!--#include file = "file name"-->, you may not be able to debug the include file properly. You need to use <!--#include virtual="file name"-->instead.

After changing your password, you need to log off/log in for ASP.NET debugging.

After you change your password, you need to log off and log back on to do ASP.NET debugging properly.

After installing Windows2000 SP4, ASP.NET debugging doesn't work and it says "Access denied".

The resolution for this issue is to re-register aspnet_isap.dll with regsvr32 –i aspnet_isap.dll.

You only hit breakpoint the first time the page is loaded.

There may be several different causes for this particular problem, but the most likely cause is that you have the page cache option set in the web.config file.

If you see something like <add key="<your web project name".Web.EnablePageCache" value="True" /> in web.config, you need to set the value to "False" to turn off the Web page cache. After changing this setting and refreshing the page, you should be able to hit breakpoint.

You Need to share a Web server for debugging but don't want to let other users be admin on the machine.

In Visual Studio .NET, there are two things that determine if a user can debug. One is the Debugger Users group, and the other is user privilege, such as administrator, power user, or SEDebug.

The Debugger Users group determines if the user can access the VS debug component (mainly MDM-Machine Debug Manager, which is part of Visual Studio), so being a member of the group means that you are guaranteed for accessing MDM. So at this point, you can debug your open process and see the list of process on your machine.

But after this, whether you can debug other user's process is decided by your privilege. For example, if you want to debug other people's native process, you should have SEDebug privilege. For the other users' Managed process, you should be administrator on the machine.

Because of this restriction, in your scenario, the student should be granted as admin. If not ASP.NET work process can't be debugged by default.

We have a sort of work-around. Cassini is stand-alone small ASP.NET server. So for students, they can use Cassini for developing things, and later they just need to deploy thing over to the actual server for submit the result. The Cassini is available on http://www.asp.net/Projects/Cassini/Download/.

General Debugging

These cases are based on Console application project type.

Message: Unable to start debugging.

Figure 15. Unable to start program

The issue causing the error shown in Figure 15 is caused by mscordbi.dll not being properly registered. Register the file manually to remedy this problem.

Message: Unable to start debugging. Access is denied.

Figure 16. Access is denied error message

Ensure that Machine Debugger Manager service is started properly and that you are a member of Debugger Users or "Administrators.

I can start Managed debugging, but PDB does not load, and I can't hit any Breakpoints.

If the debugger is launched properly, but you couldn't hit any BP, you may need to check the installation of diasymreader.dll. The file may not be registered. To register it, you need to do:

regsvr32 <path to DLL>\diasymreader.dll

Managed debugging is not working

You attach to native process in CLR mode before the process creates the CLR object. Managed debugging is not working.

Solution 1: Attach to the process after CLR code is used in the process.

Solution 2: Attach to the process in InterOp mode. In this case, you don't have to attach to the process after CLR code is invoked.

Managed debugger doesn't respond

When you start debugging with managed code, the debugger doesn't respond.

Solution: Make sure that the .NET Framework Support service is stopped and disabled (stopping the service is not enough).

If you don't have .NET Framework Support service running, disable the IIS admin service.

Stepping with C# code is not correct

Consider the following code:

string someStr; 
someStr = "SomeValue"; 
if(someStr == null) 
    Console.WriteLine("what's up?"); 

catch(Exception e) 

If you step through this code, you will see that when you step into the "if" statement, the instruction pointer is moved to the body(Console.WriteLine("what's up?");) of the "if" statement.

This is not a debugger bug, but it is known issue with try catch block debug information. See the following disassembled code for an example of a try catch block in the debugger.

if(someStr == null) 
0000002a  cmp         dword ptr [ebp-18h],0 
0000002e  jne         0000003C 

Console.WriteLine("what's up?"); 
00000030  mov         ecx,dword ptr ds:[01C50070h] 
00000036  call        dword ptr ds:[02F0257Ch] 
0000003c  jmp         00000048 

catch(Exception e) 
0000003e  mov         dword ptr [ebp-1Ch],eax 
00000041  call        762C0846 
00000046  jmp         00000048 

00000048  nop       

When the value is not matched, the instruction pointer is moved to 0000003c  jmp         00000048 line, but the line is mistakenly matched with the body of the "if" statement. While the code functions correctly, the appearance is incorrect.

Causality Debugging: Stepping Between Web Service Client and Web Service

Can't set debugging from the Web service client into a Web service

The default settings do not allow you to step from a Web service client into a Web service. It works like step-over.

The ASPNET worker process (aspnet_wp.exe or w3wp.exe) is running under the "aspnet" or "network service" user accounts, and these accounts don't have privilege to access MDM through DCOM. So, you need to add these accounts into the Debugger Users group.

After enabling impersonation of Web service, you can't do causality stepping.

When impersonation is enabled for the web service with "web.config", stepping into from web service client code to web service code is not working. So it works like step over.

You need to do these things for correct stepping between client and service.

  • Turn off Anonymous access in IIS.
  • change your client code to set credential to the Web service like so:
    Service1 obj = new Service1(); 
    obj.Credentials =  System.Net.CredentialCache.DefaultCredentials; 

After this, you will be able to step into the Web service from client.

These are needed, because when you step into the Web service, some .NET Framework components need to use the system level debugger component (MDM) to co-create it. If you don't give your proper credentials, it fails at this step. Without these the proper credentials, "step into" works like "step over".

Debugger hangs

If your Web service client code is running in a STA (Single Thread Apartment) model, and it is waiting for an async call completion like the following:

Service1 obj = new Service1(); 
System.IAsyncResult ar = obj.BeginHelloWorld(new System.AsyncCallback(Class1.Handle),obj); 
while(ar.IsCompleted != true) 

The debugger will hang. This hang occurs because one debugger component is locked by your code inside of the debugger. Solution 1 is to change your code to use thread sync with event or mutex. The other solution is to unregister csm.dll. The second solution disables causality stepping (stepping from Web service client code to Web service method). You may need to manually attach to aspnet_wp.exe for debugging the Web service.

Remote Debugging

Can't see any processes on a remote machine

Make sure that you installed Remote full debug setup on the remote machine, and that you are a member of the Debugger Users group.

Can't connect to a remote machine because of RPC issue

The following information is from a KB article written by Mike Clay.

If you see the following error messages while you are connecting to remote machine with "Processes" dialog:

Error while trying to run project: Unable to start debugging on the

web server. Not enough storage is available to complete this operation.

Or, you this message during ASP.NET debugging:

Error while trying to run project: Unable to start debugging on the web

server. Unable to map the debug start page URL to a machine name.

Ensure that RPC is working properly between your machine and the remote machine. The following can cause RPC issues:

  • Debugging through a firewall. Microsoft does not recommend or support remote ASP.NET debugging through a firewall. The best way to do overcome this is use Terminal Services to log into the remote server and debug locally.
  • One common failure for RPC is the inability to resolve the remote machine name. RPC relies on name resolution for communication between machines. If you are unable to resolve the remote servers machine name to the correct IP address errors may occur.
  • RPC traffic can flow in one direction but not the other. RPC traffic must be able to go from the machine used to do the debugging to the remote server and from the remote server back to the machine used to do the debugging in order to successfully debug remotely. Make sure that RPC communication is enabled in both directions.

To analyze your RPC, you can use the RPCPing tool.

Remote debugging fails with machines on a work group

This occurs when you have two Windows XP Pro machines that are not on a domain, but on a work group. When you do remote debugging between them, you can't access the remote machine at all.

In the work group environment, you need to make sure that you have the same user account name on both machines with the same password. If not, DCOM will fail to authenticate.

Also, on Windows XP Pro, the default security setting for Sharing and security model for local accounts is set to now allow sharing. Below are the steps to change this setting:

  1. Run Local Security Settings in Administrator tools.
  2. Select Security settings\Local policies\Security options.
  3. Change Network access : Sharing and Security model for local accounts from Guest only - local users authenticate as Guest to Classic - local users authenticate as themselves.
  4. Reboot the machine.

This change should be applied to both machines for remote debugging.

After you make the setting is changed, you will be able to do remote debugging with the same name user account on both machines. Please make sure that your user accounts on each machine has password. In some cases, without actual password it doesn't work.

However, because you changed default settings of the security model, it can expose:

  • Unexpected file sharing
  • Unexpected DCOM components sharing.

Before you make this change, any kind of connection from remote machine to your machine was guaranteed as Guest, but after this change, he/she could be authenticated with your local user account. So, like the case of debugging, if you are sharing out a folder or DCOM object, there is a possibility that any matched user (same user name and same password) on other machine could access your shared objects.

I strongly recommend that if you want to use this work-around, you make sure that all user accounts have strong passwords, or you should setup a network-island for the debugging machines to prevent any malicious attacks.

Related Books

© 2014 Microsoft