Callstack to the Rescue!
Been busy getting Office14 out the door. One thing keeping me busy is crashes buckets from Office 2007. When an application crashes, it will send information back as to where the program was when it crashed.
These crashes are analyzed and grouped together into similar “buckets”. We take the top buckets and try to determine what went wrong so we can fix them.
It pays to be good with a debugger and know assembly code here since all you have is registers, code and some memory at the time of a crash.
But what can be even more helpful is if someone else has already found a way to hit this crash. It’s 100x more useful to have repro steps which the same crash than it is to just have a dump. You can use a debug build (sometimes), you can use break points, you can change code to see how it affects the crash and later you can write automation to make sure it doesn’t come back!
How do you find these mythical repro steps? By searching the bug database for similar callstacks. If a tester has found a crash, ideally they also logged the callstack. If the callstack is similar to the dump file’s, it’s likely the same issue.
A Punted Bug
Two years ago, before Office 2007 shipped, we were all testing it trying to find a recall class problem. I came across a crash that involved SmartArt, text fields, multiple slides and undo/redo. Given the very convoluted way the crash reproed, we decided it wasn’t worth investigating and punted the bug.
Fast forward to today and we have a number of crashes in SmartArt that we don’t know what’s causing them. Turns out, people are hitting the same crash I found two years ago, although likely with simpler steps.
If I hadn’t copied the callstack into the bug, we may never have found out why this was happening.
Thank you, two years past self.
