This blog has been on my todo list forever. I am now sitting in an airport, so I guess it is time for the procrastination is over… I want to talk about remote debugging in the following network situations:
But first an introduction.
Introduction to remote debugging security
In VS 2005, remote debugging works by having Visual Studio communicate with the Remote debugging monitor (msvsmon.exe). All communication is authenticated and communication goes both ways. This means that it is not only important what user runs Visual Studio, but it is also important what user runs msvsmon.exe.
To be able to connect to msvsmon, Visual Studio must either be run as the same user as msvsmon, or must be run as an administrator. You can also configure msvsmon to accept connections from other users.
Visual Studio will accept the connection from msvsmon as long as msvsmon is run as a user that can authenticate with the Visual Studio computer.
The main event
Regardless of what situation you are in, you need to get the user account running Visual Studio to map to a user account on the Msvsmon machine, and you need to get the user account running msvsmon to map to a user account on the Visual Studio machine. The way you do this is to create a local user account on both computers with the same user name and password. If you need to run msvsmon as a different user then Visual Studio, then you will need to create two user accounts on each computer.
If you have one of the machines on a domain, it should be noted that a domain account can map to a local account. However, I haven't yet found a way for a local account to a domain account. What this means is that you will still have to create a local user account on both computers, but as long as you pick the same user name and password as your domain account, you can still run Visual Studio as a domain account.
For Windows XP machines on a workgroup, another concern is a security option entitled 'Network security: Shared and security model for local accounts'. This can be configured via the 'Local Security Policy' administrative tool. If this option is set to 'Guest only – local users authenticate as guest', then remote debugging is not going to work. This is not a problem for computers running Windows 2000, Server 2003, or Windows XP computers that are joined to a domain.
Lastly, if one or both computers are on a domain with IPSEC policy, you may have to work around that as well. I am not an expert on IPSEC, but I no have one suggestion – if you connect from the domain to the workgroup computer first, then connections going the other way might start working.