Freigeben über

Why can't you detach in interop-debugging?

  • Artikel

Matt Pietrek noticed you can't detach while interop-debugging (aka "mixed-mode") in VS. Short answer: this is a limitation of the CLR / ICorDebug.

Longer answer follows...

Some history:
Interop-debugging is managed + native debugging simultaneously in a single debugger. This means it's the lowest common denominator of managed and native debugging. Managed-debugging supports detach (ICorDebugProcess::Detach), but native debugging didn't support detach when the CLR was first written. DebugActiveProcessStop didn't come around until WinXp / Win2k03.  So Interop-detach was prevented by the OS when we first wrote the CLR.

... so why didn't we add Interop-detach in Whidbey once the OS support was available?
1. Interop-debugging involves ICorDebug wrapping all of the key native debugging APIs to make them play well with the CLR. The CLR does lots of evil things under the covers that would else wise horribly confuse a native debugger. This means that even when a new OS API is added (such as DebugActiveProcessStop), CLR may need to do some work to wrap it. This is not a good place to be, and we are actively working on fixing it.

2. We also ended up making various simplifying assumptions in interop-debugging that relied on not supporting detach (eg, that various race windows wouldn't exist), and so adding detach became sufficiently expensive that we couldn't just throw it in for free once we had the OS APIs.

3. We also had bigger fish to fry with interop-debugging. For .NET 2.0, we focused our attention here on radically improving stability (especially for attach) and  performance.

4. Not enough demand from customers. Interop-detach was missing since the first Betas of VS2003 (around 2000 / 2001?), so people had plenty of time to loudly give us feedback about it. The customer feedback was for stability and perf, and so that's where we focused.

Thus we never added a feature request to the CLR to enable it even once it was technically possible from the OS.

Comments

  • Anonymous
    March 01, 2006
    "The customer feedback was for stability and perf, and so that's where we focused"

    You're surely not claiming that VS2005 debugging is more stable and performant than VS2003?  There are some great things about VS2005, but that would be a strange claim to make in its favour.

  • Anonymous
    March 01, 2006
    Max C - I'm claiming that the underlying platform APIs for interop-debugging are more stable and faster in .Net 2.0 then they were in .Net 1.1.

    This makes no statement about the overall performance or stability of VS2005 vs. VS2003.

    Emperically, I've observed stepping while mixed-mode debugging in VS2005 to be faster than in VS2003. I blogged about some specific measurements here: http://blogs.msdn.com/jmstall/archive/2005/06/20/Interop_Stepping_Perf.aspx

    One area that we did make a mistake in is regarding certain MDAs that are on-by-default under a debugger. We do have an embarrasing case where pinvokes slow down 100x under the debugger:
    http://blogs.msdn.com/jmstall/archive/2006/01/17/pinvoke_100x_slower.aspx
    Something like that will certainly skew perf numbers.

  • Anonymous
    March 01, 2006
    Thanks for the frank answer.  By the way, there is another case very similar to the pinvoke MDA problem -- the 'Visual Studio Hosting Process' also slows the debugger to a crawl on processor-intensive code.  The factor is about 20x in that case.  (I realise this might not strictly be considered a debugger problem.)

  • Anonymous
    March 02, 2006
    The VSHost slows things down? That's ironic because they added it to speed things up.

    VSHost should just spin up in the background while the user is in Visual Studio, but then it's supposed to stop and wait.  

    Can you describe the scenario a little more and we can investigate that? Which code is processor-intensive?

  • Anonymous
    March 02, 2006
    There's a bug for this although it's been closed as a dup of the MDA problem (see Chris Goldfarb's feedback at the bottom).  On my PC right now I have MDAs disabled, and the code attached to the bug runs in about 2 seconds in the debugger with the hosting process disabled.  With it enabled, I gave up waiting for it to terminate.

    http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=0dda86da-a83f-475d-8610-d3a08a14cc7f

  • Anonymous
    March 09, 2006
    Detaching a managed-debugger is somewhat complicated at the ICorDebug API level. In a perfectly-friendly...

  • Anonymous
    January 15, 2007
    I've had a growing number of people inquire about how to write an interop-debugger with ICorDebug. I

  • Anonymous
    October 17, 2007
    Interop-debugging (mixed-mode) is managed + native debugging combined. Well, sort of. Native and managed