Historical debugger – Visual Studio 2010

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 call stack 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.

With Visual Studio 2010 Team System Editions we have something new, Historical Debugger, which is aimed at getting rid of these developer pain points.

The Historical Debugger plays a role similar to that of a black box in a plane . We keep track of important points in your programs execution and allow you to play back what happened at those points at a later time. We’re very proud of the current experience that we offer with the Visual Studio debugger so we’ve worked hard to surface all this new historical data in a way that is both useful and consistent with what you would expect from debugging in Visual Studio.

Happy programming & debugging. Hope this helps.