Sweet sorrow... remote debugging (and more)

Continuing from my previous post on common causes for memory leaks, remote debugging is another ASP.NET feature that has the potentiality to either delight (uhm... am I exaggerating here...? ) a web developer or drive him completely crazy
I remember 8-9 years ago, when I was a young technology passionate learning the basics of web development (HTML, CSS, ASP etc...), on my desk I just had a couple of programming books for beginners, my dial-up modem to download some online manuals and my copy of Office 97 for students. My editors at that time were FrontPage 97 and Notepad... so all I could do to debug my web pages were to use lots of Response.Write() to inspect variable values, and lot of brain work to try to understand where things were going wrong...

With ASP.NET and Visual Studio .NET in these days developers still have to do lot of brain work, but for sure the tools now help a lot with debugging web applications... but what happens if the debugger has tantrums?
Here is a list of the common debugger problems I saw so far in my experience with Microsoft Support; this is not at all a comprehensive list, you can find out more doing some research in MSDN, Knowledge Base or your favorite search engine.

"Unable to start debugging on the web server"

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
2. Check whether “Enable HTTP Keep Alive” option in IIS is checked or not. If it is turned off, you may need to turn it on and try your debugging again

"You do not have permission to debug the web server"

1. Make sure that “Integrated Windows Authentication” is enabled. Probably, you enabled only “Basic authentication” for Directory Security in IIS
2. If you are using “Integrated Windows Authentication”, you need to make sure that your user account has full control on the application directory
3. If you created the web project with a full machine name like http://machinename.domainname.appname, Internet Explorer will recognize it as part of the Internet Zone, so the security settings for this security zone will impact your application and the logon type. In this case you need login with your current account also in the Internet security zone in IE: go to menu Tools -> Internet Options -> Security tab -> select the Internet zone -> click the Custom Level... button, scroll down the list of settings until you find User Authentication -> enable Automatic logon with current username and password

"The project is not configured to be debugged"

Make sure your application is configured to be debugged; to do this check that your web.config file contains the instruction debug="true".
NOTE: please remember to set this to debug="false" when you deploy your application in production! See this and this.

"The server does not support debugging of ASP.NET or ATL server applications"

You may need to think about the order of installation between Visual Studio and IIS; If you install IIS after Visual Studio you will get this error. In this case you need to register the ASP.NET mappings in IIS with “aspnet_regiis.exe –i” from the .NET Framework installation folder (choose the version you want to restore).

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

Quite self explanatory...

"Could not start ASP.NET or ATL server debugging"

1. If you have installed the IIS Lockdown tool, find the urlscan.ini file and add "DEBUG" (case sensitive) into “[allowverbs]” section
2. If your web server is also a domain controller and you created your project using the full domain name, you may need to change the URL of the project
3. 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 the “.sln” and the “.webinfo” file
4. If you modified the value “<httpRuntime maxRequestLength="#########" />” in your web.config, 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

"Access is denied"

To be able to attach to the ASP.NET worker process your account must be part of the "Debugger users" group and be an Administrator of the remote machine; as an alternative you can configure your ASP.NET worker process to run under the same account you'll use to logon on on your development machine.

Remote debugging fails with machines on a workgroup

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, otherwise 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", remote debugging is not allowed by default. Here 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

Make sure that your user accounts on each machine has password. In some cases, without actual password it doesn’t work. This change should be applied on both machines for remote debugging now you should be able to remotely debug your application.

However, there is security concern about this: because you changed default settings of the security model, it can expose:

• Unexpected file sharing
• Unexpected DCOM components sharing

By default any kind of connection from the remote machine to your machine was guaranteed as "Guest", but after this change new connections could be authenticated with your local user account. So, like in 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 machines 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.

Update (30/03/2007)
I'm not sure when this was published, but here is an interesting list of common debugger errors and solutions

Cheers
Carlo