Your New Jekyll Site


Diagnosing errors with managed debugging assistants

17 Dec 2011

In Visual Studio, some MDAs are enabled by default in debug mode. Probably, for performance reasons, most of them are disabled.

Open the Debug –> Exceptions dialog box

Image of windbg

Image of windbg

Expand Managed Debugging Assistants

Image of windbg

Below is a picture of how it can look like when an Mda is triggered.

Image of windbg Scrolling down in the dialog box, you will find the name of the object of type StreamWriter in question. No further debugging is necessary.

Activating MDAs outside Visual Studio

First things first. The neat list of tick boxes where each MDAs can be configured to be activated or not has to be replicated. This is done through a special config file named App.exe.mda.config. If my application´s exe file is MyApp.exe, the config file is named MyApp.exe.mda.config and has to be in the same folder as the exe file.

Below is an example of how it can look like.

<?xml version="1.0" encoding="utf-8" ?>
    <callbackOnCollectedDelegate listSize="1500" />
    <pInvokeStackImbalance />
    <streamWriterBufferedDataLost />

Activating MDAs for all applications

I do not recommend this setting because you might accidently always run your apps with MDAs whenever there is a mda.config file present.

Windows Registry Editor Version 5.00

Activating MDAs for only some applications

I personally like opening up a CMD shell and activating MDAs through an environment variable called COMPLUS_MDA.

Image of windbg

COMPLUSMDA=1 Instruct the runtime to read the application specific mda.config file * COMPLUSMDA=0 Deactivates MDAs * COMPLUSMDA= Turns on all default MDAs plus the ones mentioned in the list. * COMPLUSMDA=0; Turns on only the MDAs present in the list.

When an MDA is triggered, an exception is thrown.

If you run under a debugger like Windbg, execution will halt, and you will see the same informative text as you would in Visual Studio.

Image of windbg

Running without a debugger, the exception thrown by the MDA will not be caught, execution continues, and eventually the application crashes with an unhandled exception.

Attaching a debugger at this moment is not as informative. In this case you might have to do low level debugging which is not trivial at all. Save yourself the trouble, and try to rerun the app under the debugger.

For more info read the MSDN pages on the subject Managed Debugging Assistants.