You can’t attach 2 debuggers to 1 process
Posted from Microsoft WebBlogs at 2004-12-11 14:58:00
For both managed-only and native-only debugging, you can only attach 1 debugger to a process.
Why?
The native debugger steals debug events from underneath the managed debugger. This confuses the managed-debugger and will cause it to crash. The native debugger has no way of coordinating with the managed-debugger here.
Troubles enforcing this:
In windows, the OS enforces that only 1 native debugger can be attached to a debuggee at a time (DebugActiveProcess to an already-debugged process will fail).
The Managed-only debugging services have similar checks to enforce that only 1 managed debugger can attach to a debuggee at a time.
Managed-only debugging is actually separate from native-only debugging. (This is related to using a helper-thread). If a process is being managed-only debugged, the OS does not view it as being native-only debugged.
This allows the loophole to attach 1 managed and 1 native debugger to an app at the same time. That would circumvent the checks.
To make matters worse, we can’t fully detect this scenario. The native debug APIs know nothing of managed-debugging, and so can’t enforce this. The inprocess-portion of the managed-debugging APIs could call IsDebuggerPresent to check if a native-debugger is attached, but the native-debugger could attach between such calls. There’s also not a good way for the managed debugger to respond even once it detects this situation.
Why would anybody want to do this?
There are actually a few scenarios to motivate attaching multiple debuggers to an app.
1) Getting more functionality ? A native-only debugger can only debug the native portions of the app. Likewise, A managed-only debugger can only debug the managed-only portions of the app. So what if you want to debug a mixed app with both managed and native code? One solution would be to attach both debuggers and use them simultaneously. (I think this is what you’d have to do in other similar scenarios; such as debugging VB6 calling native COM objects). We developed interop-debugging (aka “mixed-mode”) to explicitly enable this scenario. It allows a single debugger to debug both the managed and native portions of the app. Visual Studio supports mixed-mode debugging.
2) Debugging servers. Some server apps (like ASP.Net + SQL) may run code on behalf of multiple users. Ideally, each user could just attach a debugger simultaneously and debug their portion of the code running on the server. We hope to support these scenarios in a future CLR version via per-appdomain debugging (instead of just per-process debugging).
