Why does Task Manager let me kill critical system processes?

Because you told it to.

If you run Task Manager, highlight a critical system process like Winlogon, click End Task, and confirm, then gosh darn it, you just killed Winlogon, and the system will reboot. (Assuming, of course, that you have sufficient privileges to terminate Winlogon in the first place.)

Task Manager in earlier versions of Windows would try to stop you from killing these critical system processes, but its algorithm for deciding which processes were critical wasn't very smart, and if you were sufficiently devious, you could fake it out and make your program seemingly unkillable.¹

To avoid being faked out, Task Manager simply stopped trying. Because if you don't do anything, then you can't do it wrong.


¹Of course, it was no such thing. You could still kill the program; you just had to use a program other than Task Manager to do it. (For example, you might try taskkill.)

Comments (30)
  1. mvadu says:

    Grow up Raymond.. we use Process Explorer now a days.. http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

    [I don’t recall writing, “And you should be using Task Manager instead of some other tool.” (Heck, I even linked to another tool!) I was just answering a question about Task Manager. -Raymond]
  2. Karellen says:

    Hmmm…I wonder why Task Manager didn’t just use the same algorithm for figuring out which processes were critical system processes that Windows itself uses to determine that it needs to reboot when one of them dies.

  3. SuperKoko says:

    @Karellen: Process manager isn’t a kernel driver.

    I don’t think there’s any user-space API to get this info.

  4. I get annoyed that Win2000 Task Mgr won’t let you kill a service.  I’m glad in XP and later Windows allow you to kill services.  To anyone who may say this was a bad change, as Raymond points out there are other ways of killing a process.  Also, knifes are sharp – if you are careless with them you might get cut.

    mvadu – I agree that Process Explorer is better than Task Mgr, but Task Mgr has the benefit of being installed on every system.  Anyone who’s helped a friend solve a computer problem has surely been frustrated to find all the tools they’ve come to know and love are not present.

  5. Ross Bemrose says:

    Did this change in XP?  I seem to recall that Task Manager won’t let me kill certain processes even when logged in as Administrator.

  6. mikeb says:

    Chen’s Theorem of Ultimate Optimization:

       You can do nothing really fast

    Now we have a corollary.  Chen’s Law of Provable Correctness:

       If you don’t do anything, you can’t do it wrong

    I try to apply these to all aspects of my life, not just programming.

  7. Nathan_works says:

    This probably isn’t a place for discussion about the devious ways that malware hides themselves from showing up in task manager too..

  8. anonymous says:

    If I remember correctly at some point task manager did not try – it was just unable to kill these processes because it did not assert the debug priviledge.  

  9. Jamaal says:


    Both rules are completely true, and all of the time too.

    You CAN do nothing fast, in fact you can do nothing so fast that it is instantaneous.  I bet you are doing lots of nothings really really fast right now…

  10. Puckdropper says:

    A nop instruction still takes a tiny bit of time to execute, though.

  11. anony.muos says:

    Why did Microsoft never fix the most annoying and easy to fix bug in the Windows 2000 Task manager where it limits process names to 8.3 characters?

  12. Ken Hagan says:

    "A nop instruction still takes a tiny bit of time to execute, though."

    Sure about that? On an out-of-order processor that is bottlenecked on something other than instruction decode, which is almost certainly the case these days, I think you’ll find you can’t measure the additional time taken by an instruction stream with an extra NOP.

    Random tid-bit: when Intel needed an encoding for the new PAUSE instruction, they simply stuck a REP prefix in front of the NOP code.

  13. mikeb says:

    And who says you have to use a NOP to do nothing?

  14. Dean Harding says:

    Someone: Er, they did fix it, in Windows XP…

  15. Doesn’t all this kind of beg the question:  Why would you want to kill a critical system process to begin with?

    Here, let me cut off my arm, I want to see what will happen if I do.  Whoops, that hurt…and it looks like I might bleed to death as well.  Silly me.

  16. Matt Green says:

    This thread is starting to sound like the software engineering equivalent of that plane on a treadmill problem.

  17. Koro says:

    I think in Windows XP, Task Manager must somehow acquire the debug privilege to be able to kill system processes. Because if I remember well, you can’t get a handle to them even as administrator because of their DACL.

  18. Stephen Jones says:

    I mainly use Task Manager to kill Process Explorer :)

    Process Explorer will sometimes start without a visible window (as will many other services that can’t be bought to the front). As I have it set to only allow one instance running the only way I can restart it is to kill it with Task Manager and then restart it.

  19. I might be displaying my ignorance here but why can’t this be implemented at a lower level than taskmgr?  It seems like killing a system level process is a bad thing and should require some privledge greater than admin to achieve.  A lower level could track the PID of winlogon for instance and simply refuse to kill it.  

    I realize that even a normal user must be able to indirectly stop winlogon (otherwise they coudln’t shut down).  But it seems a couple of simple controls could be implemented for those types of scenarios.

  20. Ray Trent says:

    Not a valid syllogism, nevertheless:

    A NOP doesn’t do nothing, therefore it takes time.

    It merely does nothing useful. Many electrons are still shuffled from one place to another.

  21. JM says:

    @Kevin Provance: In the course of debugging and troubleshooting, your local guru reserves the right to kill any process he wants to.

    During regular system operation, killing Winlogon isn’t meaningful. If you want to research some exotic problem that might involve Winlogon’s presence (or say you’re *developing* Winlogon and it’s running haywire), it might be. Note that you *can* abort the shutdown initiated by a critical process terminating.

  22. Bryan says:

    Sometimes NOPs are not actually NOPs.  Instead, they are just a way of telling the processor to not modify any programmer-accessible areas of the system.

    Sometimes, NOPs do small things you wouldn’t immediately expect without knowing the architecture.

  23. @Puckdropper: A nop instruction still takes a tiny bit of time to execute, though.

    Ah, you’ve stumbled onto the difference in philosophies like Zen Buddhism between "nothing" and "no-thing"… [HH.5J]

  24. Tanveer Badar says:

    nop still changes IP, no matter what you do. And if it was the last instruction on the page, it may causing paging.

  25. a p.s. – on XP/2003, Task Manager had hard coded 5 process names as "critical": Smss, Winlogon, Services, Lsass, and Csrss.

    For a laugh, copy Notepad.exe to Winlogon.exe (or any of the other names above).  Then open Task Manager and try to kill it – Task Manager says "cannot end this critical process".  Ha!

  26. @JM – you said "Note that you *can* abort the shutdown initiated by a critical process terminating."  

    Incorrect.  There is a flag in the EPROCESS (kernel process data structure) called BreakOnTermination – that’s the true "critical process" bit.  If that is set, and the process terminates or exits for any reason, the kernel bugchecks (crashes).  You can’t stop that.

    Winlogon does NOT have that bit set – Csrss does.  Pre-Vista, the reason the system crashed if you killed Winlogon is that its parent, Smss, would crash the system (which you couldn’t stop) if Winlogon exitted (it posted a wait on the process handle for Winlogon).

    As of Vista/2008, killing Winlogon simply logs off the session (since there is no Winlogon for session 0).

    On Vista/2008, Wininit (which performs the one-time system initialization role of Winlogon) is marked critical – if you kill Wininit, the system crashes.

    Services.exe and Lsass are NOT marked critical.

    It’s the death of Lsass that (assuming Wininit is not suspended) causes a shutdown – Wininit (previously Winlogon) initiates this, and it’s _this_ shutdown you can abort.

    –Dave Solomon

    coauthor, Windows Internals (MS Press)

  27. DWalker says:

    I wish people would learn that "privilege" doesn’t have a "d" in it.   sigh….

  28. JM says:

    @David Solomon: Thanks for the clarification, you just made my day! If I’m going to be corrected, I definitely want it to be by the Winternals guys. Keep up the good work on the books. :-)

Comments are closed.

Skip to main content