Many know the basics and what’s there to know about Visual Studio debugging. With my work recently I faced the problem of identifying a cause for an exception which is thrown inside .Net framework code. This is not typical as .Net framework code is optimized and variables are optimized away.
For developers to fix bugs this is the most important tool, but is not being used that much, because maybe some doesn’t know its value. As you know Stack trace can be used to identify the calling stack up until the exception is thrown. But most of the time the stack trace contents cannot be accessed as it is optimized away. When you try to access the stack trace elements a window just appears saying that the source is not available.
To Overcome this, what needs to be done is trivial. We just need access to .Net framework code symbols. For that in Visual Studio 2010, Go to Debug->Options and Settings. There most probably “Enable .Net Framework source stepping” is not checked. Pretty straightforward. Just check that and press OK. Then Visual Studio will download the necessary public symbols from Microsoft. Then you would be able to access any entry in the stack trace as you please.
Also exceptions within the Common Language Runtime is not caught by default. To Catch CLR exceptions Go to Debug->Exceptions. In there check Thrown for Common Language Runtime exceptions.
Now you can identify all the exceptions that will be thrown when your app is debugged. But still this is little use as most of the locals cannot be identified as most of the code is optimized away.There are some options in the internet on how to overcome this. But personally I did not have any luck with them. But all locals are not optimized away. Some locals can be identified when they are assigned a new value. So not all hope is lost.
Using the above methods using the PCBs we can identify the called methods, and see where the exception is thrown. It has helped me a lot, as I have a weird need to know what the hell is going on inside the framework.