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. Note: 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 debugging stories.

Update: Experimental results obtained. No more stories involving Windows Error Reporting and WHQL.