Partilhar via

Summary of the role of MDbg and Cordbg

  • Artigo

I want to summarize in one place our views on Mdbg and Cordbg, and our plans for their future.

Our views on the different debuggers:
Cordbg/Mdbg - In general, we've never viewed Cordbg or MDbg as ideal production quality debuggers. We view Cordbg/Mdbg primarily as test tools and samples of how to use the API. They've lived in the SDK to provide a simple, primitive command line debugger for basic scenarios.
Visual Studio - We view Visual Studio (or other 3rd party debuggers) as the real debuggers. We recommend using Visual Studio over Cordbg/MDbg wherever possible. There's an entire team of great people dedicated to Visual Studio, whereas there are just a few folks randomly working on Mdbg in our free time. 
NTSD / CDB / WINDBG - these are Microsoft's "real" command line debuggers. Once NTSD supports real managed code debugging (and not just SOS), we would like to cease shipping Mdbg in the SDK altogether.

About Cordbg:
Cordbg was the first command line debugger for managed code. Cordbg was originally written as an internal testing tool for the ICorDebug APIs, and got sucked into shipping as a real product because there was a time (before VS supported the CLR) when it was the only debugger available. It was written in unmanaged C++, before COM-interop was operational, and it directly consumed the com-classic ICorDebug interfaces. Cordbg shipped in V1.0, and V1.1 SDK. The source shipped as a sample and was our primary documentation of the interfaces.  The unmanaged Cordbg's last ship date was in the VS 2005 Beta 1 SDK. In that release, it had some primitive (and untested) support for some new VS 2005 features. Cordbg may still ship in Rotor.

About Mdbg:
MDbg was written in V2, and has since replaced Cordbg. MDbg is written in C# and uses COM-interop to access ICorDebug. The initial motivation for writing MDbg was to leverage managed code's extensibility story to have a highly scriptable debugger that we could use for better automated testing of ICorDebug. MDbg now ships in the V2 SDK. Since MDbg was written from scratch, and Cordbg's feature set was not specified, MDbg is missing some unspecified features from Cordbg (like ca <type>). Unfortunately, this means MDbg is not at full feature parity with the V1.1 Cordbg. 
We also ship MDbg as full source sample. See here for a comparison of the MDbg sample versus the MDbg SDK.  The sample is intended as additional documentation for ICorDebug, and not as a production debugger.

Why the switch?
Because of MDbg's great extensibility story, we used it heavily internally for our own testing purposes. The CLR didn't want to maintain two command line debuggers (MDbg and Cordbg), we already had to maintain MDbg for testing, Mdbg was just plain cooler (being in C#), we solicited a lot of customer feedback (including here and here), and so we made the tough decision to cut Cordbg. Internally, we renamed the unmanaged CorDbg to "NativeTestDbg" and kept it around for legacy tests. All our our new test development is on Mdbg or VS.

The "Cordbg Skin" :
To help ease compatibility for anticipated cordbg-withdrawal, we created a "cordbg skin", which is just a veneer on top of Mdbg that makes it look like Cordbg. This is the Cordbg.exe that now ships in V2. Thus we completely switched the implementation of cordbg.exe between VS2005 beta 1 (unmanaged) and beta 2 (managed cordbg skin). (You'll notice Cordbg.exe now shows up in its own "pro" command). Unfortunately, just as MDbg lacks full parity with the old Cordbg, the cordbg skin lacks full parity too. Thus in trying to do a good thing (release MDbg), we have regressed cordbg functionality from an end-user perspective. This was a hard decision, but customers encouraged us that it was the right call. Furthermore, customers have also let us know there are more valuable places for us to invest our time than the Cordbg skin. Thus we would like to kill off the cordbg-skin (perhaps in the next release). Cordbg.exe will eventually cease to ship at all.

The future?
Cordbg.exe is being phased out and we'd like to stop shipping it completely.
VS is the preferred managed debugger over Cordbg/MDbg. It has great features for managed code and will only keep getting better.
Once NTSD has real command line support, we would like to stop shipping MDbg in the SDK. It will likely live on as a sample.
We will improve the document for ICorDebug, and we will continue to ship MDbg as a sample at least in the near term.

Comments

  • Anonymous
    November 07, 2005
    "Once NTSD supports real managed code debugging (and not just SOS)..."

    That's great news, thanks! I was worried that the NT debuggers would never get support beyond SOS.
  • Anonymous
    November 07, 2005
    You mention CorDbg, MDbg & VS, but skip over DbgClr, which was a very handy tool in .NET 1.x (haven't looked to see if it ships in 2.0). How do you see that debugger positioned? It makes an ideal mini-VS type debug shell for debugging apps at source level in any arbitrary language.
  • Anonymous
    November 08, 2005
    The comment has been removed
  • Anonymous
    November 08, 2005
    I'm glad to hear you suggest it will remain as, like some of the comments in that entry you refer to, I use it to debug end user sites. SDK is much easier to install than VS, and DbgClr offers a much easier debugging interface than CorDbg. Haven't played with MDbg though, so don't know yet how it compares, functionality-wise. Maybe a topic for a post?
  • Anonymous
    February 06, 2006
    I wanted to basically post about how it is to work for Microsoft, but the people here are so amazing...
  • Anonymous
    March 24, 2006
    In case you haven't already heard from every other blogger (like Shawn, JasonZ and Brad) , V2.0 of the...