In my article on Easier Multithreaded Debugging, there was a great question in the comments from GregM:
<
p style=”margin-left:36pt”>John, how about a way to make VS automatically attach to any children spawned by the process(es) being debugged?
The short answer: that’s not possible without a major architectural change to the Visual Studio debugger. That was an easy one to answer. Oh, you want to know why. OK, here’s the long answer.
The only way to start a process in Windows is to call the CreateProcess API. The sixth parameter to CreateProcess is the dwCreationFlags parameter, which controls the priority class and the creation of the process. Two of those process creation flags, are of interest to debuggers, DEBUG_PROCESS and DEBUG_ONLY_THIS_PROCESS. The DEBUG_PROCESS flag tells the operating system that the caller to CreateProcess (the debugger) wants to debug the process being started plus all processes started by the process being created. The DEBUG_ONLY_THIS_PROCESS says the debugger only wants to debug the child process and to forget about any others started from it.
As you can guess, Visual Studio uses the DEBUG_ONLY_THIS_PROCESS flag with CreateProcess. However, WinDBG, does support the DEBUG_PROCESS flag so you can debug the entire chain processes. Of course, WinDBG only does native C++ debugging but if that’s what Greg wants to do, WinDBG solves the problem for him. WinDBG is also cool enough to allow you to toggle on and off the debugging of child processes on the fly with the .childdbg command. For managed debugging, you are completely out of luck.
If you’re doing nothing but native code, you can also auto attach a debugger to any process when it starts with the Image File Execution Options trick in Windows. With this special registry key, you’re telling Windows that you want the specific process started under a native debugger whenever the process starts.
If WinDBG can do the parent-child hierarchical debugging, why can’t the Visual Studio debugger do this for native and managed debugging? (WARNING: I’m pulling this completely out of my rear and taking a total scientific wild a** guess [SWAG]. I have no access to the Visual Studio source code, have no idea for the real reasons for any decision by the team, and am probably completely wrong.)
My guess is that the original design requirement for the Visual Studio debugger was since 98% of the users are only debugging one process at a time, they optimized on that scenario. That meant that both the debugger loop (the main debugging engine) and the user interface were drastically simpler to design, develop, and test.
My guess (remember, SWAG) is that Visual Studio debugger is written so its debugger loop handles one process at a time. Since CreateProcess with the DEBUG_PROCESS flag means all debugging notifications for the parent and all child processes come in on the same thread, Visual Studio just doesn’t handle it. Playing around a little bit with Process Explorer and attaching to multiple processes shows threads being created after the attach so I suspect the architecture is one debuggee process per thread.
One thing I do know is that the Visual Studio debugger team has heard numerous times that people would like the automatic attach to child process. So far, it hasn’t shown up in Visual Studio 2010 Beta 1 and it may not, but I’m sure it will eventually get added.
Thanks for the question, GregM! If you have questions about the Windows debugging, the debuggers or performance tuning, please don’t hesitate to ask in a comment or send me an email (john @ this company’s web site).
Microsoft Azure and Amazon Web Services (AWS) are two of the most popular cloud platforms.…
Cloud management is difficult to do manually, especially if you work with multiple cloud…
Azure’s scalable infrastructure is often cited as one of the primary reasons why it's the…
https://www.youtube.com/watch?v=wDzCN0d8SeA Watch our "Unlocking the Power of AI in your Software Development Life Cycle (SDLC)"…
FinOps is a strategic approach to managing cloud costs. It combines financial management best practices…
Using Kubernetes with Azure combines the power of Kubernetes container orchestration and the cloud capabilities…
View Comments
The Visual Studio Team might have optimized the debugger for one process debugging, but I suppose that the debugger still have to handle the multi process debugging as it is possible to attach to multiple processes from Visual Studio - or would you guess that they just have multiple debuggers running in that case?
Hi,
Why not configure gflags to launch the debugger everytime your child process is started.
Brian
Klaus,
Sorry I didn't make it clear, my guess is that there is one thread per debuggee in the VS debugger. As the DEBUG_PROCESS flag means multiple processes must be debugged on the same thread, they don't support that.
Brian,
Yes, GFLAGS (Image File Execution Options) works great for native applications so any started process runs under the debugger. However, that doesn't work for managed applications so it's not a full solution.
Thanks for the questions and follow ups!
- John Robbins
Hi John,
I have used gflags to launch windbg on a managed app in XP and then loaded SOS to debug. I see this as a full solution, what am I missing?
Brian
Brian,
If that works for you, it's a full solution! :) However, many people want to be able to do source level debugging of their C#/VB source code, which is not supported with SOS.
Maybe I need to tell everyone how to use GFLAGS to make Image File Execution Options work.
- John Robbins
John, thanks for the answer. I am doing just native C++, and I tried Image File Execution Options, but couldn't get it to allow me to attach with the instance of Visual Studio that was already running.
That would probably suffice for what I'm trying to do. I'm using VS2005, but will be moving to VS2008 any day now, so if VS2008 allows using an instance that's already debugging, that would be great.
I'm running Vista x64 if that makes a difference. I did figure out that I needed to put the registry entry under Wow6432Node, and got the dialog that asks me which debugger to use, but it didn't offer the instance that was already debugging.
GregM,
I have bad news for you. :( Checking on Win 7 x64 with VS 2008 SP1 with both x64 and x86 crashes, if you're debugging one program and another crashes you can only start another instance of VS.
Maybe you could attach with the existing instance right before the crash? :)
- John RObbins
I might have misread what you've wanted to SWAG out there, but at least VS2008 and higher are capable of debugging more than one process at time. Try launching a few different projects manually that are in the same solution, setup some breakpoints in them, then do a "Attach-to" to all the running instances of different projects, and now play with them and watch how VS catches all the breaks.
Still, auto-attach-to-children-now-being-borned seem missing, :sob:
For C++ I find that putting '__asm int 3;' at the start of the spawned process is the best way to manage debugging it.