Freigeben über

Feedback on the ICorDebug API?

  • Artikel

Do you write Managed debuggers? Do you use the ICorDebug API? We're designing V3 of ICorDebug and are interested in any feedback you have about the API and writing managed debuggers in general. For example:

  • Are there any additions to the API you'd like to see?
  • Is there's anything about the API that really annoys you? (I personally have a growing list here of design flaws in ICorDebug, some of which I've blogged about here and here)
  • Is there some part of the API that is very confusing?
  • Is there some debugger feature that you want but really can't implement without additional debugging API support?
  • Have you ever tried to write a debugger for managed code? Have you ever played around with the source for Cordbg or Mdbg? What was your experience?

Comments

  • Anonymous
    April 06, 2005
    The comment has been removed
  • Anonymous
    April 07, 2005
    Serras, thanks for the feedback.
    What resources did you have when writing your debugger?
    What DLL was it that you had to recompile for each CLR version? You can have 1 executable target debug any version of the CLR.

    You're in luck because I think you'll actually get what you want in V2.0 (current version).
    1) We plan to ship MDbg, which will provide exactly what you're asking for: A pure managed API to the debugging interfaces (which could even be consumed by VB.Net!).
    2) The MDbg wrappers also make source-level breakpoints very easy.
    3) We're improving the Doc big time. We plan to actually get ICorDebug into MSDN.
  • Anonymous
    April 07, 2005
    A lot of functionality (browse style) exist in SOS that doesn't ICorDebug.
    Would be really nice to browse all objects in the process/appdomain. Browse all locks etc.
  • Anonymous
    April 10, 2005
    I think MDbg is excellent. I welcome plans for more documentation and specially ICordebug on MSDN.
    I'm working on a Debugging System for CLR My biggest complaint is with MDbg thread Model. but I know you guys r addressing it for next version.
    I'm very anxious to see more and more support for Win32/Native debugging in Mdbg. It's very easy (So I'm told!!!) to write PInvoke wrappers to DbgEng or Kernel32 calls, but it ain’t!!! I’m now nearly 60 man days down and still can’t find way home. It would be very encouraging for people like myself to have basic support within Mdbg to debug native applications. So we can explore lots of other possibilities!!

    Some features of SOS would be nice to have.
    Support for mini dumps for .net applications.

    Thanks

    Sameer
  • Anonymous
    April 11, 2005
    Dmitry + Sammeer - SOS functionality and dump-debugging are at the top on our radar for the next version.

    Sameer,
    I grieve at ICorDebug's threading (because we foolishly asynchrously dispatch events on another thread), and that problem manifests in Mdbg too. Is that Mdbg thread model issue you allude to?

    Whidbey Beta 2 Mdbg will include native wrappers. The final ("RTM") Whidbey Mdbg is looking like it will likely (though no promises here yet) have basic interop (managed+native) debugging support.
  • Anonymous
    April 11, 2005
    Thanks for reply, Mike
    My problem is we can't communicate with Debuggee from STA (GUI) thread.
    Having said that, Your new GUI Extension helped a lot. but when I want to show ToolTips etc from DataGrid I fall in trouble.

    Thanks for including Interop Debugging. :-)
    Would it be possible to debug pure native applications from MDbg beta 2? This is for apps hosting CLR.
  • Anonymous
    August 13, 2005
    Soma (my boss's boss's boss's boss) recently blogged about how the CLR took a major change to fix Nullable. ...