WinDbg is a native debugger and although using it combined with SOS to perform managed debugging is great, it sometimes lack the finesse that only a managed debugger can give.

CorDbg is a managed debugger that ships with the .NET Framework SDK. It was not written in managed code since it was the first managed debugger written in the early days of .NET when you couldn’t yet rely on managed code to produce a debugger that will debug it.

CorDbg knows and understand .NET better than WinDbg+SOS can. That is why you can better debug .NET applications with it.
For example, A simple scenario that is hard to do with WinDbg+SOS and very easy to do in CorDbg is to break only when specific .NET exceptions happen.
When I say specific I mean SPECIFIC, i.e., I can specifically specify that I want to ignore System.ThreadAbortException but not System.FileNotFoundException.

To do that all I need to do is run the following commands:

catch exception System.FileNotFoundException
ignore exception System.ThreadAbortException

WinDbg can only break (without adding sophisticated scripts to further analyze an exception) on CLR exceptions since all CLR exception has the same exception code.

Some more cool and useful things CorDbg can do includes:

  • Easily set a breakpoint in managed code (and we all know its not that nice to set a managed breakpoint in WinDbg using SOS) using the b[reak] command:b foo.cs:42 – will break in file foo.cs in line 42.
    b MyClass::MyFunction – will break at the start of MyClass::MyFunction
  • Disassembling to native or IL code using the dis[assemble] command.
  • Evaluate a function and using the f[unceval] command:f MyNamespace.MyClass::MyMethod – for static method
    f MyClass::MyMethod param1 param2 $result – for instance method. The result is stored in $result for further evaluations
  • Printing variables to see their content using their names (for local variables, only if debug symbols are available) using the p[rint] command instead of finding out their addresses to print them in WinDbg:
    p obj1.var1 – for variables inside objects
    p MyClass::MyStaticVar – for static variables
    p arr[2] – for print a specific cell in an array
  • Changing a variable value using the set command.
  • Setting the next line of execution by simply invoking setip [line number] (like you do with right-clicking in Visual Studio .NET)

As you can see, using a managed debugger like CorDbg can be a lot nicer and easier instead of WinDbg.

I heared unsubstantiated rumores that when Microsoft developers have problems with a certain build of Visual Studio they use CorDbg to figure out the problem or to debug instead of finding what the problem with Visual Studio is.

Visual Studio .NET 2005 will contain a new managed debugger that was written in managed code called MDbg. You can get it here (it required .NET Framework 2.0). MDbg has an extensions API so you can extened it just as you can extened WinDbg (but its even easier). It also features a nice simple GUI for those of you who doesn’t like to use the keyboard too much.

You can read more about MDbg in Mike Stall’s blog

I will dedicate another post to MDbg so stay tuned.

  • Pingback: Long live MDbg » Advanced .NET Debugging

  • http://www.whitespaceinternational.com/ Jack B.

    This is pretty informative. Thanks for posting this. :)

    Jack B.

  • workwear man

    I’m so glad to have found this blog today! Very useful information. Thank you for sharing!