Remote Debugging from Visual Studio 2010

By on

Leave a comment

In my latest project I was running into an issue where running my installed application on a test machine was crashing before it could even startup, but it ran perfectly when installed on my machine. I was almost to the point of taking the time to install Visual Studio 2010 on the test machine, when my coworker, Bryan Coon, reminded me of the Remote Debugging capabilities of VS and recommended trying that first.

I started off using Danny Warren’s Remote Debugging post to get both my machine(on domain) and the test machine(off domain) enabled so that I could Attach to Process (Ctrl+Alt+P) from VS 2010 on my machine. Here are the main points that I gathered from it:

  • 3 instances of the same username needed to exist as administrators (and have been logged into at least once)
    1. The domain username on my machine (domain\travis). This is the username that Visual Studio is run under.
    2. The machine username on my machine (MyMachine\travis)
    3. The machine username on the test machine (TestMachine\travis). This is the username that the remote application is run under.
  • The Visual Studio 2010 Remote Debugging Monitor needed to be installed on the test machine
    • Use the setup program that matches the OS (x86, x64, ia64)
    • I ran the application instead of setting it up as a service, so I needed to make sure it ran as an administrator
  • Everything from the bin\Debug folder of the application must be copied to the test machine.

Once the Remote Debugging Monitor was started, I was able to view all the running processes in VS by entering the name of the server that the Remote Debugging Monitor started (travis@TestMachine) into the Qualifier box.

In most cases this would have allowed me to then attach to my running application and hit debug points. My application, however, crashed before the application even became available in the list of available processes.

So the next step was to get Visual Studio 2010 configured on my machine to start the application on the remote (test) machine when I started the application with debugging (F5). I found what was needed here. All that was required was to modify the following properties in the Debug section of the application properties screen:

  • Select Start external program and specify the path to the application on the remote computer
  • Check Use remote machine and specify the remote machine

The gotcha I ran into was that again the remote machine name is the server name that the Remote Debugging Monitor started not the actual machine name.

With these final steps completed I was able to start the application with debugging and immediately found my issue. While this process took a little bit of time to setup, it saved a bunch of time that would have been spent installing Visual Studio 2010 and allowed me to keep the test machine clean of all developer tools. So if I run into an issue like this again I will definitely think to try Remote Debugging right away.

Remote Debugging

By on

3 Comments

Recently we’ve been developing an application that runs on a Win7 PC and has a slimmed down version that runs on Win7 Tablets. In our case we’re using the HP Slate. Our development machines are running Win7 and VS2010. The development machines are on our domain while the HP Slates are not. The project has been going for some months now and we’ve been relying heavily on logging using Enterprise Library to know what errors we’re up against. However, we all know that as the complexity of an application increases so does the likelihood that we may log incorrect, useless, or unrelated data. Enter the need for remote debugging. I thought this would be straightforward and easy but I was very much mistaken.

Getting Ready to Remote Debug
I started on the (MSDN http://msdn.microsoft.com/en-us/library/y7f5zaaa.aspx) in the section (How to: Set Up Remote Debugging http://msdn.microsoft.com/en-us/library/bt727f1t.aspx). Here I learned that firewalls and permissions are the first huge hurdle called out by Microsoft. I must say when it comes to limited time firewalls are out. So instead of fighting my way through setting up firewalls to work correctly I just disabled them for all machines involved for this remote debugging session. Later in this same article it tells how to install the software required for the remote machine in order to debug remotely. There is broken link to the download center for the software required, but the optional location is on the VS2010 installation media in the folder (VS Media)\Remote Debugger. Be sure to install the correct version on the remote machine. Instructions for this are in the article.

Running the Remote Debugging Monitor
STOP! Why? Because you really should figure out which users you’re going to use on both the VS2010 host machine and the remote machine before trying to run the Debugging Monitor.
Selecting the Appropriate User Accounts for Remote Debugging
I tried to remote debug at this point and found there is one more piece of information that I was missing. Going back to the list of articles on the (MSDN http://msdn.microsoft.com/en-us/library/y7f5zaaa.aspx) the next important section is (Remote Debugging Across Domains http://msdn.microsoft.com/en-us/library/9y5b4b4f.aspx). This section lists the restrictions relating to user accounts right away. I will copy the first section here for review:
To connect to msvsmon, you must run Visual Studio under the same user account as msvsmon or under an administrator account. (You can also configure msvsmon to accept connections from other users.)
Visual Studio accepts connections from msvsmon if msvsmon is running as a user who can be authenticated on the Visual Studio computer. (The user must have a local account on the Visual Studio computer.)
With these restrictions, remote debugging works in various scenarios, including the following:

  • Two domains without two-way trust.
  • Two computers on a workgroup.
  • One computer on a workgroup, and the other on a domain.
  • Running the Remote debugging monitor (msvsmon) or Visual Studio as a local account.

Therefore, you must have a local user account on each computer, and both accounts must have the same user name and password. If you want to run msvsmon and Visual Studio under different user accounts, you must have two user accounts on each computer.

You can run Visual Studio under a domain account if the domain account has the same name and password as a local account. You must still have local accounts that have the same user name and password on each computer.

End Quote.

We will cover the last part in detail since that is the scenario I was faced with. In simple terms if your domain is named us and the user account is danny (us\danny) then the VS2010 hosting machine must have a local user account named danny with admin privileges with the same password as the us\danny account. Also, the remote machine, in my case the HP Slate, must have a local user account named danny with the same password as the other two danny accounts and must also be an admin on the machine. After all accounts are created and have been accessed for the first time restart all machines and boot the VS2010 hosting machine into the domain account (us\danny) and the remote machine into the local account with the same name as the domain account (machine name\danny).

This essentially means that three(3) accounts named danny must exist: us\danny, vs2010 machine name\danny, and remote machine name\danny and all of them must be admins on their respective boxes and all must use the same password.

Running the Remote Debugger (For Real)
Again returning to the list of articles on the (MSDN http://msdn.microsoft.com/en-us/library/y7f5zaaa.aspx) the next article is (How to: Run the Remote Debugging Monitor http://msdn.microsoft.com/en-us/library/xf8k2h6a.aspx). You have two choices at this point. Run the monitor as needed or run the monitor as a service. Because we will be constantly debugging using the HP Slate I decided to run the monitor as a service which requires a little extra work. You will need to run Local Security Policy. Then under Local Policies\User Rights Assignment there is a policy named Log on as a service that must be granted for the user that will be running the debugging monitor.
Performing a Remote Debug
I’m still struggling with this a little. I cannot figure out how to have VS2010 compile and launch the application I want to debug on the remote machine. Instead copy the compiled project files from the bin\debug folder of your project to the remote machine (I suggest a location easy to access and replace files in). Run the executable on the remote machine then in VS2010 of the hosting machine open the Attach to Process dialog (ctrl + alt + p). There is a drop down name Qualifier that when opened will detect the machine you’re trying to remote debug. Select the remote machine then attach to the process on the remote machine like you would as if the process were on the VS2010 hosting machine.

Thoughts
It only took a few hours to figure this all out. The part that kept killing me was the fact that even after you create a user account if you don’t log on as that user then it will not be available for use. Remote debugging is definitely cool! It helped us figure out quite a few issues in our remote code very quickly. Now that I know how to set up a remote debugging environment I will be using it more often.