Using the Visual Studio .NET 2003 Debugger with ASP.NET Applications
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)
Contents
Introduction
ASP.NET Debugging
General Debugging
Causality Debugging: Stepping Between Web Service Client and Web Service
Remote Debugging
Introduction
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:
- Log in as Administrator.
- Run Computer management in Administrator tools.
- Choose the Local users and groups\groups node.
- Double-click the Debugger Users group in right pane.
- Click the Add button in the Debugger users properties dialog box.
- 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?");
try
{
}
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
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)
{
System.Threading.Thread.Sleep(1000);
}
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:
- Run Local Security Settings in Administrator tools.
- Select Security settings\Local policies\Security options.
- 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.
- 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.
