If you open one of those .rpt files in a text editor you will see 99% of what we report – only two items are not plain-text encoded. Basically:

– Your log file and the actual back-trace of the crash are encoded into the .rpt.
– A bunch of fields are added that you can see for yourself – mostly OS, driver and sim version info so that our database can filter on things like Mac vs Windows.
– Your comment (if you add one) and email (if you add one).
– That UUID is a hash of some system specific info – the goal is just to get a string that’s unique and consistent for YOU so that if a user reports a crash, we can say “let’s see EVERYTHING that’s crashed for this user.” Sometimes a user will have different crashes with one root cause (“look, that guy has a play-station blue-tooth joystick on Mac”). We can’t reverse a UUID to its input info.

Really the most important thing in the report form is the email, so that if we need more info we can contact you. If you file a bug with ‘the sim crashed’ the rpt file is all we need.

Hi Ben, Thank for a very informative post. I have a question about your XP10 Crash_Reporter. What info does it actually collect and send to you? I allways add my e-mail address, is there anything we (the users) could add to the comments field that would be especially useful to you or do you get all that you need from the .rpt file itself?
cessna729.

Your response seems worthy of its own blog post.

Last night, I installed the latest beta for the first time. Ben and friends gave me a lot of help over email when I bought X-plane because I kept experiencing total system crashes. It turns out that these were a result of over cranking the rendering settings.

I can happily report that, using the 64 bit beta, I played the sim for about half an hour with no crashes, even with the settings turned up to a degree which my computer is doesn’t have the power for. Sure, the fps dropped to about 7, so I wouldn’t seriously attempt to play the game in that configuration, but at least now I can play with the settings without fear of a crash and 5 minute restart each time.

So, well done to Ben and team, and thanks for all the hard work. I can report at least one pay-off for the 64 bit conversion!

Hi Ben,

I was not suggesting having people actually adding bugs to the DB – I was suggesting share the bug DB you have with the rest of the world, at least in a semi-RO mode. You guys would be the ones actually filing bugs…

Re: The duplicates, it’s perfectly fine to have 2 bugs opened for the same issue (so you keep all the information), as long as you mark the old one as “Dup” of the first one. We can discuss offline if you’re interested some approaches I usually do for managing a huge number of bugs without it becoming a nightmare.

Let me say this about a bug tracker: the bug report form has a small number of very clear instructions, things like “include a log.txt” and “don’t email this form for tech support” and the overwhelming majority of bug reports do not follow procedures. (Some users are very good about following instructions and I appreciate the effort that everyone puts in, even when the report instructions are not followed, and you, who is reading this may be in the minority of “I read the instructions first” but…statistically, most people aren’t paying attention.)

So while we have discussed internally a number of ways to do some kind of better sharing of bug information, we have not yet come up with anything satisfactory. In particular, we think that if we make the instructions _more_ complicated (which is almost guaranteed to be necessary to have a ‘full bug base’ approach) the results are going to be a wreck due to the number of bug reports that don’t follow procedure.

If you are an ambitious user who wants better bug tracking, I can see only one way to get the benefits of a bug base given our (LR’s) unwillingness to open up our internal bug DB while the level of bug report instruction following is so low (and I think this scheme isn’t terrible):

– A group of users who wants to have the advantage of a bug base maintains a public bug DB of ‘user submitted bugs’.
– Someone in that group submits the bugs to LR.
– Someone in that group ‘gardens’ the public bug base to keep junk out.

There is one more aspect of this scheme (and a public bug base in general) that I do not like:

Duplicate bugs contain information!!!

In other words, the number of users reporting a bug is really important for us to understand the configuration, frequency, and severity of a bug. It is useful for us that when something is _really_ broken, we hear about it 3 times, because there are a lot of “bugs” that we hear about only once, from one user, that turns out to be some local piece of crap-ware on their PC or a graphics card with a bad heat sync or magically goes away with a driver upgrade.

So my concern is that IF everyone stops reporting every duplicate bug, we won’t be able to tell the ‘real’ bugs from the ‘configuration problems’.

And one more note on duplicates: you guys (users) are not in a position to judge what is truly a duplicate bug, because often _two_ bugs in the system have _different_ root causes – particularly when the repro steps are non-obvious. And often one bug has multiple different manifestations, making it appear like two. So the ‘duplicate detection’ value of a public bug base may be limited – it will cause users to spend time reading bugs instead of filing (time not saved because to do the procedure right, you as a user must read the ENTIRE bug base to find whether you are reporting a dupe) and we get bugs filtered out, but not the ones we want filtered out.

I think there are two real issues going on with 10.20:

1. The speed at which I jump on the “obvious” bugs has been quite slow due to all of the plugin-related goo and other junk I’ve been working on, plus a beta during the Thanksgiving long weekend. Our normal approach is to fix anything that gets 5+ reports ASAP so that people stop re-reporting, and this “fast fix” approach is good for everyone.

2. I haven’t done a very good job of keeping up with the ‘known issues’ list, something that I can do a better job.

In fact, I think my summary is that the simplest thing for us to do is for me to post ‘known issues’ more aggressively.

A viewable bug tracker would be very useful — it would sure save me the time (and the headache) of having to report a bug that someone else may have already submitted.

As a 64-Bit testing guy so far I am happy with the first steps that you made.
Ron