Debugging with Visual Studio 2005/2008: Remote Debuggingby Patrick Mancier
How do you deal with a bug you can reproduce only on a test machine? Remote debugging to the rescue--discover how to debug a program on one machine with a debugger on another.
NOTE: Remote Debugging capability is not available in Visual Studio 2005/2008 Express. It also does not work on Windows XP Home edition, you will get an error saying "Not supported on this edition of Windows."
There are two terms will be used in this tutorial:
As previously explained, remote debugging is simply the idea of running a process on a separate machine and then attaching to this process via the debugger in Visual Studio. Once this connection to the remote process is established, as far as the debugger is concerned it appears that the process is running locally.
The beauty of this is that you do not have to have Visual Studio installed on the machine just to debug the application, you can do it remotely on another machine that does have Visual Studio installed. This kind of isolates the machine from any issues associated with installing Visual Studio, for example, it could eliminate the issue of testing installation dependencies where maybe a DLL is included with Visual Studio but is not natively included with the operating system installation. These are the kinds of reasons you might want to run an application on a untouched box.
Before you begin, make sure that your application is over on the target machine, while your program database file (commonly called <filename>.pdb) is located on the host machine; this file contains symbol information that the debugger will need to load once it attaches to the process. Also make sure that the executable you copy over is a binary match to the build of your source code, otherwise your debugger will not be synchronized and there will be all sorts of problems tracing through the code. This problem will exhibit itself as things like breakpoints not lining up and the watch variables not being valid.
To set up a remote debugging session, you first need to copy the debug server over to the target machine. Find the folder under your installation directory for visual studio Common7\IDE\Remote Debugger. If you're running Visual Studio 2008 for example it the program path would be [drive]:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger.
Copy this entire directory to the target machine that is running the process you would like to debug. You can put it in a directly anywhere on the drive.
Launch your application. Next, go into the directory you put the remote debugger in and launch msvsmon.exe.
When you run this you may get some dialog that pop up that indicate your Sharing and security model is set for guest, just click Yes.
Next you may or may not get a dialog indicating that a firewall is blocking the debugger server or that you need to enable remote file sharing. Select either the second or third option and click OK.
The next thing you need to do once it is running is to go to Tools/Options. Where the group box says Authentication Mode, select No Authentication, click on Allow any user to debug and click OK. Now the status screen show that there is no authentication. If you are REALLY concerned about running securely you can set all this up with a proper authorized windows account but since normally you would probably be running on a secure local network there really is no need to run securely in the debugger.
On your host machine in Visual Studio go to Tools->Attach to process (Ctrl-Alt-P) and open up the Attach to Process dialog. Change the Transport to Remote (Native only with no authentication). Next where it says .Qualifier. you're going to have to click the Browse button to search for your target machine on the network Once you find your target machine the Attach to Process dialog will refresh with the processes that are running on the other system.
Scroll down until you see the process you want to attach to. Click Attach. Once you do this the debugger will attach to this remote process and you can begin debugging as if you were running the application locally.
Thats about it. Happy debugging!Prev: Part 5: Using Trace and Log Messages
Debugging with Visual Studio Part 1: Debugging Concepts
Debugging with Visual Studio Part 2: Setting up the Debugger
Debugging with Visual Studio Part 3: Using Breakpoints Effectively
Debugging with Visual Studio Part 4: Setting Up Code for the Debugger
Debugging with Visual Studio Part 5: Using Trace and Log Messages
Main debugging page
Learn about another debugger, GDB
bug prevention, debugging strategies, tips, and gotchas
hunting segmentation faults and pointer errors
Finding Memory Leaks using Valgrind
Skip Stepping Into Functions with Visual Studio's NoStepInto Option