Automating Crash Dump Analysis: Some Final Thoughts
For a reference, here are some links to the previous parts in this series:
· Prolific Usage of MiniDumpWriteDump
· Getting the Stack from a .DMP File
· Getting the Crash Details from a .DMP File
· Showing the Disassembly from a .DMP File
So now the question that begs to be answered is "how do we best leverage all this information?" Let's start by assuming we can stick all of it into a database for further (and easier) querying. This then opens up a whole slew of natural reports, such as, how often do we see similar types of crashes, or which functions or modules in our code base are the scariest.
If we add the ability to talk to a source control system, then we could start tying crashes to owners or developers based on the source control history (since we know the filenames and line numbers from the stack trace). This then gives us the ability to send out notification emails ("You have a new crash dump to look at") or to assign associated bugs to the correct individuals.
And speaking of bugs: If we are linked into the bug tracking system, we can then add support for some more automatic maintenance activities. For example, when a new crash dump comes in, we can look in our database and see if it is identical to something we've seen before. If it is, and any associated bugs are still active, we may just want to note the occurrence and not waste anybody's time by manually debugging the crash (we could automatically edit the bug to indicate that a new dump is available if needed). On the other hand, if the bug has already been "fixed", then we will want somebody to pay attention to the new crash dump.