Updated: June 2011
This topic applies to:
Edition | Visual Basic | C# | F# | C++ | Web Developer |
|---|---|---|---|---|---|
Express |  | | | | |
Pro, Premium, and Ultimate |  | | | | |
To enable remote debugging, you install or share remote debugging components on the remote computer that contains the application to be debugged. If your computers are protected by a firewall, you must take extra steps to enable communication between the remote computer and the computer that is hosting Visual Studio. You must also ensure that the debugger can locate the symbol files for the process to be debugged and that you have the correct permissions to access the process to be debugged.
 Note |
|---|
Both Visual Studio and the remote debugging components contain routines to automatically configure the firewalls of the computers. When you start remote debugging for the first time, Visual Studio should perform the necessary configuration on the Visual Studio host computer. When you run the Remote Debugging Monitor on a remote computer for the first time, the Remote Debugging Monitor should configure the Windows Firewall on that end. However, this functionality might not work because of the complexities of your firewall configuration. We recommend that you use the procedures described in the topics listed in the Configuring the Firewalls section to make sure that the programs and ports are allowed through the firewall. |
This topic contains the following sections:
Caution
|
|---|
|
Remote debugging is a highly privileged operation, sometimes requiring sysadmin privileges on the Visual Studio host and the remote computer. Review the information in the Debugger Security topic for best practices in remote debugging. |
The following permissions are required for remote debugging:
|
Native Debugging |
|---|
|
To debug a process that is running under your account and password: No special permission is needed. To debug a process that is running under another account name: Your Windows login account has to be a member of the system administrators group on the remote computer. |
|
Managed Debugging |
|---|
|
To debug a process that is running under your account and password: No special permission is needed. To debug a process that is running under another account name: You must have administrator privilege on the remote computer. If the ASP.NET worker process aspnet_wp.exe is running as SYSTEM or ASPNET, for example, you have to be an administrator on the computer where that process is running. Processes that host the common language runtime, such as SQL Server 2005, may enforce custom debugging privileges. |
For information about the permissions needed to debug Transact-SQL, see How to: Enable Transact-SQL Debugging
Symbol files contain the debugging information for compiled executables. The symbol files of the application to be debugged must be the files that were created when the application executables were compiled. The symbol files must also be located where the debugger can find them.
-
The symbol files for native applications must be located on the Visual Studio host computer.
-
The symbol files for managed applications must be located on the remote computer.
-
The symbol files for mixed (managed and native) applications must be located on both the Visual Studio host computer and the remote computer.
For more information, see Managing Symbols and Source Code.
If the Visual Studio host computer is protected by a firewall, you must configure the firewall to allow Visual Studio to communicate with the remote computer. If your network requires that communication be performed using IPSec, you must open additional ports in the firewall. The procedures that you use to configure your firewall depend on the version of the Windows operating system. For more information, see the topics listed in the Configure the Firewalls section.
If the Visual Studio host computer is not protected by a firewall, no additional steps are necessary.
Ports to open on the Visual Studio computer to enable remote debugging
|
Ports |
Protocol |
Description |
|---|---|---|
|
135 |
TCP |
Required |
|
500, 4500 |
UDP |
Required if your domain policy requires network communication to be performed through IPSec. |
To enable remote debugging, you can either:
-
Install the remote debugging components on the remote computer and launch the Remote Debugging Monitor (msvsmon.exe) when you start debugging- or -
-
Run the Remote Debugging Monitor remotely from a share.
If the remote computer is protected by a firewall, you must configure the firewall to allow the Remote Debugging Monitor to communicate with the Visual Studio host computer.
-
If your network requires that communication be performed using IPSec, you must open additional ports in the firewall.
-
If you are debugging a process on a web server, you must open an additional port.
The procedures that you use to configure your firewall depend on the version of the Windows operating system. For more information, see the topics listed in the Configure the Firewalls section.
Ports on the remote computer to open to enable remote debugging
|
Ports |
Protocol |
Description |
|---|---|---|
|
|
|
|
|
135, 139, 445 |
TCP |
Required |
|
137, 138 |
UDP |
Required |
|
500, 4500 |
UDP |
Required if your domain policy requires network communication to be performed through IPSec. |
|
80 |
TCP |
Required for Web Server debugging. |
Limitations of sharing remote debugging components
Although running the Remote Debugging Monitor from a file share is the easiest way to enable remote debugging, this method has the following limitations:
-
The Remote Debugging Monitor cannot run as a service from a share on the remote computer. You must install the remote debugging components as a service if you want to do either of the following tasks:
-
Start an ASP.NET web application with debugging from Visual Studio.
-
Step into a hosted serviced called from a WCF client.
However, you can attach the debugger to ASP.NET web applications and to WCF services.
-
-
If Visual Studio is installed on a 32-bit computer, only the 32-bit version of the Remote Debugging Monitor is installed. In this case, you must install the remote debugging components if you want to debug a 64-bit application on the remote computer.
Installing the remote debugging components
You can run or download the Microsoft Visual Studio 2010 Remote Debugger setup program from the Microsoft download center. The setup program is also available on the Visual Studio installation media in the vs\Remote Debugger folder. Choose the setup program that matches the operating system (x86, x64, ia64) on the remote computer.
After the setup program runs, the Visual Studio Remote Debugger Configuration Wizard is launched.
-
On the second page of the wizard, you can choose to run the remote debugger as a service. You can also specify credentials for the service.
-
On the third page of the wizard, you can select the network locations that can communicate with the remote debugger through the Windows firewall.
|
Note
|
|---|
|
Because of the complexities of Windows firewall configuration, the wizard might not set the appropriate program and port exceptions for the firewall. To make sure that the configuration is complete, we strongly encourage you to follow the procedures described in Configure the Firewalls . |
The remote debugging components are installed on the remote computer in the
-
C:\Program Files (x64)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger folder on x64 computers.
-
C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger folder on x86 computers.
Running the remote debugging components from a share
The remote debugging components are installed on the Visual Studio computer in the
-
C:\Program Files (x64)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger folder on x64 computers.
-
C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger folder on x86 computers.
Use the procedures described in Configure the Firewalls to enable the program and ports of the remote debugging monitor to communicate with the Visual Studio computer.
The following table provides links to topics that describe how to configure the firewalls on specific operating systems for both the Visual Studio host and remote computers. Although the programs and ports that are opened are the same for all versions of the operating system, the procedures vary. Choose the topics that match the operating system of the computer.
|
Operating system |
Configuration topic |
|---|---|
|
Windows 7Windows Server 2008Windows Server 2008 R2 |
How to: Configure the Windows 7 Firewall for Remote Debugging |
|
Windows Vista Service Pack 2 |
How to: Configure the Windows Vista Firewall for Remote Debugging |
|
Windows XP Service Pack 3Windows Server 2003 SP3 |
How to: Configure the Windows XP Firewall for Remote Debugging |
Other Resources
|
Date |
History |
Reason |
|---|---|---|
|
June 2011 |
Because of a significant number of issues with the remote debugging automatic configuration, this topic was extensively rewritten to emphasize manual configuration and simplify procedures. |
Customer feedback. |
Tidbits that may help folks:
Install:
Our servers are remote vm's so installing with physical media is not happening.
I downloaded the iso file and used magic disk to mount it on my local machine. (MS manual copy instructions also work.) Then I set up remote desktop connection under the local resources tab to include this mounted drive when I connected to our remote server. Then using this drive and the RDC I installed the remote debugger per instructions here. I could not get the service version to work.
Change the shortcut so that it automatically runs as administrator. (right mouse/properties/Compatibility - check "Run this program as admin")
Bugs:
Microsoft has a couple of bugs that are marked as closed, heaven knows why, still seems to be a problem, with regard to the authentication. Something about the authentication (token not recognized) not working in reverse when the two way communication is set up with the remote server.
The work around seems to have had varied success. It did work for me.
WorkAround:
1) On the remote server, create a local user account - domain is the name of your remote server. Add this new user to the local Administrator group.
2) duplicate the account creation you just did on your debug machine/client, with exactly the same username and password and Admin privs
3) Log onto the remote server using the local admin credentials - Click on the Remote Debugging Monitor (the one set to run as admin above) It should state "Msvsmon started a new server named 'MyLoginName@MyRemoteServerName'. Waiting for new connections."
(Note: Some folks have had success using a "runas" to start the msvsmon but on W2k8 this clashes with the "run as admin" Even when trying to use the "runas" from a cmd prompt under an admin account, windows still gave me the "elevated privs needed". If I changed the shortcut back NOT to run as admin, the elevated privs error would go away, to be replaced by a "can't debug because you don't have privs" error. even though the "runas" account was admin)
4) From Visual Studio on your debugging machine, select Debug-> Attach to Process...
- Set the Transport to Default.
- In the Attach to Process dialog box, enter the same name you saw above in the msvsmon msg 'MyLoginName@MyRemoteServerName' for the Qualifier.
- Click refresh, and select the running process to attach to from the list.
Debug Symbols:
I did all this, only to find that my breakpoints were not being hit.
The dll's that are loaded, are the ones from your remote machine, and in my case from the temporary internet cache. For some reason I have not yet figured out, some of those files were accompanied by pdb symbol files and others not, despite the fact the deployment had all the pdb files.
You can manually copy these files (they have to be the ones that were created together with the dll) into the temp internet cache, so that each corresponding pdb file lies in the same folder as it's partner dll. Then your break points should be solid red dots and not rings.
You can also use the modules window (debug\windows\modules - only visible while you are running) to point vstudio to the pdb files.
Hope this helps out folks.
The remote debbuger components install program that caused many of the difficult workarounds described in other wiki posts is available in the MSDN Download Center:
http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=60ec9d08-439b-4986-ae43-0487eb83c09e
My guess is that this topic went through our publication process before the Download Center details were finalized and wasn't updated when the info arrived. We will include the info in the topic at the next refresh.
Sorry for the confusion,
Patrick
The instructions in this article depend on having a CD or DVD. What am I supposed to do if I downloaded the Visual Studio 2010 software?
Please try to write instructions that apply to 99% of your users, instead of the 1% "ideal" case which almost nobody is going to benefit from.