What information do you request when resolving an issue on a client's box using a desktop app?

Question

We write a Windows desktop application that is installed on a few thousand computers that we have no access to. When one of these users reports a bug, even if the description is quite thorough, there is other information which may be helpful.

We are currently working on an automated feedback agent, which means we will have access to very detailed information. But like a kid in a candy store, we're not sure where to start. What information would you include in your feedback package in the same case? What is useful to help us reproduce there error?

What we've got so far is:

• The version number of our app,
• OS and OS version number
• Proxy information
• .NET version and update number
• Information specific to our app (eg. data versions)
• Access and error logs

Note that this is similar to this question, however we're not so much interested in getting info when the program crashes as we are as when the user experiences a bug.

Edit: Clarification: not asking for what information the user should give in the case of a bug, but rather what information should we gather?

Answer 1

Edit: I think I misread your question. I thought you're talking about what information to get from a customer reporting a bug, rather than already planning what I describe here. I'll leave it for reference anyway.

In a similar situation, despite fewer users, our app got a "Package logs for support" button which will create a zip file with all log files, and the currently opened project file, if any. All other information you described is already part of one of the log files. This way, a customer can conveniently send the ZIP file to us, which can be done from the main application window without opening a project file or connecting to a network interface, which are the two main points where something can go wrong. This makes it so much easier than to rely on the user providing feedback "by hand".

Other than that, the exact steps to reproduce the problem must be available. Most of that is typically in the project file itself (which is in the ZIP file we get), with only a few steps missing.

Things that seemed to be important for this, other than what you already listed:

• User/account information. This may help with permission issues. You might want to include things like timezone, locale, Windows theme.
• Application configuration, including where it is installed.
• As already said, the current file the user is working with, because this may be the cause of the problem.
• User settings, i.e. the data the application stores per user. Seen weird things with these. MRU list may also be helpful.

Answer 2

Aside from the basic state of the application (version, configuration, etc.), the most important information to get is:

• The step(s) required to reproduce the error or bug, including the inputs used if possible
• The expected output
• The actual output
• Contact information in case you need to follow up (if your software is consumed anonymously)

That will be enough information to solve 99.9% of the issues. For the rest, follow up and get any detailed information you think will help solve the problem (which, hopefully, will be far better understood at this point).

Answer 3

Even if you have all of that information, reproducing the issue can be difficult. When users describes how they created the bug they're often mistaken about key steps - it's hard for them to know what areas are critical when they don't know the inner workings of the application. You might want to implement a way of tracking user actions, such as root-level event handling or some other means - if you have undo/redo functionality then I'm sure this would suffice. You could then include the last (x) steps of the action chain in the error report.