Remote Debugging

[Previous] [Next]

Now that you're well versed in the nuances of advanced breakpoints, I want to turn to one of the hidden gems within the Visual C++ debugger: remote debugging. Remote debugging means that your program and a tiny debug stub run on one machine (the remote machine) and the debugger runs on another (the local machine), communicating with one another through Transmission Control Protocol/Internet Protocol (TCP/IP). Although you can do much of your debugging on a single machine with the Visual C++ debugger, if you encounter any of the following situations, which can be affected by the overhead of a full graphical user interface (GUI) debugger, you'll be glad you've heard of remote debugging:

• When you need to debug critical window activation code
• When you need to debug drawing or painting code
• When you need to free more memory for your application
• When you need to debug on Windows 98
• When you don't want to change the machine configuration drastically by installing the complete Visual C++ IDE

The worst situation you'll face is the first: when you need to debug critical window activation code. It is impossible to single-step through WM_SETFOCUS and similar processing on a single machine because the act of stepping causes your program to lose focus to the debugger. GUI debuggers are great, but in this case, the Heisenberg uncertainty principle as it applies to debuggers is alive and well! Moving the debugger to a separate machine allows the debugger and your program each to have its own focus, thus neatly sidestepping the problem.

The second situation in which remote debugging can save the day is when you need to debug drawing or painting code. Although you might be able to scrunch the debugger into one corner of the screen and your application into another for simple cases on a single-monitor system, in the hard cases, the debugger gets in the way. If your application must use a good chunk of screen real estate or your application is a Microsoft DirectX game, you need remote debugging.

The third situation in which you need remote debugging is more subtle but still definitely something to keep in mind. The full-blown GUI debugger uses a fair amount of resources. If you want the power and ease of use of the Visual C++ debugger, your application has to forgo some memory so that the debugger can run. In real-world development with real-world applications, debug builds can be huge. By using remote debugging, you'll free more memory for your application to run. You'll find remote debugging especially useful when you're having trouble testing against minimal requirement machines.

The fourth situation in which I use remote debugging is when I need to debug on Windows 98. Because remote debugging allows you to debug from one operating system to another, I use Windows 2000 for the target machine and Windows 98 for the remote machine because I've found that the Visual C++ debugger runs better on Windows 2000.

The final situation for remote debugging is when you're debugging a machine on which you suspect you might have a system DLL version problem with your application (aka "DLL Hell"). Installing the full Visual C++ IDE on the system in question can cause various system DLLs to be updated, thus destroying the chance to duplicate and fix the bug. By copying just the few files needed to run the remote portion of the debugger to the remote machine, you can still debug the problem.

The Visual Studio documentation does a good job explaining how to set up remote debugging. I don't want to duplicate that explanation here, so I encourage you to search for the "Debugging Remote Applications" topic on MSDN.

What I want to discuss for the rest of this section are the tricks and techniques that will make your remote debugging a pleasurable experience. The documentation does tell you what individual files you need to copy to the remote machine, but it doesn't tell you where you can locate them, so I listed the locations in Table 5-2.

Table 5-2 Necessary Files for Remote Debugging and Their Visual C++ Installed Locations

Files	Visual C++ Installed Location
MSVCMON.EXE, TLN0T.DLL, DM.DLL, MSDIS110.DLL	<VS Common>\MSDEV98\BIN
MSVCRT.DLL, MSVCP60.DLL	%SYSTEMROOT%\System32
PSAPI.DLL (Windows 2000 only)	%SYSTEMROOT%\System32

The first key to successful remote debugging is to get the two systems set so that the local machine, on which the debugger runs, can find the same binaries that the remote machine is running. At a minimum, you should have the remote machine share all drives because the local machine will need access to match binaries. The location of your program will depend on its complexity: it can reside on the local machine and run from there on the remote machine; it can reside on both machines; or it can reside only on the remote machine. If your program is just a standard EXE-type program, the remote machine can probably run it off the local machine. In today's brave new COM world, however, deciding where to run your program can get complicated. What has worked for me is to have the program in identical drives and directories on both machines. The second key to remote debugging is to ensure that you have your program completely and correctly installed (wherever you decide to put it) and ready to run on the remote machine before you start remote debugging.

MSVCMON.EXE is the debug stub that runs on the remote machine. MSVCMON.EXE has a Settings button that supposedly lets you specify the local machine network name—but don't bother using it because MSVCMON.EXE ignores the settings. After you start MSVCMON.EXE, make sure that you have your debugging project set up correctly on the local machine. In the Project Settings dialog box, on the Debug tab, put the complete path and file where the binary appears on the remote machine in the Remote Executable Path And File Name edit box. When you set the local debugger to debug remotely, the local debugger doesn't actually start the process. MSVCMON.EXE starts the process, so you have to tell it where to find the binary.

After you've set up your project and clicked the Go button, you pretty much debug just as you normally would. The only difference you'll see in remote debugging vs. regular debugging is that the local debugger will occasionally prompt you for the location of a matching DLL. (This is why I mentioned sharing all the remote computer's drives—you'll always need to be able to find the matching binary so that if you experience any sort of problems, you can look at the source.) Although the prompt has a check box for turning off DLL matching, you should never turn off this feature. The problem is that once you've turned off DLL matching there's no way to turn it back on other than by deleting the project OPT file. Additionally, the locations of the remotely matched binaries are stored in the project OPT file, so if later you want to connect to a different machine for remote debugging the same project, the only way to reset the binary file locations is to delete the project OPT as well. Keep in mind that deleting the project OPT will cause you to lose all the project's breakpoints and screen layouts.

You can combine a remote control application, such as Symantec's pcAnywhere, with remote debugging so that you can debug your application on the user's machine. I've done this across a company's intranet, though never on the wild and wooly Internet. Although such a combination could result in some security issues, it still might not be a bad trick to pull out of your debugging bag if needed. This sleight-of-hand might be especially useful if the user's machine is in Singapore, you're in New York, and you have to fix the problem today!

The last two points I want to mention about remote debugging are minor. The first is to remember to set your Visual C++ IDE back to local debugging when you've finished remote debugging. The setting for remote debugging is global to all projects even though, in my opinion, it should be a per-project setting. The last point is that if you're working on a network application or on a system that is sensitive to network traffic, remote debugging uses TCP/IP, so the debugger can get in your way. If you're in either of these situations, use WinDBG, which also supports remote debugging using the serial ports and a null modem cable.