Partilhar via


Managed Debugger Sample

We have a pure C#/IL managed debugger sample, called MDbg. It's available on MSDN at  https://www.microsoft.com/downloads/details.aspx?familyid=38449a42-6b7a-4e28-80ce-c55645ab1310&displaylang=en . For a variety of reasons, this sample only runs on v2.0 CLR (you can download beta 1 here).  

[Update]: We also have a winforms gui sample for Mdbg.
[Update]: The Mdbg binaries are now included in Whidbey beta2. See here for details.
[Update: 11/8/05] Here's a set of a bunch of MDbg links.

ICorDebug is an unmanaged COM-classic API. Cordbg.exe is a simple command line debugger that our team produces that consumes this API. We view Cordbg primarily as a testing tool, and I personally cringe at the thought of people using it for production debugging needs. Cordbg ships in the SDK and is actually available as a sample, though admittedly not a very good one. The code should also be public via the CLR shared source efforts. Cordbg is written in unmanaged C++ and suffers all the problems of unmanaged code: clunky api, painful to use strings, reference counting, poor extensibility, etc...

At the time Cordbg was being written, Com-interop didn't exist (at least not in a usable state). That aside, there's no technical reason that Cordbg couldn't be managed code.  And since we all know that managed code is much cooler than unmanaged code (shameless plug..), it made a lot of sense to try and make a managed version of Cordbg in C#.

Jan Stranik, a tester on our debugger team, used COM-interop to wrap the unmanaged ICorDebug API. This was very painful as ICorDebug was designed by folks (including myself) who were not very familiar with COM (for eg, I don't think any of us knew what "apartment state" was at the time). Jan worked these kinks out and then wrote a pretty managed wrapper on top of the com-interop layer which does things like exposes string properties as System.String instead. He then wrote a managed shell on top of that. The finished product is called MDbg (for Managed Debugger), and is exclusively in C# and IL.  It's extra impressive that he did most of it as a hobby. Most other folks on our team have since jumped on the Mdbg bandwagon. Nick Hertl, another tester, has done a lot of great work to make Mdbg into a sample. I personally think Mdbg is the greatest thing since sliced bread.

Mdbg's not perfect, but here are some reasons why Mdbg is so much better than Cordbg:

  1. It's managed. Enough said :)
  2. Great extensibility model. You can easily write C# plugs-ins for Mdbg. A lot of our managed-debugger testing is done with Mdbg now.
  3. Great object model. Mdbg lets you write small simple apps that can do cool things. For eg, Jan wrote a tiny app (< 100 lines) that's a sniffs a running app to print out when modules get loaded. You could write a similar app to attach to a random app and collect a managed stack trace.
  4. Better portability story - because it's pure-managed, you can drop the exact same bits onto other CLR-supported platforms (ia64,amd64) and run them as is. Cordbg had to be manually ported to these platforms.

There's a readme in the download with more info. We have an alias for further questions about Mdbg: clrmdbg AT microsoft.com

Who knows what the future holds? I personally would like to see us ship Mdbg in the SDK and kill off Cordbg.  I'd also love to see Mdbg become an open-source project (it's currently not, although it's freely available as a sample). I can't promise anything, but we'll see what happens.

Comments

  • Anonymous
    September 30, 2004
    Thank you for good information!

  • Anonymous
    October 04, 2004
    Hi, might be worth mentioning that this sample is for .NET 2.0 SDK beta due the inclusion of features such as edit and continue.

  • Anonymous
    October 04, 2004
    Whoops! Thanks Andrew, I forgot to mention that. I updated the original post with that addition. It's likely not possible to write a managed client of ICorDebug on pre-v2.0 ICorDebug.

  • Anonymous
    October 20, 2004
    Can MDbg supports .Net Framework 1.1? I want debug for exe or dll created in .net framework 1.1.

    Any idea?

  • Anonymous
    October 20, 2004
    Chua Wen Ching -
    1) The current MDbg sample can only debug v2.0 apps (eg, the version of the CLR in the debuggee's process is v2.0). We're actively revising MDbg to add support for debugging v1.1 and v2.0 apps. One snag is that there are bugs in the V1.1 ICorDebug impl that prevent it from being consumed by managed wrappers (eg, embarrassing bugs in our QueryInterface impls that break com-interop).

    2) MDbg requires the v2.0 CLR to run. In other words, the version of the CLR in the debugger's (Mdbg's) process is v2.0.
    This is because:
    - The actual MDbg implementation uses v2.0 functionality (like generics)
    - there are limitations with calling metadata from managed code that require the latest CLR to work around.

  • Anonymous
    April 06, 2005
    Do you write Managed debuggers? Do you use the ICorDebug API?&amp;nbsp;We're designing V3 of ICorDebug and...

  • Anonymous
    April 26, 2005
    VS Beta 2 has shipped. The MDbg binaries are now included in the beta 2 sdk. (Kudos to Rick for this)...

  • Anonymous
    June 02, 2005
    Mdbg is now included in the Whidbey Beta 2 SDK as a tool. The source is not actually included in the...

  • Anonymous
    July 19, 2005
    I notice one of the most common issues folks hit when they try to write their own managed debugger is...

  • Anonymous
    July 27, 2005
    Several people have asked how to write&amp;nbsp;something that runs some executable under a harness and then...

  • Anonymous
    August 10, 2005

    The Mdbg (a managed debugging written in pure C#) sample, which includes full source, has now been...

  • Anonymous
    August 10, 2005

    The Mdbg (a managed debugging written in pure C#) sample, which includes full source, has now been...

  • Anonymous
    September 14, 2005
    ICorDebug (ICD) is a com-classic interface. In terms of COM threading models, ICorDebug is technically...

  • Anonymous
    May 10, 2006
    You've already lost the game.

  • Anonymous
    May 19, 2006
    This is something I typed up internally, to help resolve the confusion that precipitates when Visual...

  • Anonymous
    June 14, 2006
    PingBack from http://blogs.msdn.com/jmstall/archive/2005/11/08/mdbg_linkfest.aspx

  • Anonymous
    July 26, 2006
    ICorDebug, the managed debugging API, &amp;nbsp;is a public API and anybody can use it to write a managed...

  • Anonymous
    November 22, 2006
    MDbg is a debugger for managed code written entirely in C# (and IL), which started shipping in the CLR

  • Anonymous
    October 26, 2007
    I'm trying out Windows Live Writer. Currently, I do all of my blogging via Frontpage , so this will be

  • Anonymous
    June 23, 2008
    The comment has been removed