Why does killing Winlogon take down the entire system?


Commenter Demeli asks, "Why does Winlogon take down the entire system when you attach a debugger to it? (drwtsn32 -p <pid of Winlogon>)"

This question already has a mistaken in it. Running drwtsn32 on a process isn't attaching a debugger to it. Attaching a debugger would be something like ntsd -p <pid of Winlogon>, and this does work, assuming you have the necessary privileges, of course. (Indeed, this is how the Windows team debugs problems with Winlogon.) In other words, the literal answer to the question is "No, Winlogon does not take down the entire system when you attach a debugger to it."

What drwtsn32 does is take a crash dump of the process and then kills the target process. And it is killing Winlogon that crashes the system.

Winlogon is what is known as a "critical system process", the death of which forces a system restart. And you can probably guess why the system considers Winlogon critical to its functioning. For example, Winlogon is responsible for handling the secure attention sequence, also known as Ctrl+Alt+Del. If Winlogon were to die, then the secure attention sequence would stop working. That's kind of bad.

Comments (29)
  1. Laonianren says:

    This didn’t used to be the case.  Early versions of NT didn’t have critical processes and the kernel would continue to run even if you killed all the subsystems, though terminal interaction was impossible once csrss was gone.  If you killed winlogon not only was CTRL+ALT+DEL broken but some security checks ceased defaulting to access allowed; so it is very critical.

    NT has always been very modular.

  2. mvadu says:

    I have a question, not sure if relevant or not. Who takes care of locking the work station when I press Win+L. Even when the processor is 100% utilized (or a infinite loop is running) this works. Is it also part of Winlogon?

    If so, then why it can not bring up task manager in the same way. In the infinite loop scenario it takes few minutes to get Task manager open with the short cut Ctrl+Shift+Esc.

  3. Josh says:

    I can tell you that Win-L is not as "special" as Ctrl-Alt-Del.  It is possible to intercept it via a low-level keyboard hook and prevent it from reaching the OS (unlike Ctrl-Alt-Del).  Design guidelines state that it should still be passed to the OS however, to maintain the behavior users expect.

  4. Josh says:

    I should note that Win key shortcuts are processed differently from other keyboard shortcuts, which may account for the perceived difference in behavior.  I haven’t directly examined the code paths for them though, so I can’t say exactly how they differ.

  5. Mark says:

    Winlogon does both, but Task Manager involves creating a  process, while locking is mostly RPC.

  6. Neil says:

    "This question already has a mistaken in it."

    Why is it that comments on mistakes have more than their fair share of mistakes?

    Nitpickers’ corner: It wouldn’t surprise me to discover that only the session 0 instance of Winlogon is critical, though I don’t plan on killing any instances of Winlogon to verify this.

  7. Yuhong Bao says:

    BTW, I once asked Larry Osterman about automatically restarting csrss.exe once it was killed, and unfortunately that would involve restarting every Win32 app running on the system. What about Winlogon.exe?

  8. Karellen says:

    Why does Windows have so many critical system processes?

    I mean, the main point of having separate processes is to isolate them from each other; if one gets confused and/or dies, others keep running. Having multiple critical system processes kind of defeats this, doesn’t it? If one dies then the rest still all die.

    Why not just put all the critical code in a single process?

  9. Ens says:

    That’s not the only advantage that a multiprocess model gives you.  And just in general, it’s a good idea to be modular where you can.

  10. Sitten Spynne says:

    "Why not just put all the critical code in a single process?"

    I don’t understand why people use classes and object-oriented code!  In the end, it all gets compiled into a single executable, so why can’t I just write everything in a single source file?

  11. Mark Steward says:

    Neil: http://en.wikipedia.org/wiki/Muphry%27s_law

    I can confirm that only session 0 is critical: Winlogon quits after a winstation ends.

  12. "Why not just put all the critical code in a single process?"

    Probably because some code is more critical than other. E.g. SCM or WinLogon may die, but if the kernel is still working, the machine will do clean shutdown, without corrupting your file system. I think it is better than potential for propagating failures to other parts of the system.

  13. James says:

    Apart from anything else, keeping them apart will simplify debugging (and crash diagnostics): much easier to debug winlogon.exe while csrss.exe and co are still working properly, rather than having megaprocess.exe fail taking out everything important in one go!

    For that matter, you could just chuck it all straight into the kernel itself. After all, if a bug means the system goes down anyway, why would it matter whether it’s "only" a process (whose death knocks out the kernel anyway) or the kernel itself?

    Answer: apart from the engineering aspect, there are worse things than forcing a reboot/shutdown. A bug which merely crashes winlogon or csrss might lead to privilege escalation or information leakage if it were kernel code, making the bug much more serious. Instead of an orderly if unplanned reboot, you have a genuine kernel crash – or worse.

  14. ::Wendy:: says:

    Welcome back!  

    Can we spin the language to be descriptive yet less drawing on human criminal activity terminology?  Are there any suggestions for meaningful yet politely spun language to replace (I know it wont, I’m playing):

    Kill, Crash, Death and Die?  

    For example, with a nautical theme?  such as, wreak, sunk, scuppered …

  15. Name required* says:

    Interesting observation: If winlogon doesn’t run, you cann’t use Ctrl+Alt+Del, but Ctrl+Shift+Escape still works…

  16. SRS says:

    Kill, Crash, Death and Die for Cows:

    Moo, Mooo, Moo, Mooooargh…

  17. ::Wendy:: says:

    SRS,  I hope that not a variant of SARS, you’ve got the job of front-person for the new udderly-fabulous-social-networking-system of the Milk marketing board in the UK (nitpickers – I’m not completely serious,  I will go away soon,  I’m here to test your patience)

  18. John says:

    @Wendy:  How about these?

    "murdering a process"

    "slaughtering a process"

    "dismembering a process"

    "slitting a process’s throat"

    "stabbing a process in the eye"

    "running a process over with a bus"

    "beating a process to death with a sock full of pennies"

  19. I really like John’s suggestions.

  20. Starfish says:

    How about executing a process? …oh, wait…

  21. Shinobu says:

    I never understood the point of the secure attention sequence. The theory goes like this: if you get a logon prompt ("Press Ctrl-Alt-Delete to logon") you have to press the combination before you can enter your username so that you know it’s really the system you’re telling your password and not some user process. However, you can replace the task manager executable and use that to exactly replicate the Windows logon screen, including the ‘secure’ attention sequence thing. So what is it for, really?

  22. Mark says:

    Wendy, you mean "why givin’ Winlogon the long walk be surely scupperin’ yer ship"?

    I think we’d be more productive describing Windows design in baby talk…  "If Uncle Win-win goes on a long holiday, why does it make computer cry?"

  23. Kaenneth says:

    Shinobu, I think that’s an ‘other side of the airtight hatchway’ situation, if OS binaries have been replaced, you’re screwed no matter what you do.

    It prevents a web page, word document, etc. from spoofing the system, not the system from spoofing itself.

  24. Dean Harding says:

    It also prevents a non-Administrator from stealing the administrator’s password by spoofing the logon window.

  25. Shinobu says:

    Dean, that makes sense. Only users who can actually replace the file can spoof it.

    Kaenneth, I don’t think webpages or Word documents can do that kind of stuff anyway. Unless of course your security settings are too lax and you have a Word document with a macro inside, that replaces the task manager executable…

    In summary, it protects the passwords of administrators from non-administrators. (As long as the latter don’t have physical access to the machine and too much time on their hands, but that’s a whole ‘nother can of worms.) Makes sense.

  26. Karellen says:

    Hmmm….yes, I guess that having a single userspace process perform startup initialisation tasks, start ordinary system services, create and monitor interactive sessions/consoles, check for the secure attention key, and oversee system shutdown is a bit boneheaded. No-one with any sense would ever write an OS that did that.

  27. Matt Green says:

    Yawn, another news article with people insisting that their half-dozen is somehow better than the other six.

    Great thing about the Internet is everyone’s an expert.

  28. Raymond’s comment in the post "Winlogon is what is known as a critical system process, the death of which forces a system restart" – this was true pre-Vista.  And it wasn’t really a ‘critical system process’ – only processes marked in the EPROCESS block with the BreakOnTermination bit set to true are ‘critical’.  Winlogon (pre-Vista) was in reality ‘critical’ in that if you killed it, Smss would wake up and notice and crash the system.

    Of course, if you killed Smss first and then killed Winlogon, the system continued running just fine (contrary to Raymond’s comment where he suggests Winlogon’s death always results in a system crash).

    @Laonianren said "Early versions of NT didn’t have critical processes and the kernel would continue to run even if you killed all the subsystems" – that’s close, but not 100% correct; if you killed Csrss.exe (the Windows subsystem service process), the system would crash (from NT 3.1 through Vista/2008).  The way the system crashed changed in XP – prior to XP, it was Smss that would wake up on the death of Csrss and crash the system, so theoretically if you killed or suspended Smss, and then killed Csrss, the system would not crash (but as noted, the display went blank).

    As of XP, Csrss was marked critical with the new BreakOnTermination flag in the EPROCESS block – if you kill it (without turning off the bit), the system crashed.

    –Dave Solomon

    coauthor, Windows Internals (MS Press)

    http://www.solsem.com

Comments are closed.

Skip to main content