over HTTP as a POST form. This is intended to decrease the
amount of effort required to submit bug reports, reduce the
potential for human error, and increase the consistency of
the form of bug reports (always a crashinfo.txt, no wrapping
or RARring, not pasted into BTS text fields, and no forgetting
it entirely).
This offers less chance to fix the bug than a real BTS entry.
We can't interact with the user (since the submission is
anonymous and not tied to an email), so we can't get more
information about the problem or offer solutions; we can only
fix it based on the crashinfo. This will result in noise, due
to crashes caused by drivers.
We don't want people to send bug reports accidentally, but we
also don't want to encourage cancelling the report. This dialog
defaults to "view", so pressing enter neither sends the report
nor cancels.
We don't want people to modify crashinfo.txt before they send
it, since we want consistency. (Data sent is not re-read from
crashinfo.txt; it's simply kept in memory.) We also don't want
to give people the impression that changes in "view" will change
what's sent. At the same time, it's convenient to have the
crashinfo "view" function load notepad. So, crashinfo.txt is
marked read-only, so attempts to save over it in notepad will fail.
In this mode, we don't offer the option to load log.txt, or
point to a BTS. This is intended to make bug submission as
simple as possible for casual users. Keep the dialog simple
and to the point.
The id number that's displayed after a submission is intended
to be used as a reference; we can say "reproduce the crash,
submit the report and tell us what number is shown in the corner",
and easily locate the report. It's intended to be ignorable by
the most users, so no attempt is made at explaining what it means.
(It should probably be grayed out, but I havn't dug into it yet
to figure out how to gray it while still allowing the text to get
focus, so it can be copied.)
We send over HTTP, on port 80. This is probably the most likely
way to be able to send data out without any configuration.
(The localization support is incomplete.)
making crash handling more consistent. Move the crash
handling dialog into a new process, like the Unix handler
does.
- We're allowed to operate normally; we have a new heap,
so allocations are safe.
- Gzipping the VDI is easy now; we can simply use GunzipFile().
The only particularly ugly thing in this is the need to run
CrashGetModuleBaseName in the original process. That's lame,
but straightforward. It'd be better to use GetModuleFileNameEx,
but I didn't want to drag psapi.dll into this.
This may also make window hiding more reliable. Previously,
we wrote the crashinfo, tried to hide the window, then showed
the dialog. Hiding the window was risky and could hang or
crash again. Now we can forcibly kill the process from the
child, if needed, and still be able to show a dialog.
This also removes the backtrace and "reason" displays from the
dialog. Those weren't useful in practice; I always loaded the
crashinfo.txt and never used them, and they're intimidating to
casual users.
Glenn Maynard