The Visual Studio 2002, Visual Studio 2003 or Visual Studio 2005 Debugger doesn’t work. What can I do?

By Min Kwan Park( mkpark@microsoft.com / Visual Studio Diagnosis QA team)

Introduction

 

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 Visual Studio Diagnosis team and other people who helped me to complete this document with various feed back.

 

Also, please don't hesitate to contact me for new issues or any other comments. I’ll be happy to work with you to improve this document.

 

BTW, if you are looking for VS8.0 Beta1 related issues, please check “Known issues with VS8 Beta1“ article.

 

Debugging issues

ASP.NET Debugging

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

 

Message: Unable to start debugging on the web server

 

Error while trying to run project: Unable to start debugging on the web server. Would you like to disable future attempts to debug ASP.NET pages for this project?

 

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

 

 

Case 2: Please check whether “Enable HTTP Keep Alives” option of IIS is checked or not. If it is turned off, you may need to turn it on and try your debugging again.

 

Case 3: if you see “0x8013134b” error code on output window, you may have two different versions of CLRs. In that case, you need to register “aspnet_isap.dll” from the CLR which is matched your VS version. 

 

Message: You do not have permission to debug the server

 

Error while trying to run project: Unable to start debugging on the web server. You do not have permissions to debug the server.

 

Verify that you are a member of the ‘Debugger Users’ group on the server. Would you like to disable future attempts to debug ASP.NET pages for this project?

 

 

  • 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.domainname.something”), the web site is recognized as “Internet” site. So the default setting of IE 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 4:  If your Devenv(7.1) is on Window2K3 and has remote server, in this case, you may add the remote machine into trusted site list. however the default security setting of trusted site in IE is using “Automatic logon only in Intranet Zone“. so you may see this error. if so, you want to change Logon option to “Automatic logon with current username and password“.  However to be more secured, you may want to change the option back after debugging.
  • Cause 5:

    When you use the fully qualified domain name (FQDN) or a custom host header for a local/remote web site that is hosted on a computer that is running Microsoft Internet Information Services (IIS) 5.1 or IIS 6 and debugged using VS .NET 2003 and you recently installed Windows XPSP2 or Windows Server 2003 SP1, you may receive an error message as above.  you can try belowWindows XP SP2 and Windows Server 2003 SP1 include a loopback check security feature that is designed to help prevent reflection attacks on your computer. Therefore, authentication fails if the FQDN or the custom host header that you use does not match the local computer name.

  • Method 1: Disable the loopback check

  • Follow these steps:

  • 1. Click Start, click Run, type regedit, and then click OK.

    2. In Registry Editor, locate and then click the following registry key:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

    3. Right-click Lsa, point to New, and click DWORD Value.

    4. Type DisableLoopbackCheck, and then press ENTER.

    5. Right-click DisableLoopbackCheck, and then click Modify.

    6. In the Value data box, type 1, and then click OK.

    7. Quit Registry Editor, and then restart your computer.

     

     

    Method 2: Specify host names

    To specify the host names that are mapped to the loopback address and can connect to Web sites on your computer, follow these steps:

    1. Click Start, click Run, type regedit, and then click OK.

    2. In Registry Editor, locate and then click the following registry key:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0

    3. Right-click MSV1_0, point to New, and click Multi-String Value.

    4. Type BackConnectionHostNames, and then press ENTER.

    5. Right-click BackConnectionHostNames, and then click Modify.

    6. In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.

    7. Quit Registry Editor, and then restart your computer.

     

 

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

 

Error while trying to run project: Unable to start debugging on the web server. Server side-error occurred on sending debug HTTP request.

 

Make sure the server is operating correctly. Verify there are no syntax errors in web.config by doing a Debug.Start Without Debugging. You may also wan to refer to ASP.NET and ATL Server debugging topic in the online documentation.

Would you like to disable future attempts to debug ASP.NET pages for this project?

 

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 “wwwroot” or your folder for virtual directory to access and write on the folders.

Message: The project is not configured to be debugged.

 

Error while trying to run project: Unable to start debugging on the web server. The project is not configured to be debugged.

 

For ASP.NET projects, verify that you have a valid project file called ‘Web.config’ for the URL specified and ‘debug’ is set to ‘true’ in that file

For ATL server projects, verify that the ‘DEBUG’ verb is associated with your ISAPI extension.

Would you like to disable future attempts to debug ASP.NET pages for this project?

 

 

Case 1: 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.

 

Case 2: For VS7.1, if you see this error message, check whether in IIS you have the Default Website mapped to a static IP address and NOT All Unassigned. If so, please create project with “http://<IP address>” than “http://<server name>”.

However in this case, you need to make sure that the IP address is trusted site list and automatic log on is enabled for trusted site.

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

 

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 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: You do not have privileges to debug the web server process.

 

When doing ASP .NET debugging on Windows Server 2003/ Windows XP/Windows 2000 using VS .NET 2003 you might see this error message:

 

"Error while trying to run project: Unable to start debugging on the
web server. You do not have privileges to debug the web server
process. Contact an Administrator to get the debug privileges on the
server. You may also want to refer to the ASP.NET and ATL Server
debugging topic in the online documentation."

 

If you see this problem, please check two things below

  1. Add “Administrators” to the “Debug Programs” in Local policy as follows: From Administrative Tools open the Local Security Policy snap-in for
    Microsoft Management Console. Open the Local Policies node and then
    the User Rights Assignment node. Open the properties of the "Debug
    Programs" policy. It should have the Administrators group and
    the VUSR_yourcomputername user in the list. If not, add them and save
    the properties. Then close the Microsoft Management Console. After updating the policy reboot the machine.
  2. If the web site is created using the full machine name, the following option in IE needs to be set for either the internet zone/intranet zone depending on where the machine is OR http://fullmachinename can be added to trusted sites and the following property set on the trusted sites zone: Bring up IE ->Tools -> Internet Options -> Security Tab. Choose Internet/Intranet/Trusted Sites based on the above. Click on Custom Level and go to the end of the dialog box. Set the option under User Authentication -> Logon to “Automatic logon with Current Username and password”. Click OK and Click OK.

 

Message: The debugger is not properly installed.

 

Error while trying to run project: Unable to start debugging on the web server. The debugger is not properly installed. Run setup to install or repair the debugger. Would you like to disable future attempts to debug ASP.NET pages for this project?

 

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

 

 

Error while trying to run project: Unable to start debugging.

 

Unable to start program’<the path of your debuggee>’

 

The debugger is not properly installed. Run setup to install or repair the debugger.

 

It means that your .Net framework is not installed properly. So 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.

 

Error while trying to run project: Unable to start debugging on the web server. The server does not support debugging of ASP.NET or ATL Server applications. Run setup to install the Visual Studio .NET server components. If setup has been run verify that a valid URL has been specified.

 

You may also want to refer to the ASP.NET and ATL Server debugging topic in the online documentation. Would you like to disable future attempts to debug ASP.NET pages for this project?

 

If you have an XP 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_isapi.dll” with “aspnet_regiis.exe –i”.

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

 

Error while trying to run project: Unable to start debugging.

 

Access is denied, Verify that you are an administrator or a member of the ‘Debugger  Users’ group on the machine you are trying to debug. After being added to the “Debugger Users” group, you must log off and log back on for the setting to apply.

 

Case 1:

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 groups\groups” 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.

 

Case 2:

If you machine has XP SP2 or W2K SP4, make sure that “SEImpersonate” is allowed to ‘aspnet” user account.

  1. Open local security policy control panel from admin tools
  2. See Local policy\user right assignment\impersonate a client after authentication and add "aspnet" into the list.

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

 

Error while trying to run project: Unable to start debugging on the web server. Could not start ASP.NET or ATL Server debugging.

 

Verify that ASP.NET or ATL Server is correctly installed on the server. Would you like to disable future attempts to debug ASP.NET pages for this project?

 

Case 1: 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.

 

Case 2: if you are using Domain controller as server, and your project is created with machine name than full domain name, you may need to change the URL of project to use full domain name.

 

Case3: 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 project, you need to change project to use IP address than just machine name by editing “.sln” file and “.webinfo” file.

 

Case4: if you do change the value “<httpRuntime maxRequestLength="#########" />” in “web.config”, please make sure that the value is not too big. The default unit is “Kbyte”, not “byte” so if you put too big number, it causes problem with debugging.

Message: Access is denied.

 

Error while trying to run project: Unable to start debugging on the web server. Access is denied. Would you like to disable future attempts to debug ASP.NET pages for this project?

or

Error while trying to run project: Unable to start debugging on the web server. Access is denied.

 

case 1: 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.

 

case 2: You need to make sure that your user account is admin or same user account of ASP.NET worker process. currently CLR debugging service has security restriction to allow only admin or same user to debug managed process. so unless you are admin or same user, you can't debug ASP.NET worker process(W3wp.exe on IIS6-Windows 2003 or Aspnet_wp.exe on other OSes). if you can't be admin on the server box, but you have Windows 2003 server, you have a work-around by using separate app-pool.  the detail information is on section 6.2 of http://msruniv.corp.bcentral.com/shared%20documents/dotNETDevSvrDEVELOPER2003.doc document.

Can’t debug with an included File

Inside of ASPX, 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 "<!--#include file = "file name"-->", you may not be able to debug the include file properly. In this case, you need to use "<!--#include virtual="file name"-->".

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 in to do ASP.NET debugging properly.

 

After installing Windows2000 SP4, ASP.NET debugging doesn’t work and it says “Access denied”.

After Windows 2000 SP4, if you ASP.NET debugging doesn’t work by pressing “F5” and it says “Access denied”, please re-register “aspnet_isap.dll” with “regsvr32 –i aspnet_isap.dll”. it will fix the problem.

 

Can hit breakpoint only when the page is loaded first time.

There may be several different cases of this problem. but one of well known cases is that you may turn on page cache option in “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 as “False” to turn off web page cache. It will let you hit breakpoint when you refresh the page.

 

Need to share web server for debugging but I don’t want to let other users to be admin on my machine.

In VS.Net, we have two things to decide whether user can start debugging. One is “Debugger users” group and the other is user privilege like administrator or power user or SEDebug.

Debugger users group decide whether the user can access VS debug component (mainly MDM-Machine Debug Manager- which is part of VS). So being the member of debugger users 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/.

 

Message: No managed code is running..(7.1)

 

When start ASP.NET debugging:

Error while trying to run project: Unable to start debugging on the web server. There is no managed code running in the process. In order to attach to a process with the .NET debugger, managed code must be running in the process before attaching. 

 

When do any managed code debugging:

Error while trying to run project: Unable to start debugging

Unable to start program <path of debuggee>

The .NET debugger has not been installed properly. The most probable cause is that mscordbi.dll is not properly registered. Click Help for more information on how to repair the .NET debugger.

 

If you installed VS7.0 and VS7.1 together and uninstall VS7.0 and you can't do ASP.NET debugging with the error message, you need to repair the installation of 1.1 CLR. it will solve your problem.

General Debugging

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

 

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

 

Error while trying to run project: Unable to start debugging.

 

Unable to start program ‘<path of your debuggee>’

 

The debugger is not properly installed. Run setup to install or repair the debugger.

 

 

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

Message: Unable to start debugging. Access is denied

 

Error while trying to run project: Unable to start debugging.

 

Access is denied verify that you are an administrator or a member of the ‘Debugger users’ group on the machine you are trying to debug. After being added to the ‘Debugger Users’ group, you must log off and log back on for the setting to apply.

 

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.

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

 

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

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

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" 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 followingdisasembled code


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 "3c" line, but the line is mistakenly matched with the body of "if" statement. While the code functions correctly, the appearance is incorrect.

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

Can’t set from web service client into web service

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.

 

After enabling impersonation of web service, 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 clinet code to set credential to webservice 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"

 

Debugger hangs

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.

 

Remote debugging

Can’t see any processes on a remote machine

 

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.

 

Can’t attach to a process launched with runas command(VS2005)

 

When a user attaches to a process has been started using “runas” in the console session on Win 2003 he gets an “Access Denied” error using v8.0. The bug is to do with the process enumeration API we used in v8.0.

 

The workaround is to launch the process under debugger instead of attaching (disable the Visual Studio Hosting process if the process is managed).

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

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

 

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

   in both directions.

 

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

 

Remote debugging fails with machines on a work group

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, DCOM will 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.              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.              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.

Please make sure that your user accounts on each machine has password. In some cases, without actual password it doesn’t work.

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.

After installing Windows XP SP2, Remote debugging doesn't work.

Windows XP SP2 has better firewall system. and by default it disable remote debugging. If you want to do remote debugging with Windows XP SP2 system, please check http://msdn.microsoft.com/security/productinfo/xpsp2/default.aspx?pull=/library/en-us/dnwxp/html/xpsp2remotedebug.asp link for more information. it has instructions to enable remote debugging with Windows XP SP2 and VS7.0/7.1.