Feedback on the ICorDebug API?

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 (7)
  1. Serras says:

    Well, I started developing applications using Visual Basic 6, and then I changed to C#. Indeed, I can say C# is the language I have made most of my seriuos work with.

    About a year ago, I started developing and IDE for the MSIL language I had learnt some months earlier. I decided to create a debugger for it, so I started making a wrapper library for ICorDebug in C++. I don’t use C++ too much, and I don’t know many of the features of the language, so it took me crazy for some time. Also, the lack of documentation about how to use the API ina correct way was enormously notoriuos.

    One of the things I thought was really annoying was the neccesity of recompiling the DLL foreach( version in NETFramework.ReleasedVersions :-). MDbg was a good thing, but it came late for me :'(. So my suggestions are the folloing:

    – Create a .NET pure API for debugging, easy to use in any .NET language and really object-oriented (well, I know MDbg is…)

    – As a result of the first suggestion, there won’t be any necessity of recompiling the API for each version.

    – It would be also great to have an easy way to create breakpoints in code, based of the file and line number (I wasn’t successful on this task when doing ILIDE#).

    – Some tutorial that introduces you in this world, because for complete beginners there’s a lot to learn and normally books about this topics are very theory-oriented, and of course, don’t give any way to dealt with this in C#.

    If we have a way to create IL code within IL via System.Reflection, why not create a way to debug applications (for example, System.Debugging). With this, .NET Framework would became a real platform that won’t need any other tool for the outide and will be able to continue with its evolution. That’s my opinion. Thanks for reading my verborrea 🙂

  2. 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.

  3. Dmitriy says:

    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.

  4. Sameer says:

    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.



  5. Dmitry + Sammeer – SOS functionality and dump-debugging are at the top on our radar for the next version.


    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.

  6. Sameer says:

    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.

  7. Soma (my boss’s boss’s boss’s boss) recently blogged about how the CLR took a major change to fix Nullable. …

Comments are closed.

Skip to main content