Holy cow, I wrote a book!
Commenter littleguru asks,
"Why does the End Now button not kill the process immediately?"
When you click the End Now button,
the process really does end now,
but not before a brief message from our sponsor.
When you kill a hung application,
Windows Error Reporting steps in to record the state of the
hung application so it can be submitted to the mother ship
(with your permission).
If you are running Windows XP or Windows Vista,
you can briefly see a process called dumprep.exe
or WerFault.exe; these are the guys who are doing
the data collection.
After being uploaded to Microsoft,
these failure reports are studied
to determine why the application stopped responding and what
could be done to fix it.
I've been asked to do quite a few of these analyses myself,
and sometimes it's something pretty mundane
(an application sends a cross-thread message while holding a
critical section, and the thread can't receive the message
because it's stuck waiting for the critical section that the
sender is holding—classic deadlock),
and sometimes it's something pretty weird
(application has a bug if
the number of sound output devices is not equal to one).
Whatever the reason, I write up my analysis,
and the people who are in charge of such things make arrangements
for the information to be sent back
to the vendors who wrote the application
(assuming the vendors are
registered with Winqual).
If you don't want Windows Error Reporting to collect application
crash and hang reports,
you can disable it from the Group Policy Editor under
Windows Error Reporting.
Of course, if you do this, then
you don't get to vote on which
program crashes and failures Microsoft should work on fixing.
This entry is an experiment:
I mentioned Windows Error Reporting and WHQL.
If people complain about digital certificate authorities,
that'll just confirm my bias against returning to those old
Experimental results obtained.
No more stories involving Windows Error Reporting and WHQL.