Managed Debugger Sample

We have a pure C#/IL managed debugger sample, called MDbg. It’s available on MSDN at . 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

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 (61)

  1. Woo Seok Seo says:

    Thank you for good information!

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

  3. Mike Stall says:

    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.

  4. Chua Wen Ching says:

    Can MDbg supports .Net Framework 1.1? I want debug for exe or dll created in .net framework 1.1.

    Any idea?

  5. Mike Stall says:

    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.

  6. Do you write Managed debuggers? Do you use the ICorDebug API?&amp;nbsp;We’re designing V3 of ICorDebug and…

  7. VS Beta 2 has shipped. The MDbg binaries are now included in the beta 2 sdk. (Kudos to Rick for this)…

  8. Mdbg is now included in the Whidbey Beta 2 SDK as a tool. The source is not actually included in the…

  9. I notice one of the most common issues folks hit when they try to write their own managed debugger is…

  10. Several people have asked how to write&amp;nbsp;something that runs some executable under a harness and then…

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

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

  13. ICorDebug (ICD) is a com-classic interface. In terms of COM threading models, ICorDebug is technically…

  14. You’ve already lost the game.

  15. Dan McKinley says:

    This is something I typed up internally, to help resolve the confusion that precipitates when Visual…

  16. ICorDebug, the managed debugging API, &amp;nbsp;is a public API and anybody can use it to write a managed…

  17. MDbg is a debugger for managed code written entirely in C# (and IL), which started shipping in the CLR

  18. I’m trying out Windows Live Writer. Currently, I do all of my blogging via Frontpage , so this will be