Engineering in the white spaces
I've decided to blog this for myself as well as for other people, as it's quite useful to have all of this information in one place. These are some remote debugging tips when using .NET 1.0 or 1.1. Please note that these tips haven't been validated against .NET 2.0.
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.
If you only want to do remote debugging of native Win32 programs, you can install just the remote components needed for native debugging. The minimum components needed 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.
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.
Alternatively, you can install the full set of remote debugging components, which allows you to debug managed code in addition to native code.
There are some remote debugging restrictions:
- You can't use remote debugging to debug managed code 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.
- 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 (non-system) 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:
HKLM\Software\Microsoft\Machine Debug Manager\AllowLaunchAsOtherUser (DWORD = 1).
In addition, for the last two security restrictions in the list above, 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.
Finally, there are some extra remote debugging restrictions imposed by Windows XP SP2 and Windows 2003 SP1. Please see these articles for more details.
http://support.microsoft.com/default.aspx?kbid=841177
http://support.microsoft.com/default.aspx?scid=kb;%5BLN%5D;833977
http://blogs.msdn.com/andypennell/archive/2004/08/20/217933.aspx