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

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

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

[/code]
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)
{
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 theweb

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.