Automatically launching the remote debugging monitor
One of the debates that has gone on in the debugger team is who should be responsible for launching the remote debugging components. VC has traditionally required that the user launch msvcmon.exe. VJ automatically launched debugging components. In VS 7.0/7.1, the debugger team tried to do automatic launch for 'default' transport.
There are a few issues with doing this:
- The profile for the remote debugging components is wrong. If you are doing a launch, this means that the debuggee is going to run under LocalSystem’s user profile, and LocalSystem’s process environment. If you are doing a managed attach and are loading symbols from a mapped drive, the remote debugger will not have that mapped drive.
- Debugger components sometimes run under impersonation. If you try and attach to a service and no one is logged in, the remote debugging components will run with an impersonation token. This will be a problem if you try and load symbols off a network share, because impersonation tokens don’t have access when calling off a box. The work around here is to log into the console or allow anonymous access to the file share.
- No way to configure the environment (except modifying the system settings). Some processes like to read environment variables. However, since the debuggee always runs from the system environment, these are very difficult to set.
We are still deciding what to do for the next version of Visual Studio. One thing we know is that if the user manually launches the remote debugger, we will always connect to the instance that the user started. Furthermore, we will only connect to user-launched remote debuggers for any launch scenario or if the Visual Studio user isn’t an admin on the debuggee machine. However, in current versions, we still support auto-launch in the remaining scenarios.
What do you think? Should we ever automatically launch the remote debugging components?