This section looks at how to install remote debugging and at some of the choices that you need to make during the installation process.
You can install the Visual Studio remote debugging components on Windows XP, Windows 2000, Windows NT 4.0 (provided you've installed Service Pack 6a), Windows 98, and Windows ME. By default, installing remote debugging adds the Windows account that you're using for the installation of remote debugging to the Debugger Users group on the remote machine. If you're going to be debugging remotely with a different Windows user than you used for installation of the remote debugging components, you'll need to add this user account manually to the Debugger Users group on the remote machine.
If you're working within a Windows domain, you can add any individual domain user to the Debugger Users group. Alternatively, you can create a domain group containing users who wish to do debugging and then add this domain group to the Debugger Users group. A final alternative is to add the INTERACTIVE group to the Debugger Users group so that anybody who can log in will also be able to debug, but this might be a significant security risk in some environments.
Visual Studio can perform remote debugging using any of three transport protocols with .NET 1.1 (the native pipes protocol isn't available with .NET 1.0). By default, remote debugging uses DCOM as the transport protocol together with the Machine Debug Manager (MDM) service (mdm.exe). If you want to debug managed code as well as unmanaged code, this is the only remote debugging transport protocol that you can use. The second transport protocol available is native-only TCP/IP, but this only allows you to debug unmanaged programs, such as those written in C++ or VB.Classic. The third possibility is to use the native-only pipe transport protocol. As with native-only TCP/IP, this last option only allows you to debug unmanaged code. Native-only pipe is a more secure, but significantly slower, protocol than native-only TCP/IP, and it isn't available on Windows 95, 98, or ME.
Figure 15-2 shows how you can choose which of the three transport protocols you wish to use when attaching to a remote process from the Debug ’ Processes window. Obviously, you need to choose the default DCOM protocol if you're going to be doing any remote debugging of managed code.
Figure 15-3 shows the standard installation window for Visual Studio. The option to install remote debugging is in the bottom center of the window, and you use it to install the remote debugging components on the remote machine. No extra installation is required on the local machine. If Visual Studio is already installed on the remote machine, you won't see the option to install remote debugging because it's installed as part of Visual Studio.
If you wish, you can opt to install just the remote components needed for debugging native Win32 programs. These are programs written using unmanaged languages such as VB.Classic and C++. The minimum components needed for remote native debugging are msvcmon.exe, msvcr70.dll, natdbgtlnet.dll, and natdbgdm.dll. If you're doing remote debugging under Windows NT, you'll also need psapi.dll, and if you need debug dump support, you'll need dbghelp.dll as well. Figure 15-4 shows the option to install native remote debugging only.
You can install the native remote debugging components either directly into a single folder on the remote machine or on a local share that can then be accessed from the remote machine. This latter option is very convenient in that it allows you to do native remote debugging without installing anything at all on the remote machine. This is very useful in production environments where you may not be allowed to install any debugging components.
Figure 15-5 shows the resulting installation instructions for setup of full remote debugging on Windows 2000. Full remote debugging allows you to debug both managed and unmanaged programs, as well as script applications. If SQL Server is detected on the remote machine, the SQL Server remote debugging components are also installed.
Note that each version of the operating system has its own unique instructions. For instance, when you install remote debugging on Windows ME or Windows 98, you'll probably need to install and configure DCOM because it's not installed by default on these operating systems.
In this section I discuss the restrictions that you might encounter when using remote debugging. Most of these restrictions aren't lethal, but a couple of them can be rather troublesome . This first list includes the three most common restrictions:
You can't use remote debugging to debug VB .NET, C#, or any other managed programs running on the Home Edition of Windows XP. This is because Windows XP Home Edition only supports TCP/IP for remote debugging, and you can only debug unmanaged (native Win32) programs remotely when using TCP/IP.
Windows 2000 doesn't support remote debugging using Terminal Services. I haven't established why this restriction exists.
You can't do remote debugging across Windows domains, unless those domains have two-way trust. This is a DCOM security restriction. You can use TCP/IP instead of DCOM for the remote debugging transport, but most firewalls will block the IP ports required for TCP/IP remote debugging. Note that this restriction effectively prevents standard remote debugging across the Internet.
One workaround for remote debugging across domains that don't have two way trust is to use Terminal Services to log into a machine in the remote domain. Providing this remote machine has Visual Studio installed, you can then perform local debugging on that machine or remote debugging on another machine in the remote domain.
The next list includes some security restrictions imposed by the Visual Studio debugger. As noted after the list, these restrictions can be overcome by setting a registry key on the remote machine.
You can't use Visual Studio to attach to, or launch, a remote process running in another user's Terminal Services session.
Unless you're an administrator on a remote machine, you can't attach to a process started by a console (nonsystem) user on that machine. This security restriction doesn't apply if you and the console user have the same Windows account.
You can't attach to a Windows service on a remote machine unless you're an administrator on that machine.
You can't launch a process on a remote machine unless you're logged into that machine, either locally or using Terminal Services.
Creating or modifying the following registry key on the remote machine can overcome these security restrictions:
HKEY_LOCAL_MACHINE \Software\Microsoft\Machine Debug Manager\AllowLaunchAsOtherUser
This registry key should be set to a DWORD value of 1 . In addition, for the last two security restrictions in this list, you need to have an administrator logged into the remote machine during the debugging session. This is an added security measure required by the Visual Studio debugger.