The Old New Thing

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

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.

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

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

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.

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.

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.

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

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.  

@mikeb  

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...

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

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?

"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.

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

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

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.

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

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.

http://blogs.technet.com/markrussinovich/archive/2005/07/24/running-windows-with-no-services.aspx

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.

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.

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.

@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.

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.

@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]

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

@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)

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!

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

@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. :-)

PingBack from http://www.microsoftconfidential.com/2008/10/21/raymond-chen-ftw/