Locate runtime errors with VS.NET's Remote Debugger

Microsoft provides the Remote Debugger with Visual Studio .NET to handle debugging an application on another machine. Tony Patton explains how to set up machines for remote debugging and demonstrates how to debug an application remotely.

Debugging can often be handled on a developer's local machine, but some problems exist solely in a test or production environment, thus requiring debugging within this environment. Microsoft provides the Remote Debugger with Visual Studio .NET (VS.NET) to handle debugging an application on another machine.

Remote debugger setup

Microsoft provides two ways to debug a remote application:

  • Remote debugging via DCOM and the Machine Debug Manager
  • Remote Debug Monitor

Since the second approach is more applicable to C/C++ and native code, I'll focus on the first one. In that method, the Machine Debug Manager is installed via VS.NET setup. You can install a full version of VS.NET or select the Remote Components Setup link on the main VS.NET installation screen. This selection provides two options:

  • Native Remote Debugging: Installs components that enable a debugger to connect for debugging of native code only.
  • Full Remote Debugging: Installs components that enable a debugger to connect for debugging of native code, managed code running on the CLR (Common Language Runtime), and script (VBScript or JScript). If SQL Server is installed on the machine, components for SQL remote debugging will be installed as well.

In this article, C# code is debugged, so we'll select the second option. This installs all necessary remote debugging files on the system. Once the remote debugging components are installed, you must set up system privileges that allow access for remote debugging.

  • To debug another user's process: You must be an administrator on the machine where the process runs. This applies whether you're attaching to another user's application or working with a Web application by attaching to the aspnet_wp.exe process.
  • To debug your own process: You must be an administrator or be listed in the Debugger Users group.

You'll be working with your own code/process, so adding your name to the remote system's Debugger User's group is sufficient. At this point, the machine is ready to be used for remote debugging.

Debugging an application remotely

With the remote machine set up, you can access your application from your own instance of VS.NET. This assumes that the application to be debugged is located on the remote machine. If not, you should copy the necessary file(s) to the machine.

The example in this article is a simple command-line application, so the executable is copied to a location on the remote machine. You'll debug the following simple C# application:

using System;
using System.Threading;
public class HelloWorld {
public const System.String message = "World";
public static void  Main(System.String[] args) {
Thread t1 = new Thread(new ThreadStart(Test1));
Thread t2 = new Thread(new ThreadStart(Test2));
static void Test1() {
System.Console.Out.WriteLine("1. Hello: " + message);
static void Test2() {
System.Console.Out.WriteLine("2. Hello: " + message);
} }

It's a simple C# console application that uses two threads with each thread sending output to the console. Debugging this application requires the following steps within the VS.NET IDE:

  1. Open the application's project file.
  2. Access the application's properties via the Project | HelloWorld Properties file menu.
  3. Select the Debugging category within the Configuration Properties folder in the Properties window.
  4. Change the Debugger Mode setting from Project to Program.
  5. For the Start Application setting, enter the complete path to the HelloWorld.exe file copied to the remote computer. (On my test machine, this is c:\HelloWorld.exe.)
  6. Set Enable Remote Debugging to True.
  7. For the Remote Debug Machine setting, enter the machine name or IP address for the remote machine.
  8. If you want to do mixed-mode debugging of managed and unmanaged code, set Enable Unmanaged Debugging to True.
  9. Click OK to save your changes.

Now you're ready to debug this application. When you choose Debug | Start from the file menu, the application is started on the remote machine. You can set breakpoints in the code within VS.NET, and the remote program will stop execution when it reaches the breakpoint(s). Then, you can step through the code (or whatever debugging action you choose) and try to pinpoint the runtime problems—if there are any. Note: You can use the same approach if you're using another .NET language such as VB.NET.

Potential issue you may encounter

While the Remote Debugger is an excellent tool included with the VS.NET IDE, you may encounter problems when you try to use it. For instance, gaining administrator level access to the remote machine may be restricted. System administrators get nervous when granting administrator-level access to any machine and equally anxious about installing new applications on the machine. This may be more of a problem if you're dealing with a production machine.

Alternative approaches

Another way to approach debugging or monitoring production-level code is recording runtime exceptions in the event log or database, or possibly e-mailing the messages to your inbox. An excellent approach involves using the Exception Handling Application Block and the Logging and Instrumentation Application Block, which are freely available from Microsoft.

TechRepublic's free .NET newsletter, delivered each Wednesday, contains useful tips and coding examples on topics such as Web services, ASP.NET, ADO.NET, and Visual Studio .NET. Automatically sign up today!