We need your feedback on the fate of Cordbg.exe

We currently ship a command line debugger in the SDK, Cordbg.exe. It's implemented in unmanaged C++. In v2.0, our debugger test team also started developing their own command line debugger, MDbg, written in C# and harnessing the awesome power of managed code.


We don't want to maintain two command line debuggers. We'd strongly prefer to deprecate Cordbg and just go with MDbg. Thus we can redirect our efforts from Cordbg into the actual ICorDebug interface, which benefits all consumers (including Visual Studio and any third party tools).

Unfortunately, MDbg has a pretty different syntax than Cordbg and so we don't want to totally break people depending on Cordbg.


We're considering the follow plan. If you think this plan will cause you grief, please reply to this post and let us know.


1)       Ship MDbg in the SDK. This would also include our managed wrappers for ICorDebug.  We believe MDbg is a much better tool than Cordbg and users will really appreciate its extensibility model.

2)       Give MDbg a Cordbg-emulation mode. This means that MDbg can run with a Cordbg skin.  I think this is a win/win:

a.       The CLR wins - we only have to maintain a single command-line debugger (Mdbg), which we already have to maintain for our testing purposes anyways.  We can free up all resources spent on Cordbg.

b.       All ICorDebug consumers win –.  We can focus our resources on the real product. Also, people depending on Cordbg are not totally broken.

3)       As part of this, we're thinking of not including the following Cordbg commands in the emulation layer because we consider them to be sufficiently obscure that nobody actually uses them:

a.       conn[ect]- Connect to a remote device

b.       regd[efault] - Change the JIT debugger

c.       newobjnc - Create a new object via function evaluation, no constructor

d.       >  - Write commands to a file (this doesn’t seem to work as people expect anyways)

e.       uw[here], ut[hreads], uc[lear] – These are all the interop-debugging test commands that and Cordbg is not officially an interop-debugger.

f.         wt  - Track native instruction count and display call tree

g.       wr[itememory] - Write memory to target process

4)       Cordbg's v2.0 beta introduced several new commands. We'd only include the following in the emulation layer: 

a.       attachn[ame] -attach to a process by name.

b.       int[ercept] - intercept a managed exception (new feature in whidbey)

c.       #  - comment command (very useful for scripts).

5)       Other inspection information (such as getting a function's IL-->Native map, or IL debugging) would be available in MDbg via extensions.

6)       Cordbg’s fate on other platforms (like Rotor and Compact Frameworks) is still up in the air. Whatever we do, we’ll keep some command line debugger for them. Maybe those platforms will continue to use the native C++ Cordbg. Maybe we’ll get MDbg running on them (that’s a little harder since Rotor doesn’t support COM-interop)


Let me repeat, we’re just considering this plan and it’s all tentative. No commitments. If this all works, we'd expect the vasst majority of people to not notice any change in cordbg and not realize that they're actually using MDbg in an emulation mode. I’d love your feedback about what you think (just post feedback to this blog article).



Comments (16)

  1. Brian Long says:

    wt is a great switch. That’s the thing I’d miss.

    Even if not used in production debugging, it gives a great demo of what goes on inside a simplae when teaching .NET to a class

  2. bysza says:

    I think you should switch entirely to MDbg. CLR and managed code is a way to go. But please provide MDbg a Cordbg-emulation mode.

  3. The only uncertainty is the Heisenberg principle. Isn’t a native debugger "better" in that it has less influence on the internals of the CLR than a managed debugger?

  4. Steve Hall says:

    I would vote for leaving the original CorDbg in the SDK, but deprecated and unsupported…and WITH source code!…and all accumulated documentation. This would serve to satisfy all interests in the matter…including keeping it in both Rotor and CF (i.e., it could be the same source code package that gets included in those SDKs…)

    The proposed MDbg emulation mode list of subcommands (left in and out) looks fine on first glance, but it would be sure nice to have the old CorDbg available (but NOT as a separate download!) ((Why does EVERYTHING seen to end up being a separate everso "special" download? Isn’t that what SDKs are for?!?!!))

  5. Mike Stall says:

    Hallvard – both Cordbg + MDbg have the same heisenberg properties because they both use ICorDebug. The onyl difference is their implementation (C++ vs. C#).

    Now ICorDebug (managed debugging) has a much higher heisenberg effect than native debugging (and interop debugging’s heisenberg is even greater).

    Steve – fwiw, Cordbg does ship as a sample, in the SDK, with full source code. (see http://blogs.msdn.com/jmstall/archive/2004/10/05/237954.aspx)

  6. Brian Grunkemeyer says:

    I didn’t know about the wt nor connect commands – both of those sound interesting to me. But frankly, if rascal is freely & publicly available, the need for a command line debugger does decrease. I still like cordbg and haven’t used MDbg, but I can understand getting rid of cordbg & providing a cordbg-emulation mode for MDbg.

    To me, there are two crucial purposes for cordbg. The best feature is breaking when a managed exception is thrown. "ca e" then "g" are the most common commands I do in windbg, followed up by "where", "show", and "print".

    Probably the next most useful feature for me in cordbg is the ability to view memory directly, especially for String objects. I need to look at Unicode code points directly, and occasionally look at the length of a String object & check for zero’s at the end of a String (which may not show up in a debugger when printing the contents of a String).

    As long as MDbg does a good job here, I think we’re fine.

  7. Marc Rohloff says:

    I vote against removing connect. At this point this is the only way to debug compact applications apart from the VS integration.

  8. Mike Stall says:

    Marc – if MDbg had a connect command and could debug the Compact frameworks, then you’d still have an xcopy-deployable command line debugger for the CF. Would that address your needs?

  9. Marc Rohloff says:

    That would be even better than CorDbg.

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

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

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

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

Skip to main content