Remote debugging in Visual Studio works great if both machines are on the same domain and/or workgroup. It also works dreamily if you’re doing straight native C++ where you can use the TCP/IP as the debugging transport. The problem comes in when you need to do remote debugging for managed code across domains or workgroups. It doesn’t work because .NET remote debugging relies on DCOM, which as a transport protocol does not jump workgroup or domain boundaries.
When I have to remote debug across domain/workgroup boundaries, here’s what works for me. It’s not an ideal solution but until Microsoft allows us to debug .NET code with pure TCP/IP this will get you at least started. Again, your mileage may vary and your network admins may not let you perform the following so you’re on your own with these steps. Finally, I’m assuming you know how to set up remote debugging for the supported same domain/workgroup scenarios. If you don’t you should read the documentation to understand what I’m talking about here.
The issue with DCOM is there’s a security ramification where an account one domain does not have rights on the other workgroup or domain. The big trick is to do your remote debugging with local machine accounts. DCOM first attempts to make the connection with machineusername account and if that does not work, it falls back to the username using the hashed password. As long as the username and password on the both machines is the same, DCOM can make the connection.
On the machine where Visual Studio runs, called the local machine, open up an elevated command shell or PowerShell window with administrator rights and execute the following command. Yes, you can do the same through the GUI but this is much faster. Don’t fear the command line!
net user username
password /add
That creates the user account you’re going to use for Visual Studio.
On the machine where your application runs, called the remote machine, open up an elevated command shell or PowerShell window with administrator rights and execute the following commands. Obviously you’ll be using the same user name and password you entered on the local machine.
net user username
password /add
net localgroup administrators remotecomputernameusername /add
With the same computer accounts on both machines account life is easy. On the remote machine, you’ll need to login with the new account or if you’re logging in with a different account, use RUNAS.EXE to fire up MSVSMON.EXE like the following.
runas /user:remotecomputernameusername “<full path>msvsmon.exe”
With the remote debugging stub waiting for connections, you’ll need to start Visual Studio on the local machine with the account as well.
runas /user:localcomputernameusername “<full path>devenv.exe”
With both sides running with the same account and password, you’ll work around the DCOM bumps and get your remote debugging across domains and/or workgroups functioning. As I mentioned, this approach isn’t ideal because you’re now running Visual Studio in a different account so all your settings, extensions, and drive mappings aren’t there. The good news is that those are pretty simple to set up especially since you can export and import your Visual Studio settings.
One problem you’ll run into with this approach is when you need to attach to a process running with administrator rights.
The issue is that MSVSMON.EXE itself is not running with administrator rights. One option is to log into the machine with the local username, right click on MSVSMON.EXE in Explorer and choose “Run as administrator.” Another option, which I do instead, is to use my Elevate program that starts processes as an administrator at the command line. When I need MSVSMON.EXE running with administrator rights, I simply do the following.
runas /user:remotecomputernameusername “<full path>elevate <full path>msvsmon.exe”
Right now some of you are sitting there thinking that instead of creating the completely separate account to run everything in, why not just create a machine account on the remote machine that matches the name of the domain account you want to use? That seems to make sense, but you’ll have a small little problem. The DCOM connection only works one way and you’ll get an error.
While not a perfect solution, using machine accounts with the same usernames and passwords on both machines will at least let you do remote debugging. In some cases this may cause more trouble than it’s worth, but I thought it was worth mentioning the approach. One of these days full remote debugging with complete security will be built into the operating system. A boy can dream, right?