Why does ending a task from task manager work better than canceling a program?

770 views

When a computer starts to freeze or operate slowly and doesn’t respond, ending the task(s) from the task manager usually ends the program and the problem. Why does this work better than simply canceling the task with ALT+F4/pressing the cancel button in the window?

In: Technology

26 Answers

Anonymous 0 Comments

[I think the man himself answers this most effectively](https://www.youtube.com/watch?v=f8VBOiPV-_M)

Anonymous 0 Comments

When your wife texts you it’s time to leave the bar you close your tab, get your credit card back, put on your jacket, take a leak on your way out. When your wife texts the bouncer she knows he picks you up and throws you out of your ass. Option two is faster, but not always better.

Anonymous 0 Comments

The real ELI5 explanation: Pressing the close button is like asking you to leave the room. Using the task manager to end an application is the same as your parents dragging you out of the room.

Anonymous 0 Comments

Pressing the X is like telling someone to leave. Ending the task is like physically removing them.

When you press the X, you’re telling the program to shut down. When you end task, you’re telling your computer to stop running the program.

Anonymous 0 Comments

Computer engineer here!

When you exit a program, it tries to do some clean up before it shuts down completely. If the program is already having problems, it may not even recognize that you asked it to shut down and never gets to that step. As a result, it either doesn’t quit or it takes a long time.

One of the things your operating system does is pause and resume different programs really quickly so that you can run multiple things at one time (like listen to music and surf the internet). When you kill a task through the task manager, you are telling the operating system to remove that task from its todo list and give back the RAM.

Anonymous 0 Comments

One you ask politely for it to leave and wait for it to get its luggage, fill it and calmly leave.

The other you kick it out the door and burn its belongings.

Anonymous 0 Comments

It doesn’t. Killing a program this way is like stopping a car by firing a rocket at it instead of turning the traffic lights red.

You stop the car both ways, but one way is guaranteed to be ok to drive after, and the other might not depending on if your rocket hit the car or just the road in front.

Anonymous 0 Comments

I’ll just throw in a Linux reference (I don’t know if this also applies to windows).

There are 3 main ways to terminate a program in Linux: from the program itself, with a signal, hard kill.

Within the program: programs often look for you to ask it to close. That might be pressing a key or clicking a button. The program has to specifically look for that happening. Sometimes there’s a bug in the program and it forgets to check for your request. In that case clicking the button or hitting the key does nothing.

Signal: the OS can interrupt the program and tell it to do something, this is called a signal. Signals can be sent in multiple ways, but the command “kill” is the typical way from the command line (despite the name, kill can send lots of different signals, not just the one for kill). Even if the program is stuck doing something, the OS forces it to stop that and do something else. That something else is called a handler and the program decides what it is. On Linux, the signal that tells the program to shut down is called SIGTERM. If all goes well, the program stops what it’s doing (even if there’s a bug and it normally couldn’t stop) and tries to shut down cleanly (just like the “within the program” case). The big difference here is that the OS interrupted the program rather than the program checking for your request itself.

Hard kill: if both of the above fail, it means the program has a big problem and can’t be trusted to shut down. In this case, we’re not even going to ask. No buttons, no signals. The OS just stops the program in its tracks and removes it from memory. This is done using another signal called SIGKILL. This signal is special because the program never even sees it, the OS does everything.

We prefer the first two methods because the program might want to save open files and generally clean up after itself. The last one is a last resort since the program doesn’t have a chance to do anything before it dies.

Anonymous 0 Comments

The simplest version is that the operating system controls virtually all access between software and the hardware. The application itself can send instructions to the operating system to say “Hey, I’m good to shut myself down”, which the operating system will then accept and process…killing the task. If you use Task Manager, you are more closely interacting with the operating system itself (technically, using a different application with higher privileges) – and your instruction is to “stop executing that task”, which the OS is happy to oblige, usually, and usually quickly.

The reasons why Task Manager is quicker at the job:

* if the application has any house cleaning to do before it shuts down like freeing up used memory or saving inprogress files it will complete them before asking to be shut down
* if it’s busy doing …whatever it is that it is supposed to do…or if anything has gone wrong and it’s stuck in an infinite loop – there may not be enough instruction cycles left for it to actively monitor the X button for clicks, so it never, or very slowly queues the command to shut itself down.
* Task manager doesn’t care about those things – it just looks at the list of tasks that get allocated processor time, and removes the task/threads associated. That program ceases to exist.

When you say ‘work better’ – it works better at killing the program more quickly, but can do damage to files that may be in the process of being written, only getting part of the data computed or stored before the app stops.

Anonymous 0 Comments

The guy who wrote task manager has a YouTube channel and made an episode about this. Search for Dave plummer.