Archive for the 'MDbg' Category

I’ve found this interesting post on Mike Stall’s blog.

Felice Pollano is working on merging MDbg (I’ve talked about it before here) with Reflector (the .NET disassembler) so one can debug application without having debug symbols and still be able to get a bit more information than just IL code (you’ll be able to choose the language that will be displayed while debugging)

This is definitely something that I will keep on tracking since it can provide a bridge between hard core WinDbg debugging, soft core MDbg debugging and Visual Studio debugging.

There is a new broadcast episode on MSDN TV titled “Introduction to the CLR Managed Debugger“.
It features Jan Stranik, the guy who wrote MDbg and he shows examples, as well as talk about the API and have a few insights as two the problems and solutions he encountered while writing MDbg.

I talked about MDbg briefly here and even used it to create an small tool to capture and log all exceptions being thrown in the process (even swallowed one) which I titled ExceptionDbg.
Its available in both binary and source code and is a nice tool to see all of the exceptions being thrown and caught. It’s also a good reference to implement your own cutomized debuggers and applications based on MDbg.

If you want some more information about MDbg go here, to Mike Stall’s blog.

Following some of the samples posted in Mike Stall’s blog and after actually needing something like this at work, I’ve decided to write a small program called ExceptionDbg which uses MDbg’s APIs and tracks all exceptions being thrown in an application (including those that are being swallowed by try..catch blocks).

We had a case of exceptions being thrown in the finalization code (this is C++ code that has destructors and therefore has finalizers. I’ve talked about C++ destructor in this previous post).

ExceptionDbg let you attach to a process and dump all of the exceptions being thrown live to your console and/or log file.

There are a few filters on the exception types being logged including:

  • Show only exceptions being caught by try..catch blocks
  • Show full Call Stack and if debug symbols are present, show line numbers as well as source file names.

So what is it good for, you ask?

  • Check exceptions in the finalizer thread – These exceptions are ALWAYS being caught so the finalizer thread will not die. It can mean that if you have some code that frees some unmanaged resources they will not get freed and this is a potential memory leak.
  • Got a performance problem? Check how what are all the exceptions being thrown and caught (try..catch blocks) to verify that some pieces of code doesn’t use exception throwing as a logic to handle things other than failure.

As you can see, it’s useful for a number of scenarios and it help me a lot in finding some of these problems.

You can get the binaries here and the source code here.

You need the .NET Framework 2.0 for this which can be downloaded from here.
If you want to compile it you’ll need the .NET Framework 2.0 SDK which you can download from here.

Enjoy and send me feedback!

I had a stupid problem today compiling MDbg in VS2005 and I thought I should share it with you so others won’t waste 10min for their lives.

I have both VS2003 and VS2005 (the RTM of course 😉 ) installed on my machine.

The MDbg source code that I talked about in the previous post, has one assembly called corapi2 which only includes IL source code since it has a few COM marshaling trickes that are not covered by IL code generated from C#.

corapi2 has a .csproj file and is a part of the MDbg solution for ease of use. it doesn’t compile C# code, but rather run a post build command that runs ILAsm.

I tried to compile the soultion but it failed saying that it cannot recognize the interface ICorDebugProcessEnum.

I started to investigate and saw that it is suppose to be declared in corapi2.
I dropped corapi2.dll into Reflector and saw no .NET code. Strange.

I tried manually compiling it and go a funny error about uint32 in line 88. Go figure.
Then I noticed that I’m running ILAsm of Framework 1.1 and not Framework 2.0 since, for some reason I have the Framework 1.1 folder in my PATH environment variable.

I open the the Visual Studio 2005 Command Prompt, changed dir to the Mdbg folder and run nmake (which is the other option of compiling it) and it compiled with no special problems :-).

Beware of the PATH!

I just wanted to remind you that according to the post in the 10th of August in Mike Stall’s blog, the MDbg that worked on Beta 2 is also intended for use in the RTM release of .NET Framework 2.0.

You can get it from here.
It includes FULL source code for the debugger (which is a pure C# application) as well as additional samples and an extensions API (if you wrote an interesting extension please let me know).

I talked a bit about MDbg in a previous post.

Remeber a few posts ago that I talked about CorDbg, the managed debugger?
According to this post in Mike Stall’s blog (a fine blog, btw) its out of the SDK.

CorDbg was the first managed debugger that was written. It was written in native code since Interop in those days was still being written and was very unstable.
CorDbg also lacks features that are common in WinDbg such as extending it with extensions and instrumeting with it in a nice way.

Its hard (or even impossible according to this at Mike Stall’s blog) to implement a managed debugger in managed code for v1.1 (although I know there are a few people messing around with it as we speak, me included 😉 ). That is why CorDbg is the only viable managed debugger for production debugging for v1.1

To fill all of these gaps and to make things a lot more easier and more powerful here comes MDbg (ta-da).

MDbg is a managed deubugger fully written in C#. Its extendable by writing managed code to extend it, can be used to instrument code and is just so damn cool 😉

It gives you all the things you ever wanted from a production debugger and can also debug both .NET 1.1 and 2.0 code (to use it to debug 1.1 code you will still have to have the .NET 2.0 Runtime installed).

You can find out more information about MDbg here.
I am in the process of collecting some more information for a more elaborate post on MDbg and some of its features (probably a series of posts), so stay tuned.