Calling Dr. Watson
You may have noticed that if you ask Dr. Watson (drwtsn32.exe) to take a memory dump of the Winlogon process, Windows® shuts down as soon as it's finished. Some people wonder, "Why does connecting a debugger to Winlogon take down the entire system?"
But that's not what's happening. Running Dr. Watson on a process is not the same as attaching a debugger to a process. Attaching a debugger involves using something like ntsd—and this does work, assuming you have the necessary privileges. Indeed, this is how the Windows team debugs problems with Winlogon. So the literal response to this question is, "Attaching a debugger to Winlogon doesn't take down the system."
But Dr. Watson is a medical examiner, not a general practitioner, first taking a memory dump of a problematic process, then killing the process. Since Dr. Watson doesn't actually try to fix the problem, if it let the process continue running, that process would simply crash again. And the doctor would be called right back in, leading to an infinite loop. In a sense, Dr. Watson is a debugger that doesn't actually do any debugging. The good doctor just shows up on the scene, takes careful notes, and then kills the process. And it is just this—killing Winlogon after the memory dump has been taken—that causes the system to crash.
If you kill Winlogon, your system will reboot (Click the image for a larger view)
Winlogon is what is known as a "critical system process" and the death of a critical process forces the system to restart. Why does the system consider Winlogon critical to its functioning? For starters, Winlogon is responsible for handling the secure attention sequence—Ctrl+Alt+Del. If Winlogon dies, the secure attention sequence stops working. That in itself is kind of bad. What makes it worse is that with the official keeper of the secure attention sequence gone, another program can merely wait for the user to press Ctrl+Alt+Del and display a fake password dialog in response. It wouldn't be a very good secure attention sequence if it could be spoofed! As a protective measure, Windows shuts itself down before the bad situation becomes worse.
Now, if you run Task Manager, highlight a critical system process like Winlogon, click End Process, and confirm, then gosh darn it, you just killed Winlogon and the system will reboot (assuming, of course, you are running as an elevated administrator and therefore have sufficient privileges to kill the process).
In earlier versions of Windows, Task Manager tried to stop you from killing these critical system processes, but its algorithm for deciding which processes were critical wasn't very smart. If you were sufficiently devious, you could fake out Task Manager and create a program that it considered to be unkillable. Of course, this wasn't really the case. You could still kill the program—you just had to use a program other than Task Manager in order to do it. (For example, you might try the taskkill program.)
To avoid being faked out, Task Manager simply stopped trying to prevent you from killing critical system processes. After all, if you don't do anything, you can't do it wrong. This does mean that Task Manager is no longer watching over your shoulder when you kill a process. It won't slap your wrist when you try to kill something you'd probably be better off leaving alone. If you choose to kill a critical system process, you're just going to have to live with the consequences.
Raymond Chen's Web site, The Old New Thing, and identically titled book (Addison-Wesley, 2007) deal with Windows history and Win32 programming. He leaves the job of operationalizing mechanisms to others.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited