Visual Studio Remote Debugging Tips MS VS 2005

We have numerous situations at work where we need to debug issues at customer sites remotely. It is a huge hassle to install a development environment and source code and even source code control system at customer sites each time there is some hard-to-track crash or bug that we need to attend to.

Fortunately modern Visual Studio environment supports remote debugging. With the ubiquitous availability of VPNs this has became easier but there are still some challenges exist. I am sure that you have also been puzzled by why your system won't connect with the remote to begin a debug session, or get all sorts of different messages which all boil down to some connectivity and authentication issues.

I just got this to work (finally) with one of our customers using Visual Studio 2005 debugging environment. Both my system and the customer system was in different domains, so before I forget what hoops I had to jump through to get this going, I am going to document that here so that at least I can refer to this article myself.

I am sure that this is similar with 2008. We are using Windows XPs between the two.

The Most Important Gotcha Concept

The most important requirement for the remote debugging connection to work is the understanding of the following facts.

• It is a bidirectional communication and you cannot precisely control the user name and password for each way of the communication through the remote debugging tools. The logged-in user name and password should match on both remote and local debug environment. In other words, you want to log in to your local machine and the remote machine using exactly the same user name and password.


• You might say, other machine is in the domain and mine is not or likewise. But it does not actually seem to matter if the user name part (after the domain qualifier) and password pair is in the domain or not. The user name part and the password that goes with it must match on both ends.


• Note that if the user names are both in the domain and on the local system the password set in the domain will be used even if you are logged in as a local user. The interpretation of this is that "Administrator" should and cannot not be used in most sane situations since this is usually set by the domain's administrator and it would take an act of god to get the access to that password. But if you know what that is, change your local administrator's password as well as the local domain's password for the Administrator to get it to work. Not very advisable from the security stand-point though.

The Cookie Cutter Method

If remote debugging isn't working, at least some basic stuff going by creating some simple Hello World type app and use the following to see if you can connect and debug at all.

• On the LOCAL and REMOTE machine's user accounts, create the local user name account that DOES NOT exist in neither of the domains.


• Give that account the same password.


• Also it is best to edit C:\Windows\System32\Drivers\Etc\Hosts file and put each other system's WINS names and actual IP address. For example, if the remote machine is called XPWS1 then put that entry.

Other Stuff to Check

Windows firewalls may get in the way. I would temporarily turn this off while debugging the connection.

• The Local Security Settings (in Control Panel: Administrative Tools: Local Security Policy) must be tweaked on Windows XP as following. Go to Security Settings: Security Options: Network Access: Sharing and security model for local accounts. This must be changed to Classic - local users authenticate as themselves.