What information do you capture when your software crashes in the field?

Question

I am working on rewriting my unexpected error handling process, and I would like to ask the community:

What information do you capture both automatic, and manually, when software you have written crashes?

Right now, I capture a few items, some of which are:

Automatic:

1. Name of app that crashed
2. Version of app that crashed
3. Stack trace
4. Operating System version
5. RAM used by the application
6. Number of processors
7. Screen shot: (Only on non-public applications)
8. User name and contact information (from Active Directory)

Manual:

1. What context is the user in (i.e.: what company, tech support call number, RA number, etc...)
2. When did the user expect to happen? (Typical response: "Not to crash”)
3. Steps to reproduce.

What other bits of information do you capture that helps you discover the true cause of an applications problem, especially given that most users simply mash the keyboard when asked to tell you what happened.

For the record I’m using C#, WPF and .NET version 4, but I don’t necessarily want to limit myself to those.

Related: What to: Collect Information When Software Crashes

Related: What should be included in the state-of-the-art error and exception handling strategy?

Answer 1

(This is somewhat Windows / .NET specific, but that is what you specified in the question, and I think this is quite useful info in that context.)

Unless your application is strictly single-threaded, you want a dump file (which will give you the stack for all threads, at a minimum), not just a stack trace for the thread throwing the exception.

Generating a dump that is not too big and that has enough information to give you useful managed stack traces is a bit tricky, but there is a very useful utility called clrdump that will handle some of the gorier details for you.

Clrdump is mostly a wrapper for Microsoft's DbgHelp.dll. You can use DbgHelp directly - see this question - but then you will get a "full minidump" which will be as big as the virtual address space of your application, which can be pretty large. Clrdump does a nice job of creating a small dump with just the stack traces plus enough info for SOS to be able to read them.