Historical Debugging in VS 2010 at 12.10.09

Ever had the fun of debugging an application, stepping through the source trying to find the piece of code thats causes an exception? Ever wondered why you couldn't step back from within a catch? Well, with the historical debugging feature of visual studio 2010 you can.

According to Microsoft, the historical debugger supports six mainline scenario's:

• Application Event Recording
• Playback Debugging (a.k.a Time Travel Debugging)
• Record and Playback of Manual Test Failures
• Debugging Build Acceptance Tests
• Diagnosing Unit Test Defects
• Debugging Load Test Failures
  

The historical debugger can be compared with a black-box in a plane, it logs important events in program execution which allows you to playback these events later.

So how does this historical debugging work?

The data that is being collected is pretty much the same as the information that is normally available when doing standard debugging. The first thing that crossed my mind was "how does this affect the performance?". But when you look at the default configuration, the data being collected and the frequency of when this data is being collected is not that much of a performance issue.

This behaviour can be tweaked by selecting several so called diagnostic events .When these diagnostic events aren't providing enough information, one can choose to collect debugging data at all method entry points, this ofcourse has a downside to the perfomance as all parameters etc. will be collected too.

Historical debugging in action

The historical debugger information will be shown in the normal debugger windows, for most of the information. You can step back, step forward etc. seeing the recorded execution. An example is shown in the screenshot below.

First impression

Unfortunately you cannot change the values of variables / parameters in historical debugging session, this would be a welcome addition. Further more, there is an option to save the sessions to a .tdlog file, but there is no tool to start a log in an enviroment where there is no visual studio etc. This tool will be available in the future though. When it's ready it will be a great tool to troubleshoot "not reproducable" bugs etc. At this moment I think it is just a nice idea which is nowhere near ready, especially compared to tools like AppSight. Another thing I miss is the possibility to change the historical debugging settings per project / application.