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).
Are you looking to improve the performanaAzure Migration Assistant Tool Assessment: Improve Your Websitece, reliability and reach of your website?
Atmosera’s Azure Migration Assessment Program is focused on transitioning website infrastructure to Microsoft Azure.
The program includes the only free assessment of its kind to evaluate website workloads and performance data to develop an optimal cloud architecture.
The assessment helps prioritize requirements to optimize performance and realize continuous operation.
We also build in automated testing designed to streamline updates and ensure your site does not break.
Make Informed Decisions.
A plan which can be implemented immediately soundly, accurately, and with transparency.
A Better Environment.
Gain the flexibility, scalability, reliability and response time to deliver a superior experience.
A Team You Can Rely On.
Leverage a team of experts who will also manage and monitor the environment 24x7x365.