Remote Debugging
****
1. Introduction.
Remote debugging is one of the most interesting features of Visual Studio and it has been greatly simplified in Visual Studio 2005. The purpose of this article is to discuss the basic functionality, configuration details, and troubleshooting steps required for a successful remote debugging session.
Why we need remote debugging?
Troubleshooting an application on development environment is not a preferred choice. Especially when we have deployed an application on a production server where Visual Studio is not installed. It becomes more difficult when there is something system specific. In such situations, Remote debugging is a solution.
2. Remote Debugging components.
Before we start let’s try to understand what are the important components which play an important role in remote debugging.
Basically remote debugging works in a client-server architecture model. On the local machine there is devenv.exe (Visual Studio) and on the remote machine, the required component is msvsmon.exe( Visual studio remote debugging monitor).
Besides them there are several other components as well. Here is an article which gives a detailed list of Remote debugging components. Both managed and native debugging is supported.
These components are installed on the machine where Visual Studio 2005 is installed. And can be safely copied or shared to the remote machine.
These components are located at the following location:
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
Sharing the components is the preferred choice.
For a successful communication between the local and remote machine, there are several ports under the hood that needs to be opened. If there is any firewall between the two systems then it needs to be configured.
3. DCOM configuration
Remote access permissions for anonymous logon need to be setup on the machine where Visual Studio is installed. This can be done by using DCOM configuration tool (dcomcnfg.exe )
4. Firewall Settings and security (Ports and permissions)
DCOM RPC uses TCP 135 and IPSec uses UDP 500 and UDP 4500. These ports must be opened on both the machines.
Moreover permissions needs to be set for file and print sharing and adding msvsmon(on remote machine) and devenv.exe(on the local machine) to the exception list in the firewall settings. Here is an article which explains the steps.
5. Workgroup or Domain - how machines are connected?
There are different network scenarios. Depending upon which we needs to check the network authentication and communication issues. Remote Debugging Across Domains .
6. Managed or Unmanaged code (Is debugging mixed code possible)
Remote debugging is supported for both the managed and unmanaged code. However mixed code debugging or debugging managed and unmanaged code at the same time may not be stable. It is advisable to disable it How to: Enable Debugging of Unmanaged Code.
7. User Rights
In order to have a successful communication, the user account on the local machine must map to the user account on the remote machine and vice-versa. The safest way is to check that both the users are the members of the administrator/Debugger group and have the same username and password. However, this is not compulsory.
8. Authentication mode and No authentication – A threat to security?
Remote debugging in Visual Studio 2005 is supported in both the Authentication mode and no-Authentication mode. However no-authentication mode supports only the native code debugging.
No-authentication mode is faster but unsecured.
How to: Set Up Windows Authentication Mode
How to: Set Up "No Authentication" Mode
9. Two remote Debugging scenarios
Remote debugging can be performed in two ways:
a. To start a process from local machine, see Remote Debugging of a Project Built Locally
b. To attach to a process already running on remote machine, see How to: Select a Remote Machine
Comments
- Anonymous
December 21, 2007
.NET: JScriptIntelliSense:AReferenceforthe