Enable Remote Debugging to immediately attach to a starting process
The Global Flags Editor (gflags.exe) allows a debugger to be configured so that when a process is started, the debugger can attach immediately and break before the process' entry point. This already works with Visual Studio (devenv) and WinDbg.
It would be great if the Remote Debugger (msvsmon.exe) could be configured as the debugger for a process in the same way as VS and WinDbg.
I would expect the workflow to be something like:
1. configure msvsmon as the debugger for a process (eg notepad) on a remote machine
2. Attempt to start notepad.exe on the remote machine and find that the Remote Debugger starts first, begins listening on the configured port, and starts notepad.exe paused before its entry point
3. Open Visual Studio on my local machine and choose Attach to Process.
4. Specify the remote machine name and then choose the paused notepad.exe process from the list (perhaps highlighted differently from running processes).
5. Find myself attached to the process but waiting for me to configure breakpoints, step into, or just continue the process from before the entry point.
This would enable a better remote debugging experience for interactive applications, windows services, and web applications that are misbehaving during their early startup before a user can reasonably attach the debugger manually.
Thanks for taking the time to share this suggestion. Looking at the VS “15” plans, we’re not going to take action on this item, so we’re going to archive it. We think this is a great idea and have longer term plans on our backlog to improve the Attach to Process experience all up, including incorporating this suggestion.
Visual Studio Team
7 commentsComments are closed
Marc Chamberlin commented
2.5 years since this was reported and still no solution??? Pretty sad reflection on the design process at Microsoft, doing a few use case studies before designing the remote debugger should have easily revealed the need for this feature, and it can't be all that hard to provide a solution. Sebastian's workaround is on the right track and I can think of a number of variations on his scheme that would work. Thanks Sebastian!
I also voted for this feature, but in the meantime maybe my workaround will help you: https://lowleveldesign.wordpress.com/2015/06/22/how-to-debug-windows-services-written-in-net-part-ii/
Andrew Au commented
Please, this is useful and important.
Loved visual studio, but I just can't install the whole thing on every test machine, and needed to have debug on launch.
Debug on process launch
Setup Visual Studio to automatically attach (and break at entry point) to any externally launched processes by process name. Similarly, setup Visual Studio to automatically attach (and break at entry point) to any processes spawned by the program currently being debugged (recursively).
DO IT. Save us from the remote debugging misery and implement this.
Paul Tobey commented
Agree with this 100%. How many times have you had an installer extension or a shell extension that crashes on load? What do you do with that if it happens only on a user PC and not a development PC? DebugBreak? That's a code change. Are you sure it's not affecting the problem?