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
Expand Managed Debugging Assistants
Below is a picture of how it can look like when an Mda is triggered.
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" ?> <mdaConfig> <assistants> <callbackOnCollectedDelegate listSize="1500" /> <pInvokeStackImbalance /> <streamWriterBufferedDataLost /> </assistants> </mdaConfig>
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 [HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFramework] "MDA"="1"
Activating MDAs for only some applications
I personally like opening up a CMD shell and activating MDAs through an environment variable called COMPLUS_MDA.
Instruct the runtime to read the application specific mda.config file
Turns on all default MDAs plus the ones mentioned in the list.
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.
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.