Native-only debugging allows you to debug child processes. In other words, you can debug process A, and then if A spawns process B, your debugger can automatically start debugging process B.
This eliminates the need to manually attach to process B, and potentially losing the ability to debug B at startup. Windbg exposes this through the “-o” switch. At the API level, this is exposed via kernel32!CreateProcess by passing the DEBUG_PROCESS flag and excluding the DEBUG_ONLY_THIS_PROCESS flag.
Unfortunately, Managed-debugging and interop-debugging do not support this functionality.
(Shawn Farkas just asked me about this in the hall because this came up in his post here.)
Managed-debugging doesn’t support this for technical reasons. The managed-debugging pipeline is not actually built on top of native-debugging (see here and here for details), and thus it does not have the same opportunity to catch processes at startup.
In contrast, the native-debugging pipeline has OS support so the OS can tell it when a process is created. So now one may ask why Interop-debugging doesn’t support this. Afterall, interop is built on native-only and so it has the OS cooperation. It turns out this is just a missing feature in the CLR and not so much an architectural shortcoming.
I recognize that we could probably find ways to hack together a solution in the managed-only case, but the solutions would likely be hacky, ugly, and not necessarily fully correct. Since there wasn’t high demand for this feature, it was very easy to justify avoiding a hacky solution for a feature nobody was pushing for and instead add other features that folks really wanted, such as Edit-and-Continue.