(picture)

November 26, 2002

Forensic debuggers and visualisation

Gavin points to Green Hat Journal, who asks:

Imagine distributing an instrumented version of your program to 100 alpha customers. Every time the program commits an error, the user presses a button to generate a program trace and sends it to your server (WinXP does this for crashes, but they collect very little data). You collect hundreds of errors in a giant DB, with very detailed data on every program instance. Is it possible to automatically data mine these crashes to precisely identify the problem in the source code? I'll call this forensic debugging (FD).
Yup. Done, deployed. Groove has this subsystem called CSM:
If a problem occurs, the Groove software automatically notifies Groove Networks' Customer Service Manager (CSM) server about the problem, and then works with it to fix the problem. The information transmitted to the CSM server includes the execution state of your computer at the time the problem occurred.
I gather the database is pretty big. Now, mining that for long-term trends is one of a class of related things which interests me. How do error conditions manifest over time? How does a large source tree grow over time (whch areas have most churn, and how does that correlate to reliability)?

QVis could be a very interesting tool for this type of dataset. Must try it sometime.