Visual Studio can be used to debug processes remotely, using the MSVSMON agent. This can be used for both native code and managed code. However, for successfully debugging managed code applications, symbol files have to be correctly loaded – and for that to happen, they must be in the correct place.

Prerequisites

For remote debugging of managed code to work correctly, the pre-requisites are:

1. The Default transport needs to be used in Debug-Attach to process
2. Firewall exceptions both ways
3. Symbols need to be accessible from MSVSMON (target) – see note below
4. Source will still be loaded on the client machine

 

Symbol locations

It is very important to keep in mind that VS.NET never loads mismatched symbols. So it is our responsibility to ensure matched PDBs are made available at one of the following locations on the remote machine:

• At the location where the EXE is
• On the path we specify in the VS.NET symbols dialog
• _NT_SYMBOL_PATH
• %SystemRoot%

Setup

Here is a schematic of the typical setup. Here, VS.NET acts as a controller, talking to MSVSMON (the remote debugger agent) which actually attaches to the process being debugged.

 

An additional challenge in our case is that the client and server are actually in different domains. To work around this issue, we create identically named local users (call it VSUSER) in the client and on the remote server. The password for this user is also kept the same on both machines. This technique is sometimes referred to as passthrough authentication or mirrored accounts.

Ready to roll

On the server and on the client, we now launch sessions logged in as VSUSER. You could also use the RUNAS command to obtain CMD prompts which are running as VSUSER. That will be used to launch the following:

1. On the client side, we will launch DEVENV (VS.NET IDE) running as VSUSER
2. On the server side, we will launch MSVSMON running as VSUSER
3. On the server side we will launch the Windows application (running as any user.)

Next, we deploy the remote debugger, MSVSMON, which is found at the location C:Program Files (x86)Microsoft Visual Studio 10.0Common7IDERemote Debuggerx64. When you install and run this on the server side, you will most probably be prompted to unblock firewall ports:

The next step is to use the Debug-Attach to process menu on the client to discover the processes on the remote machine.

Permissions

If you try to remote debug a process which is not launched under the VSUSER identity, you may get this error message:

 

To fix this issue, add VSUSER to the local administrators group on the server, and run MSVSMON as administrator (due to UAC). Once this is done, reattach to the process, you should get the following warning, and then you should be able to continue.

 

Summary

Remote debugging of managed processes (even those which are launched under another identity) is very much possible, as long as you use the Default transport, ensure authentication, keep communications open and most importantly – ensure that symbols are on the target at one of the locations specified in my above post. You can then resolve the source line numbers, and debug interactively!

 

Further Reading

How to- Run the Remote Debugging Monitor – Microsoft Corporation

Visual Studio 2008 – Remote Debugging with MSVSMON.EXE

That’s it for now! Please rate this post and leave your comments – much appreciated!