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

朱雀 2022-01-07 11:09 267阅读 0赞

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][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 ####

![Aa290100.vsdebug_fig01_28en-us_VS.71_29.gif][]

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

![Aa290100.vsdebug_fig02_28en-us_VS.71_29.gif][]

**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 ####

![Aa290100.vsdebug_fig03_28en-us_VS.71_29.gif][]

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

![Aa290100.vsdebug_fig04_28en-us_VS.71_29.gif][]

**Figure 4. Setting Internet Explorer Authentication**

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

![Aa290100.vsdebug_fig05_28en-us_VS.71_29.gif][]

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

![Aa290100.vsdebug_fig06_28en-us_VS.71_29.gif][]

**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. ####

![Aa290100.vsdebug_fig07_28en-us_VS.71_29.gif][]

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

![Aa290100.vsdebug_fig08_28en-us_VS.71_29.gif][]

**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. ####

![Aa290100.vsdebug_fig09_28en-us_VS.71_29.gif][]

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

![Aa290100.vsdebug_fig10_28en-us_VS.71_29.gif][]

**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. ####

![Aa290100.vsdebug_fig11_28en-us_VS.71_29.gif][]

**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 ... ####

![Aa290100.vsdebug_fig12_28en-us_VS.71_29.gif][]

**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. ####

![Aa290100.vsdebug_fig13_28en-us_VS.71_29.gif][]

**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. ####

![Aa290100.vsdebug_fig14_28en-us_VS.71_29.gif][]

**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 ``, you may not be able to debug the include file properly. You need to use ``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/][http_www.asp.net_Projects_Cassini_Download].

## General Debugging ##

These cases are based on **Console application** project type.

#### Message: Unable to start debugging. ####

![Aa290100.vsdebug_fig15_28en-us_VS.71_29.gif][]

**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. ####

![Aa290100.vsdebug_fig16_28en-us_VS.71_29.gif][]

**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` 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 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.

转载于:https://www.cnblogs.com/relang99/archive/2007/03/27/690106.html

[Introduction]: http://msdn2.microsoft.com/en-us/library/aa290100%28VS.71%29.aspx#vsdebug_topic1
[ASP.NET Debugging]: http://msdn2.microsoft.com/en-us/library/aa290100%28VS.71%29.aspx#vsdebug_topic2
[General Debugging]: http://msdn2.microsoft.com/en-us/library/aa290100%28VS.71%29.aspx#vsdebug_topic3
[Causality Debugging_ Stepping Between Web Service Client and Web Service]: http://msdn2.microsoft.com/en-us/library/aa290100%28VS.71%29.aspx#vsdebug_topic4
[Remote Debugging]: http://msdn2.microsoft.com/en-us/library/aa290100%28VS.71%29.aspx#vsdebug_topic5
[Aa290100.vsdebug_fig01_28en-us_VS.71_29.gif]: /images/20211223/f0355aeb37b244948cfba95c2f32c05a.png
[Aa290100.vsdebug_fig02_28en-us_VS.71_29.gif]: /images/20211223/fec688f196ff4d84be3123fa8aa3e06c.png
[Aa290100.vsdebug_fig03_28en-us_VS.71_29.gif]: /images/20211223/a1455a0f70b0479c8778325711805d6e.png
[Aa290100.vsdebug_fig04_28en-us_VS.71_29.gif]: /images/20211223/5209eda547724ad4bb30054892c5bd83.png
[Aa290100.vsdebug_fig05_28en-us_VS.71_29.gif]: /images/20211223/7ae4a9f7d7334e299b2f581af747a05c.png
[Aa290100.vsdebug_fig06_28en-us_VS.71_29.gif]: /images/20211223/0dc21f1537e047ff8856fc149c84c5b4.png
[Aa290100.vsdebug_fig07_28en-us_VS.71_29.gif]: /images/20211223/af9201cf52184259a9baa878c8dfa49f.png
[Aa290100.vsdebug_fig08_28en-us_VS.71_29.gif]: /images/20211223/79c492076525479694c18f80b1a6e471.png
[Aa290100.vsdebug_fig09_28en-us_VS.71_29.gif]: /images/20211223/e0e941856066494ba2dc5ca29eb6d54a.png
[Aa290100.vsdebug_fig10_28en-us_VS.71_29.gif]: /images/20211223/5d577decb3af41bd8a0ea091ddb5e4a8.png
[Aa290100.vsdebug_fig11_28en-us_VS.71_29.gif]: /images/20211223/ea8b045ecafc4be493d2de04242b553c.png
[Aa290100.vsdebug_fig12_28en-us_VS.71_29.gif]: /images/20211223/3c63db13c91f4a51abc6438fb40243f7.png
[Aa290100.vsdebug_fig13_28en-us_VS.71_29.gif]: /images/20211223/ca11584b47374b9cb3ab6d82ce2b35b6.png
[Aa290100.vsdebug_fig14_28en-us_VS.71_29.gif]: /images/20211223/7d31518a57b44864b0247e4d7b4b784b.png
[http_www.asp.net_Projects_Cassini_Download]: http://www.asp.net/projects/cassini/download/
[Aa290100.vsdebug_fig15_28en-us_VS.71_29.gif]: /images/20211223/80e2a450eac44cff982784a8d27d5767.png
[Aa290100.vsdebug_fig16_28en-us_VS.71_29.gif]: /images/20211223/e557ecbb07584dd194eee11ed27f7260.png