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:



  1. 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.

  2. 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.

  3. 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?


Comments (2)

  1. Ziv Caspi says:

    There’s one scenario you don’t mention: that of having the loader automatically start/attach the debugger when it starts the process (via Image File Execution Options). This is the most effective way to debug service startup. Would that be supported?

  2. Gregg Miskelly says:

    In Whidbey, we have a much better solution for doing this locally. If you put ‘vsjitdebugger.exe’ as the Debugger in Image File Execution Options, we will execute the debuggee under the correct context, while launching the IDE as the logged in user. We install vsjitdebugger.exe to the path as well, so you don’t even need to find the thing.

    However, we still don’t have a good remote debugging story for ‘Image File Execution Options’. This is because VS has never done the ntsd.exe style remote debugging where you start a process under a debugger, and then can remotely connect to the running debugger. Someday we would like to do this, but it probably won’t happen for Whidbey. How often would you find this useful?