Knowledge Base

How to implement remote debugging in Visual Studio 2005

Article ID: 910448

Article Last Modified on 9/28/2006

APPLIES TO

Microsoft ASP.NET 2.0
Microsoft ASP.NET 1.1
Microsoft ASP.NET 1.0
Microsoft Visual Studio 2005 Standard Edition
Microsoft Visual Studio 2005 Professional Edition
Microsoft Visual Studio 2005 Express Edition

ASP.NET Support Voice column

How to implement remote debugging in Visual Studio 2005

To customize this column to your needs, we want to invite you to submit your ideas about topics that interest you and issues that you want to see addressed in future Knowledge Base articles and Support Voice columns. You can submit your ideas and feedback using the Ask For It form. There's also a link to the form at the bottom of this column.

Introduction

Welcome to the Microsoft ASP.NET Support Voice column! My name is Akshay N. S., and I am with the ASP.NET developer support team. I have been working with ASP.NET support for nearly two years. This month in the ASP.NET Support Voice column, I am going to describe how to implement remote debugging for ASP.NET Web applications by using Microsoft Visual Studio 2005. I would like to thank my technical lead, Jerry Orman, for his incredible help!

Remote debugging is considered one of the toughest topics in ASP.NET, but it's a really cool feature and is really helpful when we cannot have a local Web server or when we have to store the applications at a centralized location. This column covers how to set up and use remote debugging in Visual Studio 2005.

Remote debugging setup is greatly simplified in Visual Studio 2005. Although the DEBUG verb is still sent to the Web site to ensure that the remote process is running, all remote debugging scenarios except T-SQL debugging use the Remote Debugging Monitor (Msvsmon.exe).

For more information about what's new in the Visual Studio 2005 debugger, visit the following Microsoft Developer Network (MSDN) Web site:

http://msdn2.microsoft.com/en-us/library/01xdt7cs.aspx

In Visual Studio .NET 2003 and Visual Studio .NET 2002, debugging relied on two DCOM packages, Machine Debug Manager (Mdm.exe) and Vs7jit.exe. Common problems that people would see were caused by version mismatches, DCOM permissions, or networking issues, and troubleshooting the problems was very difficult. These packages have been eliminated. Msvsmon.exe now has a graphical user interface in place of the previous command-line interface. With the use of Msvsmon.exe, remote debugging is more simplified. You just need to run Msvsmon.exe, and the tool listens for the connections from the clients.

Msvsmon.exe has a user-friendly interface that makes it easier to use. The setup for remote debugging in Visual Studio 2005 is quite simple. You need to run Msvsmon.exe on the remote server prior to debugging. You can install the Remote Debugging Monitor from the Visual Studio 2005 CD or simply run Msvsmon.exe from a share without installing anything at all on the Web server.

To learn more about ASP.NET debugging, visit the following MSDN Web site:

http://msdn2.microsoft.com/en-us/library/ms227556.aspx

Why remote debugging?

You can consider using remote debugging when you have the following situations:

You cannot run a Web application locally.
You cannot have a local Web server, and you need to develop an application for Internet users or you want an application to be deployed on a Web server.
The application is not available to you locally.
You want to store the application at a centralized location.

The Remote Debugging Monitor (Msvsmon.exe)

The Remote Debugging Monitor (Msvsmon.exe) is a small application that Visual Studio 2005 connects to for remote debugging. During remote debugging, Visual Studio 2005 runs on one computer (the debugger host) and the Remote Debugging Monitor runs on the remote computer along with the application you are debugging.

The Remote Debugging Monitor runs as a Microsoft Windows application. The user interface shows that the Remote Debugging Monitor is running and makes remote debugging easy to set up.

Configuring Msvsmon.exe for remote debugging

You can configure the Remote Debugging Monitor for remote debugging in one of two modes:

Windows Authentication mode
This mode uses the operating system's built-in security to provide a high level of security. The Kerberos and NTLM protocols are used to authenticate all requests. Remote procedure call (RPC) packet privacy is used to encrypt data traveling over the network when you debug native code or .NET Framework-based code on computers that are running Microsoft Windows Server 2003, Microsoft Windows XP, Microsoft Windows 2000, and future Microsoft Windows operating systems.

To set up remote debugging in Windows Authentication mode, visit the following MSDN Web site:

http://msdn2.microsoft.com/en-us/library/ms164722.aspx
No Authentication mode
This mode has no security. Visual Studio 2005 will send the current user's user name to the remote debugger, but this information is used for informational purposes and is therefore not verified. No Authentication mode enables faster debugging on slow networks, but it is not secure and should be used only on secure networks. This mode should never be used on a network that might have hostile traffic. Additionally, this mode should never be used to remotely debug across the Internet. No Authentication mode only supports native debugging.

To set up remote debugging in No Authentication mode (for native code only), visit the following MSDN Web site:

http://msdn2.microsoft.com/en-us/library/ms164723.aspx

The remote debugger has been designed so that multiple users can run the remote debugger on the same computer. Each instance of the remote debugger has a unique server name. Server names are configurable, so you can give an instance of the remote debugger any server name. Usually, the default server name is satisfactory. The default server name varies depending on which user started the remote debugger. If the user_name user from the domain_name domain is logged on to the server_name computer, the default server name would be domain_name\user_name@server_name.

You connect to an instance of the remote debugger by entering the server name in the Attach To Process dialog box or by entering the server name into the debugging properties for a project. To open the Attach To Process dialog box, click Attach To Process on the Debug menu or on the Tools menu.

Debugging another user's computer

Suppose we want to perform remote debugging to a different user's computer with the different user logged on to the computer. We have to consider two primary issues:

Permissions

By default, only administrators and the user running the remote debugger have access to connect to the remote debugger.

Connecting

Visual Studio 2005 needs to know to which instance of the remote debugger you want to connect. If the same user is running the remote debugger and Visual Studio 2005, Visual Studio 2005 will be able to find the remote debugger without you telling it which user is running the remote debugger.

However, if a different user is running the remote debugger, Visual Studio 2005 must be told to connect to domain_name\user_name@remote_computer instead of just being told to connect to remote_computer.

Let's consider an example to understand this situation clearly. Molly Clark and Adam Barr are both employees at Adventure Works. Adventure Works has a Microsoft Windows NT domain named adventure-works.com. Adam is having trouble with some software that Molly wrote. Molly would like to debug this software on Adam's computer. Molly and Adam follow these steps:

Adam doesn't have the remote debugger on his computer. To set up the remote debugger, Molly decides to share out the Program Files\Microsoft Visual Studio 8\Common7\IDE\Remote Debugger directory on her computer. She creates a file share called Remote.
Adam runs \\MollyComputerName\Remote\x86\Msvsmon.exe.
After the remote debugger starts, Adam clicks Permissions on the Tools menu to configure the remote debugger by using the Permissions dialog box. He gives Molly permission to debug.

Note Adam could also configure the remote debugger by passing the /allow option when the remote debugger starts.

Molly starts Visual Studio 2005.
To open the Attach to Process dialog box, Molly clicks Attach to Process on the Tools menu.
Molly connects to Adam's computer by entering adventure-works.com\Adam@AdamComputerName in the Qualifier box.
Under Available Processes, Molly selects the worker process that her application is using and then clicks Attach.
Molly opens a browser and provides the URL to the remote application. The execution stops where the breakpoint is placed in the application.

Running the Remote Debugger Service in ASP.NET and in other server environments

For debugging in ASP.NET and other server environments, you can run the Remote Debugging Monitor as a Windows service (the Remote Debugger Service).

To configure the Remote Debugging Monitor as a service, follow these steps:

Click Start, click Microsoft Visual Studio 2005, point to Visual Studio Tools, and then click Visual Studio 2005 Remote Debugger Configuration Wizard.
Follow the steps in the wizard to set up remote debugging as a service.

How to set up the environment for remote debugging

Add the appropriate user to the Debugger Users group on the remote computer

To do this, follow these steps:

On the remote computer, right-click My Computer, and then click Manage.
Under Computer Management, expand System Tools, expand Local Users and Groups, and then expand Groups.
Double-click Debugger Users.
To add the appropriate user to the Debugger Users group, click Add in the Debugger Users Properties dialog box.
In the Select Users, Computers, or Groups dialog box, enter the appropriate user in the Enter the object names to select box, and then click OK two times. For example, enter Domain1\User1.
Exit the Computer Management tool.

Note In Visual Studio .NET 2003 and Visual Studio .NET 2002, the user who is trying to perform remote debugging has to be a member of the Administrators group. However, in Visual Studio 2005, we don't need to add this user to the Administrators group.

The following table shows what accounts can access the computer.

Computer setup	Local System account	Domain account	Local accounts with the same user name and password on both computers
Both computers on the same domain	Yes	Yes	Yes
Both computers on domains with two-way trust	No	No	Yes
One or both computers on a workgroup	No	No	Yes
Computers on different domains	No	No	Yes

Make sure that the Visual Studio 2005 remote debugging components are installed on the remote server

If you don't want to run Msvsmon.exe from a remote share, you have to install the remote debugging components. To install the remote debugging components, follow these steps:

Insert the last Visual Studio 2005 CD into the remote computer. For example, if your copy of Visual Studio 2005 came on four CDs, insert the fourth CD into the remote computer.
Navigate to the Remote Debugger folder on the CD.
The Remote Debugger folder contains a subfolder for every processor architecture, that is, x86, x64, and IA-64 (supported SKUs only). Open the subfolder that matches the processor of your computer.
Start Rdbgsetup.exe, and then follow the instructions to complete the setup.

Enable remote debugging on the remote server

To enable remote debugging on the remote server, you can do one of the following:

Install the Remote Debugging Monitor on the remote server from the Visual Studio 2005 CD. To do this, follow these steps:
1. Manually start Msvsmon.exe from the local file system when you start debugging. You can stop the process when you are finished debugging.
2. Start the Visual Studio 2005 Remote Debugger Service (Msvsmon.exe running as a service). By default, the service is disabled. You need to use the Services Microsoft Management Console (MMC) snap-in to enable and to start the service. Once the service is started, you can automatically debug ASP.NET applications.
Run Msvsmon.exe remotely from a share. By sharing out the Remote Debugging Components directory on the Visual Studio 2005 computer, you can run Msvsmon.exe on the remote server without installing anything on the server.

Msvsmon.exe is installed to the following paths:

Install path\Microsoft Visual Studio 8\Common7\IDE\Remote Debugger\x86
Install path\Microsoft Visual Studio 8\Common7\IDE\Remote Debugger\x64
Install path\Microsoft Visual Studio 8\Common7\IDE\Remote Debugger\ia64

Once you start Msvsmon.exe on the remote server, you can open your remote project and debug.

The Msvsmon.exe.config file needs to match the version of the common language runtime (CLR). The CLR version is version 2.0.50727 if you installed a Visual Studio 2005 service pack.

The following debugger features will not work when you run Msvsmon.exe from a share:

Debugging on a computer that is running Microsoft Windows Millennium Edition or Microsoft Windows 98
Stepping into an XML Web service (Manual attach is still possible.)
Automatic debugging of an ASP.NET Web application or an ATL Server-based Internet Server API (ISAPI) extension (Again, manual attach is still possible.)

For more information about how to set up remote debugging, visit the following MSDN Web site:

http://msdn2.microsoft.com/en-us/library/bt727f1t.aspx

Build a Web solution

To do this, follow these steps:

Click Start, point to All Programs, point to Microsoft Visual Studio 2005, and then click Microsoft Visual Studio 2005.
On the File menu, point to New, and then click Web Site.
In the New Web Site dialog box, click ASP.NET Web Site under Visual Web Developer installed templates.
In the Location box, click HTTP.
For the location, enter a path on the remote server. For example, enter http://RemoteServerName/WebApplicationName.

Note Make sure that the FrontPage Server Extensions from Microsoft are installed on the remote server. If you don't have the FrontPage Server Extensions installed on the remote server, you receive the following error message:
Open Default.aspx in the designer view.
Double-click the designer to open the Code Editor. You are placed in the Page_Load event.

Add the following line of code to the Page_Load event.

' Visual Basic
Response.Write("Hello World")

// C#
Response.Write("Hello World");

Press F9 on the current line to set a breakpoint.

Verify that remote debugging works

To verify that remote debugging works, press F5 to run the application in debug mode. The debugger should break at the line where you placed the breakpoint.

When you start debugging, the Remote Debugging Monitor looks like the following on the remote server:

This tells us that the user is connected to debug the application.

If the breakpoint is not hit, then we should consider looking at the Microsoft Internet Information Services (IIS) logs. The IIS logs will help you determine which step isn't working or whether the DEBUG verb is being sent to the Web server. The IIS logs are in the following location:

%windir%\system32\logfiles\w3svcNumber

Note Number is the IIS instance number of the Web site.

Tip You can also click Start, click Run, and then type LogFiles to go to the default log file directory.

You can get the path by checking the IIS properties:

Start IIS Manager.
Right-click the Web site you are creating projects against, and then click Properties.
On the Web Site tab, click Properties under Enable Logging.

The log file path and the directory are listed at the bottom of the General Properties tab.

This is how the IIS logs look after we are able to successfully debug the application. I've added comments in the log to show the items that we are looking for.

#Software: Microsoft Internet Information Services 5.1
#Version: 1.0
#Date: 2006-09-11 14:32:56
#Fields: time c-ip cs-method cs-uri-stem sc-status 
14:32:56 X.X.X.X POST /remoteApp/_vti_bin/_vti_aut/author.dll 200

Look for the debug verb after the IP address (in our case it's X.X.X.X). This indicates that the debug verb is sent to the Web server successfully.
14:32:58 X.X.X.X  DEBUG /remoteApp/Default.aspx 200
14:33:02 X.X.X.X GET /remoteApp/Default.aspx 200
14:33:05 X.X.X.X DEBUG /remoteApp/Default.aspx 200

If you don't find the DEBUG verb sent to the server that is running IIS, grab the following DEBUG verb log to get more information about what exactly is failing:

%TMP%\Visual Studio Web Debugger.log

Things to do before you implement remote debugging

You must reference the remote computer by using a computer name instead of an IP address.
The Web.config file for the ASP.NET application must not contain any errors, and the compilation element must have the debug attribute set to True.
At a minimum, the Visual Studio 2005 remote debugging components must be installed on the remote computer unless you want to run Msvsmon.exe from a remote share.

Note Make sure that you share out the Program Files\Microsoft Visual Studio 8\Common7\IDE\Remote Debugger directory and not just the subfolders within it. For example, if you share just the x86 folder and then you run Msvsmon.exe from a remote share without having the remote debugging components installed, you receive the following error message:
Make sure that a firewall is not blocking remote debugging. If you enable a firewall and if it's blocking the execution, you receive the following error message:
The security setting for the site must allow Integrated Windows authentication. The site may also allow anonymous access.
Make sure that the Remote Debugging Monitor is running on the remote server. If Msvsmon.exe is not running, you receive the following error message:

Microsoft KB Archive/910448

Contents

How to implement remote debugging in Visual Studio 2005

ASP.NET Support Voice column

How to implement remote debugging in Visual Studio 2005

Introduction

Why remote debugging?

The Remote Debugging Monitor (Msvsmon.exe)

Configuring Msvsmon.exe for remote debugging

Debugging another user's computer

Running the Remote Debugger Service in ASP.NET and in other server environments

How to set up the environment for remote debugging

Add the appropriate user to the Debugger Users group on the remote computer

Make sure that the Visual Studio 2005 remote debugging components are installed on the remote server

Enable remote debugging on the remote server

Build a Web solution

Verify that remote debugging works

Things to do before you implement remote debugging

Related links