Tip/trick: finding errors with mda’s

Most errors you run into when using the .NET Framework throw an exception making it easy to figure out what is going on.  However there has always been a class of bugs that are very hard to diagnose.  My favorite example is getting a P/Invoke declaration wrong which can screw up your stack and cause all sorts of hard to debug behavior to occur.

When we were building V2.0 of the CLR, we decided to try and make this easier for you by creating Managed Debug Assistants or MDAs.  These are dynamic checks that you can turn on while your application executes which will help you debug otherwise impossible to find conditions.

To help demonstate this, I created a how-do-I video on using MDAs.  This is my first attempt and (as you’ll see) I have some work to do tweaking my screen settings and production to get rid of some of the grainier pieces.  But hopefully it demonstrates the concepts well enough to get you going:

In the video I referenced three web pages that have more information:

One addition note:  we found after we shipped that the P/Invoke inbalance test caused quite a performance degredation for managed C++ when running under the debugger.  For this reason, this MDA check has been turned off in V2.0 SP1 (aka “red bits” which ships with the “Orcas” release).  This means if you download the “Orcas” February CTP, you must enable this MDA check manually using the config file settings I demonstrate in the video.

I’d be interested in hearing from you if MDAs have been useful for you when developing your projects.  We always debate during feature planning how much these kinds of things help and if we should add more.  Having community input would be very valuable!

Comments (3)

  1. Peter Ritchie says:

    RE: MDAs useful.  That’s a vote of "yes" for me.  Keep them coming.  While they may not be useful all the time or all at the same time; they can be switched on in certain circumstances.

    It would be nice if MDAs could be automated and/or hooked into unit testing.  e.g. run certain unit tests with P/Invoke imbalance test MDA turned on, and run certain unit test with it turned off…

  2. Another vote of useful from me. The problem for me has been remembering to turn them on whilst writing my code (whether I have a specific problem or not).

    I think it might be useful to have an MSBuild task that can set up MDAs prior to running unit tests. ie. Set the COMPLUS_MDA env var and generate an mda.config file.

    I guess it matters how detected problems would manifest themselves in such a unit test environment. For this to be useful within continuous integration, any MDA failures would need to fail the build.

  3. Anonymous says:

    Thanks for the feedback guys.  Hooking MDAs into the test environment is a very interesting idea.