Date: 5/5/2010
| I've got a number of outstanding Scribe bugs that involve crashes at the moment so I've been trying unsuccessfully to collect crash dumps and work out where the crash happened. The existing system writes a minidump to a file and I should be able to use that to find the stack trace of the crash and what threads were doing what. However the reality is that when I get all my symbols and binaries lined up VS2008 (express) fails to match the .PDB's with the binaries. I know that I have all the right files and paths, but I guess it just can't cope with VC6 built binaries/symbols.
So where does that leave me? I'm downloading VS2010 express at the moment to try and build Scribe/Lgi with so that I can try postmortem analysis with that. Hopefully the minidumps from a VS2010 build will seamlessly load into VS2010 and work. I already have good systems in place with the saving of symbols during my release process, but I need to close the loop so that crash dumps get reported back to me more autonomously.
This week I added proper version information to the version resource on the windows builds. That is handled by a custom build step running a python script that pulls the scribe version and build identification and the current SVN revision and then embeds that into the Resource.rc file so that it ends up in the version resource of the final binary. When the application crashes I try and load that information in to use as the filename of the crash dump so that you get something like this:
InScribe-2.00.24.4774-crash.dmp
So in the near future I'm planning to add some code that scans the install folder for .dmp files and offers to upload them to memecode.com to report the crash. Then I can collect them and fix the problem. In theory.
|
