Cross Domain Remote Debugging

Remote debugging can be a task on it's own, but after the first time you've done it, it becomes second nature. This blog will take remote debugging a step further and explain step by step how to easily debug across domains.

Set Up Your VPN

In Network Connections, use the "Create a new connection" wizard to set up the VPN.

You want to VPN into the same domain that your remote server is on. So for me, I found the IP address of the domain controller and connected to that.

When prompted for a username and password, use an account that is both a member of the domain and is part of the local Administrators group of the machine you are remotely debugging.

Placing the PDBs

General rule of thumb is that you want to put your PDBs directly next to their assemblies. While it's possible to follow that rule for assemblies that are in the GAC, it's much easier to put it in the "C:\Windows\Symbols\dll" folder. As usual, your PDBs must be built with the DLLs that you're using. If they aren't, nothing will work. Also, in the case of IIS, simply replacing the assemblies in the GAC will not force your web application to pick up the new assemblies. You will need to either recycle your app pool or simply do an iisreset.

Setting up Remote Debugging

There are a few ways to prepare your machines for remote debugging. If you plan on doing it more often than just this one time, I suggest you download and install Visual Studio to your remote machine. You'll then be able to install the Visual Studio 2008 Remote Debugger service which can be set to start on login. Then, you'll never have to think about it again.

If this is just a quick test, copy the appropriate Remote Debugger from your local Visual Studio box to the remote machine. See this MSDN article to find out where those files are located: How to: Set Up Remote Debugging. You need to copy all of the files in that directory so in the case of x86 remote debugging, copy the entire x86 directory over to your remote machine. Mine were located here:

   1: C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x86

Starting the app will look something like this:

Make a note of the quoted server name. You will need that next.

On your Local Machine

On your local machine, open up Visual Studio and choose "Debug > Attach to Process". Before you type in the server name into the Qualifier box, click "Select..." next to the "Attach to:" field. Check the code types you would like to debug and click OK.

Next, enter the Qualifier (this is the server name from before). It should look something like this: username@server. Hit Enter and wait.

If everything else went well, you will see a list of available processes for you to attach to.

Which process one do I pick?

You can select multiple processes if you're not sure which one is hosting your code. In the case of web applications, there can be multiple w3wp.exe processes available and it's nearly impossible to know which one applies. My only warning is this: do NOT select too many or you will have to wait for the polar ice caps to melt before your machine breaks free from Visual Studio's hold.... well, maybe that's a bad example.

Enjoy

This process can be a bit painful, but like "regular" remote debugging, it's not that bad the second time around. Fortunately, the result is well worth the work. Even though I've found it to be a little flaky, most of the regular Debugging features work as expected: Immediate Window, Intellisense, Break Points, Call Stack, etc.