Information to include in a bug report.
-
Hi. In my experience users are very good at finding workarounds for bugs. They almost never bother trying to find out how to submit a bug. I can understand this as most applications have very different means of doing so - in a lot of cases it might be time consuming. To make it very simple for the user (and myself), I've built an application to catch unhandled exceptions and submit them by mail. I've added a stacktrace, some system info (os, memory), networking (domain, interfaces) and application info (name, version). I'm just wondering: What kind of information do you find useful in a bug report for a normal desktop application?
-
Hi. In my experience users are very good at finding workarounds for bugs. They almost never bother trying to find out how to submit a bug. I can understand this as most applications have very different means of doing so - in a lot of cases it might be time consuming. To make it very simple for the user (and myself), I've built an application to catch unhandled exceptions and submit them by mail. I've added a stacktrace, some system info (os, memory), networking (domain, interfaces) and application info (name, version). I'm just wondering: What kind of information do you find useful in a bug report for a normal desktop application?
simendsjo wrote:
I'm just wondering: What kind of information do you find useful in a bug report for a normal desktop application?
That depends on how far you want to go, and how much time you want to spend in finding the cause of a particular crash - which may even be caused by a hot CPU. I found that the EventLog sometimes contains some nice clues. A dump of the running processes, along with their CPU-usage can be helpfull too, to detect either malware or Adobe Acrobat Reader. If you can spare the room on your harddisk, then you might want to include a list of the installed service-packs :)
I are Troll :suss: