Visual Studio 2010 – Historical Debugging
One of the great features arriving with Visual Studio 2010 are “Historical Debugging”.
What is Historical Debugging?
If you’ve been in the development world for any length of time you’ve probably ended up in a situation like one of the following more than a few times.
- You’ve received reports of a crash from a tester, but on your local box you can’t get the bug to reproduce.
- You’ve received a crash dump from the tester along with the bug. But the callstack that actually caused the crash was just a cascading effect and you can’t trace the bug back to the root issue.
- The bug that you are currently working at resolving has an extremely long set of reproduction steps and you just accidentally stepped over the function that is returning bad data.
- You know that some part of your program is hitting the registry way too often, but while stepping through all that you see are .Net framework calls and you are unable to isolate which of them is doing all the extra registry work.
For more information about “Historical Debugging” read Historical Debugging with Visual Studio
Event only – diagnose only event with minimal impact on application performance.
Using this option you are able to see “Diagnostic Event” view.
Events, Methods and Parameters – Method level tracing and have impact on application performance.
Using this option you are able to see “Debug Tree” view.
Limit Trace Recording and set if to see navigation while debug mode.
This area is very important, choose which modules you are tracking with running the application under Debug mode.