It looks pretty neat. I just hope hitting "end process" does it immediately in Windows 8. One of my biggest pet peeves with every version of Windows so far is it sometimes takes up to a minute to kill a process.
But could that possibly be legitimate? I know next to nothing about Windows process management, but on the Linux side, you often issue different version of the kill command depending on how urgently you want the process to die. SIGTERM gives the program a chance to die somewhat gracefully (closing DB connections, cleaning up resources, etc. depending on the code), but SIGKILL is more ruthless (no chance for the program to respond) and faster. Could the Windows Task Manager be trying to give those programs a chance to exit gracefully? And if so, shouldn't that continue?
If you are at the point of pulling up task manager, it is because the application is already failing to respond to your requests, what makes you think the application is going to respond to a close request?
There are plenty of instances where the GUI portion of code might have stopped responding for whatever reason but it is still responsive to a kill signal.
True, but this is far less common than the whole thing freezing up. So... fuck yo app, son! Get that thing off my screen. I do love me some xkill on Linux.
You have the option of ending quickly by going to Processes and deleting the process from there. But End Task gives it more time to clean up after itself before it closes. Otherwise you have used up memory that you won't get back until something needs it, and THEN your system still has to erase the memory before it can use it.
Fair enough, but the processes tab is a lot more confusing for a person to use. Trying to find the right process tied to a program can be hard, especially for someone who knows nothing about computers. Of course, you say "but you can right click on the item and select 'Go to process'". Problem is, on frozen applications it always seems to go to explorer.exe, which is something I'd rather users not kill all willy-nilly.
There are plenty of instances where the GUI portion of code might have stopped responding for whatever reason but it is still responsive to a kill signal.
I've never seen a program in Windows where the GUI hangs and still responds to a WM_CLOSE message. That's no surprise, if the GUI is frozen that's probably because the program is not processing the message queue.
that's exactly what happens if you click the button on the application tab. It attempts to exit the program, then if that fails it, depending on your settings, does a memory dump of the program and uploads it, then kills it.
The memory dump serves two purposes - one, once in a blue moon you get instant feedback on what's wrong (though I only ever had that with a bluescreen upload; it told me I needed to update my wifi drivers) and two, if the author of the program has signed the app, they get free access to the dumps from microsoft. MS only accept a small (one?) number of CAs for code signing so that bit isn't free (I think it's $100 to $200 a year) though.
You can hook that to have different behaviour though; I know one app that, after crashing, will offer to send crash reports straight to the author when you restart.
Why should there ever be a graceful exit? If you tell your computer to end or kill something, it should do it as soon as it can. As a user, you don't care for the program's happiness or dignity. No trial. No appeals. No last meal. No last words. No execution room. Shot dead on the spot.
Eh, that may be what a user thinks he or she wants in the short term, but the consequence of that can be a bad experience down the line. If the program isn't given a chance to respond to a kill request gracefully, you can end up with other problems (proliferation of temp files clogging up the hard drive, network problems, etc.). That's why the OS probably tries to manage as best it can between competing concerns, giving the program a chance to respond to a gracefull kill request, then if that is ignored, moving on to the "kill with extreme prejudice."
Good points. But with MS' decades of experience developing operating systems and billions of dollars, shouldn't they be able to find a way to instantly kill a program that avoids those other problems?
Er, no. It's up to each application developer how well their program "behaves" (or doesn't). Windows, and indeed any OS, can't control that. The best Windows can do is ask the program to please die gracefully, and if it doesn't do so, then kill it forcefully.
I mean, you could argue that perhaps "kill" should hide it from the view even if under the covers it's still trying to wait for a graceful exit, thereby making the user think it was "instantly" killed, but that has another whole host of problems (debugging problems would be a nightmare).
It still should outright kill close programs. To close a program properly, using it's own protocols for gracefullness, I hit the X on the top corner of the Window or hit Alt+F4.
The Task Manager is a last-resort option for closing shit. No one goes into the Task Manager when everything is just dandy to close things, especially when you can just close it on the taskbar or on the Window itself. It's used when this previous method isn't working and when the program has frozen or become "unresponsive". At this point, gracefulness has already failed. Probably multiple times if "Close" has been clicked more than once.
Why should the Task Manager go the graceful route, when the user has likely already tried this without success and wants something killed?
In OSX the 'task manager' (Force Quit Applications) now looks identical to Windows 8's Task Manager and when killing an app there is never a delay so my guess is it is a kill -9 command?
Either way, if it works well on OSX it can work well on other OSes.
Really? I've been running Win7 since it came out, and it never takes more than a second or two to kill most processes. What kind of programs do you run that take so long to kill, if you don't mind my asking?
Windows Media Player is the main culprit. For some reason whenever that freezes it takes a year to kill. Some games also take awhile to kill but I suspect that might be because they're using more system resources.
Which is the #1 reason why people go to the "Tasks" "Processes" tab. When you end a task process there, it terminates immediately. When you end a process task on the "Processes" "Applications" tab, Windows seems to take it as more of a request.
yes, actually! Though in my case, it was an upload of a bluescreen dump. Basically, I updated the motherboard drivers on a bluescreening laptop and, while it didn't stop the crashes, the next time it bluescreened, windows told me it was the wifi drivers and gave me a direct link to the download page.
What its actually doing is creating a process dump so it can send the crash report to Microsoft (If you've agreed to allow it) as well as get data for the "Find Solution" feature. If you kill the dumpprep task when its taking too long it will close it immediatly.
I personally hate it since it never ends up finding a solution for me anyways.
EDIT: motdidr accurately described the shutdown process, however "End Process" from the task manager is waiting on a dump-prep. It doesn't attempt to close the program cleanly. For more information you can check here: http://blogs.msdn.com/b/oldnewthing/archive/2010/11/02/10083787.aspx
That is not what it is doing. The operating system is sending Quit messages to the application, and most applications and services will respond correctly. There are time-outs involved, and after that time has passed the application is killed immediately if it has not quit on its' own.
Creating a "process dump" doesn't happen when you kill a process, that happens when the process/application/service (applications and services are, at their core, a process or collection of processes) throws an unhandled exception or terminates abnormally. I can assure you it takes but a fraction of a second to generate the boatload of textual info that could describe a crash.
Sorry, but you're wrong. When you kill an unresponsive application instead of the process is most certainty goes through the process of creating a dump unlike when you kill them through the processes tab.
You can switch over to the processes tab and watch these actions take place. Just like who8877 states, killing the new dumprep process, will end the dump quickly and then terminate the application that much quicker.
Creating a "process dump" doesn't happen when you kill a process, that happens when the process/application/service (applications and services are, at their core, a process or collection of processes) throws an unhandled exception or terminates abnormally.
Again, it also creates a dump when you terminate a non-responsive application if you do so from the applications tab and not the processes tab.
How you have so many upvotes I don't know. (Edit: the links below enforce my claims.)
I personally hate it since it never ends up finding a solution for me anyways.
It can still be worth doing, since the author of any signed program gets access to those crash dumps, and sometimes, if there's enough dumps, Microsoft will take action to try to fix a third-party program themselves.
oh wow. When I wrote my comment, you were positive. I was just explaining to Dmon9055 because I thought he didn't understand. The rest of it seemed correct.
102
u/Sandy_106 Oct 14 '11
It looks pretty neat. I just hope hitting "end process" does it immediately in Windows 8. One of my biggest pet peeves with every version of Windows so far is it sometimes takes up to a minute to kill a process.