Remote Debugging

Remote debugging allows you to connect to a running application on another machine or domain and debug that application in its environment. This is often the only way to experience errors that are occurring on specific hardware. We’ve all heard this developer’s cry: “Works on my machine.” Remote debugging helps those developers figure out why their application doesn’t work in other environments.

Remote debugging makes a lot of sense in various scenarios, such as debugging SQL server-stored procedures, web services, web applications, remote services or processes, and so on.

The hardest part about remote debugging is getting it set up properly. The actual debugging is no different from the debugging we’ve discussed thus far. However, the setup requires you to jump through a lot of hoops in terms of installation and security. These hoops are necessary because you do not, by default, want developers to easily connect debug sessions to applications on your servers.

There is some good news. Visual Studio tries to minimize and simplify the setup and configuration of remote debugging. Microsoft has written the Remote Debugging Monitor (msvsmon.exe) for this purpose. However, developers still find the setup tasks somewhat arduous (but rewarding when finished). We do not cover the setup in great detail here because it is often environment specific. We suggest querying MSDN for “Remote Debugging” to get the full walk-through and troubleshooting advice for your specific situation.

We do offer the following, however, as a set of high-level tasks that you need to complete to get remote debugging working:

1. Install the remote debugging monitor (msvsmon.exe) on the remote machine being debugged. You install it using the setup application, rdbsetup.exe. You can also run it from a file share. You need to select the version that matches the version of Visual Studio you are using and the type of processor on the remote device (x86, x64, ARM).

2. Configure remote debugging permissions. Typically, this means one of two things. First, you can set up identical accounts (username and password) on both machines (debugging and server). The debugging account may be a local or a domain account. However, the server account should be a local account. Second, you can give your user account administrative access to the machine being debugged, but this is often a security risk that you shouldn’t take lightly.

3. Run the remote debugging monitor on the remote machine. This is a Windows application (with a GUI). You can also set the monitor to run as a Windows service. This capability can be useful for specific server scenarios and ASP.NET remote debugging.

4. If your debug machine is running XP with SP2, you have to configure your security policy and firewall for remote debugging. (See the MSDN documentation “How to: Set Up Remote Debugging.”) If you are running Windows 7 or 8+, you might have to elevate privileges when running Visual Studio (run as Administrator).

5. Run Visual Studio on your debug machine as you would to debug any process. Open the project that contains the source for the process you want to debug.

6. Attach to the running process on the remote machine using Attach to Process. You have to browse to the machine you want to debug and find the process running on that machine.

As you can see, getting remote debugging set up can be a challenge. However, if you have a test environment that you typically debug, the setup should be a one-time operation. From there, you should be able to debug in a more realistic environment as well as walk through SQL-stored procedures.