Asp. NET debugging problems and solutions

asp.net| Solve | The problem

From MSDN:

Asp. NET Debugging.

Note If you do not find the error message you want in this section, review the section on handling the general debugging issues or the remote debugging issues.

Message: Unable to start debugging on the Web server.

Figure 1. Failed to start debug error message

Reason 1: The IIS application is not configured to use integrated Windows authentication. Make sure the Integrated Windows authentication check box in the Authentication Method dialog box is selected, as shown in Figure 2.

Figure 2. Enabling Integrated authentication

Reason 2: Check the Enable HTTP Keep Alive option for IIS. If it is turned off, you may need to turn it on, and then try debugging.

Message: You do not have permission to debug the server.

Figure 3. No Debug permissions

Reason 1: Make sure integrated Windows authentication is enabled. The possible reason is that Basic authentication is enabled only for Directory security for IIS.

Reason 2: If you are using integrated Windows authentication, you need to make sure that your user account has full control of the IIS directory.

Reason 3: If you create a Web project with a complete machine name (such as Machinename.domainname.something), the Web site is recognized as an Internet site. Therefore, the default settings for Internet Explorer will have an impact on the logon behavior. In this case, you need to use the current account to enable logon in the Internet area with the IE settings.

However, this is not the default setting for Internet Explorer, so it is a good idea to use only the machine name to create the project, using Figure 4 as a guide to security Settings.

Figure 4. Setting up Internet Explorer authentication

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

Figure 5. Server-side errors during debugging

Reason 1:web application has no application name. To do this, use the IIS MMC to check the properties of the Web project to ensure that the Web project has an application name. The application name should appear when the red outline in Figure 6 appears.

Figure 6. Setting the application name

Reason 2: If you are using the NTFS file format, make sure that "ASPNET" has the appropriate permissions on the "Wwwroot" or virtual directory folder to access and write to these folders.

Message: The project is not configured to accept debugging.

Figure 7. Project is not configured for debugging

If this error message occurs, you need to configure the Web for debugging. To do this, you need to set debug = True in the Web.config file. This file is located in the Web project folder.

You can start debugging without an error message, but you cannot reach a breakpoint.

You started debugging with the F5 key and it looks as if debugging was started correctly and Internet Explorer was started correctly, but you can't reach a breakpoint in code-behind code.

Reason 1: ASP.net debugging is not enabled in the project properties. Set the key to True as shown in Figure 8.

Figure 8. Enable ASP.net debugging

In a VB project, the UI is different, but you can easily identify the equivalent.

Reason 2: Make sure that the expected DLL is loaded with a matching debug symbol file. You can check this by using the Modules window.

Message: The debugger is not installed correctly.

Figure 9. Debugger not installed correctly

If you see this problem, check the debugging features in the Console application project. If the console Application project displays an error message as shown in Figure 10, the. NET Framework application is not installed correctly.

Figure 10. Unable to start debugging

You need to manually register "MSCorDbi.dll" 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 installed Windows XP Pro or Windows Pro on your machine, you might want to consider the order of installation between Visual Studio 7 and IIS. This error occurs if IIS is installed after Visual Studio 7. In this case, use "aspnet_regiis.exe–i" to register "Aspnet_isapi.dll".

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

Figure 12. Access Denied

You may not be a member of the Debugger Users group on this computer. You can resolve this error by adding your user account to the Debugger Users group on your computer.

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

1.

Log on as an Administrator.

2.

Run the Computer management in the Administrator tools.

3.

Select the Local Users and Groups\groups node.

4.

Double-click the Debugger Users Group in the right pane.

5.

Click the Add button in the Debugger Users Properties dialog box.

6.

Type the user account and click OK.

Message: Unable to start asp.net or ATL server debugging.

Figure 13. asp.net or ATL not installed

Reason 1: You may have installed the IIS Lockdown tool. If so, locate the Urlscan.ini file and add DEBUG (case sensitive) to the [AllowVerbs] section.

Reason 2: If you use a domain controller as a server and your project is created with a machine name (a non-complete domain name), you may need to change the project's URL to a full domain name.

Reason 3: If you set up IIS to use private IP (such as Web site identification, you can find this option in IIS settings in IIS MMC), you may see this error message. In this case, you need to change the project name and use the IP address directly. For an existing project, you need to change the project to use the IP address instead of using the machine name by editing the. sln file and the. webinfo file.

Reason 4:web.config the value in the file is too large. The default units are kilobytes, not bytes, so if you change this number and use the wrong units, you may cause debugging problems.

Message: Access was denied.

Figure 14. Access Denied

Reason: You may be a member of the Debugger Users group, but you do not have permission to debug the ASPNET worker process because you are not a member of the ASPNET user account or Administrators group. You can resolve this problem by adding your user account to the Administrators group on the machine.

Unable to debug with file included

In ASPX, you cannot debug with a file that is included. When converting an old ASP project to ASPX, it often results in including files.

If you include a file, you may not be able to debug the included file correctly. You need to use it instead.

After you change your password, you need to log off/log in for ASP.net debugging.

After you change your password, you need to log off and then log in to properly asp.net debugging.

After you install Windows2000 SP4, asp.net debugging cannot run, and the message "Access Denied" is displayed.

The workaround for this problem is to re-register the Aspnet_isap.dll using Regsvr32–i aspnet_isap.dll.

Breakpoints are only encountered when the page is first loaded.

There may be several reasons for this particular problem, but the biggest possibility is that you set the page caching option in the Web.config file.

If you see something similar in web.config, you need to set the value to "False" to close the Web page cache. After you change this setting and refresh the page, you may experience a breakpoint.

You need to share a WEB server for debugging, but you don't want other users to be computer administrators.

In Visual Studio. NET, the following two can determine whether a user can debug. One of these is the Debugger Users group, and the other is user rights, such as Administrator, Power User, or Sedebug.

The Debugger Users group determines whether a user can access the VS Debug component (primarily part of Mdm-machine debug manager,visual Studio), so being a member of the group means guaranteeing access to MDM. So at this point, you can debug the open process and view the list of processes on the machine.

After that, however, you can debug the process of another user depending on your permissions. For example, if you want to debug someone's local process, you need to have Sedebug permissions. For another user's managed process, you should be the Administrator on the machine before you have permission to debug.

Because of this limitation, you should grant student administrator permissions in your scenario. Otherwise, the ASP.net worker process cannot be debugged by default.

We have a workaround. Cassini is a stand-alone, small ASP.net server. For students, they can use Cassini for development and later deploy their development results to the actual server to submit results. Cassini is located in http://www.asp.net/Projects/Cassini/Download/.

Back to the top of the page

General debugging

These cases are based on the Console application project type.

Message: Failed to start debugging.

Figure 15. Unable to Start program

The cause of the problem shown in Figure 15 is that the MSCorDbi.dll is not registered correctly. The remedy for this problem is to manually register the file.

Message: Failed to start debugging. Access was denied.

Figure 16. Deny access to error messages

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

I can start managed debugging, but the PDB does not load and no breakpoints are encountered.

If you start the debugger correctly, but you cannot encounter any breakpoints, you may want to check the installation of Diasymreader.dll. The file may not be registered. To register the file, you need to do the following:

regsvr32 \diasymreader.dll

Managed debugging is not running

Connects the local process in CLR mode before the process creates the CLR object. Managed debugging is not running.

Solution 1: Use CLR code in the process to reconnect the process.

Solution 2: Connect the process in InterOp mode. In this case, you do not have to connect to the process after invoking the CLR code.

The managed debugger does not respond

When you start debugging with managed code, the debugger does not respond.

Solution: Make sure that the. NET frameworksupport service is stopped and disabled (it is not enough to stop the service only).

If the. NET Frameworksupport service is not running, the IIS Admin service is disabled.

Using C # code to step through debugging is incorrect

Consider the following code:

String Somestr; Somestr = "somevalue"; if (somestr = = null)   Console.WriteLine ("What ' s up?"); try {} catch (Exception e) {}

If you use this code, you see that the instruction pointer moves to the "if" Statement Body (Console.WriteLine ("What's Up?");) when the "if" statements are encountered.

This is not a debugger bug, but a well-known try catch block debugging information problem. See the disassembly code for the try Catch block sample in the following debugger.

if (somestr = = null) A CMP        DWORD ptr [ebp-18h],0 e jne        C Console.WriteLine ("What ' s Up");  mov        ecx,dword ptr ds:[01c50070h]  call       dword ptr ds:[02f0257ch] C jmp        catch (Exception e) e mov        DWORD PTR [ebp-1ch],eax  call       C0846  jmp        }  NOP      

When the value does not match, the instruction pointer moves to the 0000003C jmp line, but the row has been incorrectly matched to the "if" statement body. When the code function is correct, the display is not correct.

Back to the top of the page

Causal debugging: Steps between a Web service client and a Web service

Unable to set debug from Web service client to Web service

The default setting does not allow access to Web services from Web service clients. It runs in a similar way to Step-over.

The ASPNET worker process (aspnet_wp.exe or w3wp.exe) runs under the "ASPNET" or "Network Service" user account, and these accounts do not have access to MDM through DCOM. Therefore, you need to add these accounts to the Debugger Users group.

After you enable WEB service impersonation, you can no longer use causal steps.

When you use "Web.config" to enable impersonation for a Web service, you cannot enter Web service code from Web service client code. Because, it works like step over.

You need to do the following to correct the steps between the client and the service.

•

Turn off Anonymous access in IIS.

•

Change the client code and set the credentials as a Web service, as follows:

•

Service1 obj = new Service1 ();

•

Obj. Credentials = System.Net.CredentialCache.DefaultCredentials;

After that, you will be able to access the WEB service from the client.

These actions are required because some. NET Framework components need to be created together using a system-level debugger component (MDM) When you enter a WEB service. If the correct credentials are not available, this step will fail. Without these correct credentials, the "step in" operation will resemble "step over."

Debugger Hangs

If the Web service client code runs in the STA (single Thread Apartment) model, and it waits for the asynchronous call to complete, as follows:

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 pending operation occurs because the code in the debugger has locked a debugger component. Solution 1 is to change the code to use a thread that synchronizes with the event or mutex. Another solution is to unregister csm.dll. The second solution disables causality steps (steps from Web service client code to Web service methods). You may need to manually connect aspnet_wp.exe to debug a Web service.

Back to the top of the page

Remote debugging

Unable to view any processes on the remote machine

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

Unable to connect to remote machine due to RPC problem

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

If you see the following error message when you connect to the remote machine through the Processes dialog box:

Error while trying to run project:unable to start debugging on the Web server. Not enough storage are available to complete this operation.

Or you see this message during asp.net debugging:

Error while trying to run project:unable to start debugging on the webserver. Unable to map the debug start Page URL to a machine name.

Ensure that RPC runs correctly between your machine and the remote machine. The following behavior can cause an RPC problem:

•

Debug through the firewall. Microsoft does not recommend or support remote asp.net debugging through a firewall. The best way to resolve this problem is to use Terminal Services to log on to the remote server and debug locally.

•

A common fault with RPC is the inability to resolve remote machine names. RPC relies on name resolution to communicate between computers. If the remote server machine name cannot be resolved to the correct IP address, an error may occur.

•

RPC traffic can only flow one-way, but not in the other direction. RPC traffic must be able to reach the remote server from the machine used for debugging and return the machine for debugging from the remote server for successful remote debugging. Ensure that RPC traffic is enabled in a bidirectional manner.

To analyze RPC, you can use the RPCPing tool.

The machine in the Remote debugging workgroup failed

This occurs when both of your Windows XP Pro machines are not in the domain but are in the workgroup. You cannot access a remote machine at all when you are debugging between them remotely.

In a workgroup environment, you need to make sure that both machines have the same user account name and the same password. Otherwise, DCOM will fail when authenticating.

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

1.

Run the local security Settings in the Administrator tool.

2.

Select the Security settings\local Policies\Security option.

3.

Change the network access:sharing and security model for local accounts from guest only-local users authenticate as guest to Clas Sic-local users authenticate as themselves.

4.

Restart your computer.

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

After you change the settings, you can use a user account with the same name to debug remotely on both machines. Make sure that the user account on each machine has a password. In some cases, no actual password machine cannot run.

However, because the default settings for the security model are changed, the following may be exposed:

•

Unexpected file-sharing

•

Unexpected DCOM component share.

Before making this change, any kind of connection from the remote machine to your machine is performed as a Guest, but after the change, he/she can accept authentication using the local user account. Therefore, in a debug case, if you share a folder or DCOM object, any matching user (with the same user name and the same password) on the other machine may have access to your shared object.

I strongly recommend that if you want to use this workaround, make sure that all user accounts have strong passwords, or you should set up a network island to debug your machine to prevent malicious attacks.