Remote Debugging into an Isolated Lab Environment

by John 11. October 2011 20:04

As part of correcting issues in an isolated lab environment, it is often necessary for developers to connect to one or more machines within the isolated network.  While the concepts of remote debugging are pretty straight forward, I decided to go ahead and put together something that our developers could use as a guide to perform those types of activities.  Our codebase is 100% managed code, for whatever reason, it is more difficult to get attached and debugging across domains with managed code than it is with Native code.  Honestly, I don't understand why that is, but it can be a bit frustrating unless you fully understand how to get such an environment configured properly.

The first thing you need to do is install the Visual Studio Remote Debugging tools (x86 or x64) on the target machine.  The install is pretty straight forward, so I won't go into that directly.  We actually include the remote debugging monitor (MSVCMON) as part of our base lab images.  In our case we don't configure the tool to run as a service, instead, we place a short cut on the desktop so that it can be started when needed.

Once of the key aspects of remote debugging is that you have to use the same user account on your developer machine, as well as the target machine.  This means Local Accounts on both machines.  So the first step is to create a local account on your desktop, lets call it "Remote.Debugging" for our purposes.  This account doesn't necessarily need to be in any special local groups.  Create the same user name and password on the target machine.  This time, however, you need to put the account in the target machines Administrators group (the local administrators group, not the domains).

Once you have the accounts created, you need to update the permissions in the Visual Studio 2010 Remote Debugger. Once opened, use Tools->Permissions and add the account as part of the security.  Below is a screen shot of what you should see when you do this.

 

 

Now you are ready to attach and debug, should the need arise. Notice that the user signed into the desktop is from the isolated domain called "LAB", and the user name is Lab.Administrator.

When you need to debug, simple hold the shift key down and right-click on the Visual Studio 2010 Remote Debugger Icon on the desktop, you will get a pop up menu that looks something like this:

 

Notice that there is a option for 'Run as Different User'.  Select that, and you are presented with a credentials pop up window as follows:

  

 

It is important that you enter the local machine name in the windows credential dialog (because the account is local to this machine. A little known shortcut is that you can use the "." as the machine name for local accounts.

  

 Once you have successfully authenticated, you will have a Monitor window like the one below.  Notice that the user name now indicates Remote.Debugging@LabDesktop01.

 

 

This means that you are now ready to connect from Visual Studio.  On your workstation, follow the same process, hold the shift key down and right-click on the visual studio shortcut, you will see a pop up menu like this

 

 

 As before, select Run as Different user.  When prompted enter the credentials of the local account 'Remote.Debugging'.  If this is the first time you are performing this procedure, you will be asked the various initial-setup questions, such as your default environment settings, etc.

Generally, I open the solution that has the executable that I am debugging so that I have access to all of the source code within the environment.  If you are opening a project that is corrected to TFS, you will get a pop up asking you for your TFS credentials.  This is normal because you are running as the local user you created. Once you have opened the solution, and are ready to attach, select Debug->Attach to Process.

Enter the machine name (you know the long with that starts with LAB_), or the IP Address and press enter.  Once attached, within visual studio, you will get to select the process.

 

 

 You can select the "Show processes from all users" checkbox to see the other processes.  Once you find your process select it and click Attach.  Notice that the "Attach to" field currently indicates Automatic: Native Code; If you have connected as outlined here, this will change when you select your process to whatever is suitable.  Over in the Lab, the Visual Studio Remote Debugging monitor shows this

 

 

 Notice that both screens show that you are attaching as the user created specifically for this purpose.

And now a brief word about security...  Since many organizations have multiple developers, I recommend that you disable the account you created on your developer workstation until you need it for debugging.  This helps prevent unauthorized access to your computer.

 

 

Tags: , ,

Debugging

About the author

I am a software Entrepreneur, I always have been. I spend my days developing cool new software for several customers, mostly in the Justice space. I have been developing software for clients since I was 14 (I got addicted young). I am always up for a new challenge.

I love the bleeding edge; I have lots of battle scars to prove it.  I spend all of my extra time reading, researching and pushing the limits. Some call me a work-a-holic, to which I respond that there are not enough hours in the day to learn everything I want to know.  Some might say I am forever on a knoweldge quest.

Month List