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:
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:
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:
- 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:
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.
Collapse this tableExpand this table
| 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:
- Manually start Msvsmon.exe from the local file system
when you start debugging. You can stop the process when you are finished
debugging.
- 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:
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:Collapse this imageExpand this image
- 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:
Collapse this imageExpand this image
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:Collapse this imageExpand this image
- 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:
Collapse this imageExpand this image
- 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:
Collapse this imageExpand this image
Related links
908099
(http://kbalertz.com/Feedback.aspx?kbNumber=908099/
)
How to turn on remote debugging for Visual Studio 2005 in Windows XP with Service Pack 2
919823
(http://kbalertz.com/Feedback.aspx?kbNumber=919823/
)
You may
receive an error message when you try to connect to an instance of the Remote
Debugging Monitor in Visual Studio 2005
948040
(http://kbalertz.com/Feedback.aspx?kbNumber=948040/
)
Problems when trying to set up remote debug across network domains
As always, feel free to submit ideas on
topics you want addressed in future columns or in the Knowledge Base using the
Ask For It
(http://support.microsoft.com/common/survey.aspx?scid=sw;en;1176&p0=&p1=&p2=&p3=&p4=)
form.