Managed Debugger Sample
We have a pure C#/IL managed debugger sample, called MDbg. It's available on MSDN at http://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:
- It's managed. Enough said :)
- Great extensibility model. You can easily write C# plugs-ins for Mdbg. A lot of our managed-debugger testing is done with Mdbg now.
- 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.
- 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.
