The VS7 Debugger doesn’t work. What can I do? (转)[@more@]RM language= script id=_ctl0_Form1 name=_ctl0:Form1 οnsubmit=ValidatorOnSubmit(); action=vs. x?ID=3695 method=post>

Resolving de ger problems

The VS7 Debugger doesn’t work. What can I do?:namespace prefix = o ns = "urn:schemas--com::office" />

By to:mkpark@microsoft.com" rel="nofollow">mkpark@microsoft.com (Visual Debugger QA team)

Introduction. 1

Debugging. 2

Message: Unable to start debugging on the server 2

Message: You do not have pession to debug the server 2

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

Message: The project is not configured to be debugged. 4

Can start debugging without error message, but breakpoints are not hit. 5

Message: The debugger is not proy installed. 6

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

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

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

Message: Access is denied. 7

Can’t debug with an included File. 8

General Debugging. 8

Message: Unable to start debugging.  Unable to start program …... 8

Message: Unable to start debugging. Access is denied. 8

Can start Managed debugging, but P is not loaded. So, can’t hit any Breakpoints at all. 8

Managed debugging is not working. 9

Managed debugger doesn’t respond. 9

Step with code is not correct…... 9

Causality debugging: Stepping between web service client and web service. 10

Can’t set from web service client into web service. 10

After enabling impersonation of web service, can’t do causality stepping. 10

Debugger hangs. 11

Remote debugging. 11

Can’t see any processes on a remote machine. 11

Can’t connect to a remote machine because of RPC issue. 11

Remote debugging fails with machines on a work group. 12

During the last several months, I have dealt with many users from both inside and outside of Microsoft who have debugging issues. I noticed that there are many common mistakes and problems that can be solved, if users are provided with proper diagnosis. Hence, I’ve written this document to provide you with this information which will help you if you run into any issues while using the debugger.

 

This document contains:

• Error message dialog or description of error situation
• The causes for error
• How to fix the problem.

And I especially thanks to VCS debugger team and other people who helped me to complete this document with various feed back.

Debugging issues

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

Your application of IIS is not configured to use “integrated authentication”. Please make sure that the “integrated windows authentication” checkbox on the “authentication method” dialog box is checked.

Message: You do not have permission to debug the server

• Cause 1: Make sure that “Integrated Windows Authentication” is enabled. Probably, you enabled only “Basic authentication” for Directory security of IIS. 
• 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.ainname.something”), the web site is recognized as “Internet” site. So the default setting of will impact on the behavior of log on. In this case, you need to enable logging on with your current user account in “Internet” area with IE setting.
  But it is not the default setting of IE, so you’d be better off if you create project with only the machine name.

 

 

Cause 1: Your web application doesn’t have an Application name. Please check the properties of the web project using the IIS MMC to ensure that your web project has an application name

 

You need to create an application name for debugging.

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

 

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 may find this file in your web project folder.

You started debugging with “F5” and it looks like debugging is started properly, and IE is launched properly. But you can’t hit a breakpoint on my code behind code.

Cause 1: Please make sure that “asp.net debugging” is enabled in the properties of project.

 

In the case of 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.

 

If you see this problem, please check debugging with console application project. And if the console application project shows the error message like

 

It means that your is not installed properly. So you need to register “mrdbi.dll” manually by executing “regsvr32 mscordbi.dll”.  

 

If you have an Pro or W2K Pro machine, you may need to think about the order of installation between VS7 and IIS. If you install IIS after VS7, you will get this error. In this case, please register “aspnet_is.dll” with “aspnet_regiis.exe –i”.

 

You may not be the member of “Debugger users” group on the machine. Please add your user account into “Debugger users” group on the machine.

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 “Local users and groupsgroups” node

4.  Double-click “Debugger users” group on right pane.

5.  Click “Add” button on “Debugger users properties” dialog box.

6.  Type your user account and click “Ok” button.

 

You may have installed “IIS Lockdown” tool. If so, Please find “urlscan.ini” file, and add “DEBUG”(case sensitive) into “[allowverbs]” section in “urlscan.ini” file.

 

You may be the member of “Debugger users” group, but you don’t have the right to debug the aspnet worker process, because you are not the “aspnet” user account or the member of “Administrators” group. Please add your user account to the “Administrators” group on the machine.

Inside of , you can't debug with an included file. It may easily happen, when you convert old ASP project to ASPX.

If you include file with "", you may not be able to debug the include file properly. In this case, you need to use "".

These cases are based on “Console application” project type.

 

You can’t start debugging because “mscordbi.dll” is not registered properly. Please register it manually.

 

Please make sure that “Machine Debugger Manager” service is started properly.

Please check that you are the member of “Debugger users” group or “administrators” group.

If you can start debugging and debuggee 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. So you need to register it manually.

To register it, you need to do

1. find out “diasymreader.dll”
2. regsvr32 diasymreader.dll

You attach to native process in CLR mode before the process creates the CLR . 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.

When you start debugging with managed code, the debugger doesn’t respond at all.

Please make sure that the “.Net framework support” service is stopped and disabled forever. (just stopping the service is not enough.)

If you don’t have “.Net framework support” service, Please disable “IIS admin” service. It may help you.

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" statment, the instruction pointer is moved to the body("Console.WriteLine("what's up?");") of the "if" statement. This is not debugger bug, it is known issue with try catch block debug information. See the followingdiembled code

if(someStr == null) 0000002a  cmp  d 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 "3c" line, but the line is mistakenly matched with the body of "if" statement. While the code functions correctly, the appearance is incorrect.

With the default settings, you can’t step from 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 via DCOM. So you need to add these accounts into the “Debugger users” group.

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 clinet code to set credential to like   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 web service, some framework components need to use the system level debugger component (MDM) to cocreate it. If you don't give your proper credentials, it just fails to do the "cocreation". Without these the proper credentials, "step into" works like "step over"

If your web service client code is running in STA(Single thread Apartment) model, and it is waiting for an async call completion like:

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 debugger

Solution 1:

Change your code to use thread sync with event or mutext.

Solution 2:

Unregister “csm.dll”. In this solution, it will disable causality stepping (stepping from web service client code to web service method). You may need to attach to “aspnet_wp.exe” manually for debugging web service.

Can’t see any processes on a remote machine.

Please make sure that you installed “Remote full debug” setup on the remote machine, and that you are a member of “debugger users” group.

* this information is from one of KB articles. Thanks for “Mike Clay” who wrote this KB.

If you see the below 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 see the below, 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.

Please make sure that RPC is working properly between your machine and the remote machine. the reason of RPC issue can be from

1. Debugging through a . 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.

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

3. 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 succesully debug remotely. Make sure that RPC communication is enabled

  in both directions.

To analyze your RPC, you can use “RPCPing” tool.

You have two 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 remote machine at all. What’s wrong with it?

In the work group environment, you need to make sure that you have the same

named user account on both machines with the same password. If not, Dwill fail to authenticate you.

There is one more consideration:

On XP Pro, because of the default security setting for "sharing and security model for local accounts", this remote debugging is not allowed by default.  Below are the steps to change this setting:

  1.  Run "Local Security Settings" in Administrator tools.

2.  "Security settingsLocal policiesSecurity 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.  After this, you need to reboot the machine.

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

After you make the setting change, you will be able to do remote debugging with the same name user account on both machines.

However, ***there is a concern with security with this change***.  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 should setup network-Island for the debugging machines to prevent any malicious attack.

posted on Tuesday, March 11, at 11:13 PM dotnetweblogs.com/Rosherove/Services/Pingback.aspx" rel=pingback> --&gt

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10748419/viewspace-975034/，如需转载，请注明出处，否则将追究法律责任。