You're viewing a single thread.
I have encountered processes that even Task Manager could not kill.
All the damn time. I typically use Linux, so having a process I can't even force kill is a severely annoying concept.
This has happened to me only once on Linux. I still tell stories about it.
It was a CD burning program stuck in uninterruptible sleep! Trapped in a system call into the kernel that can never be interrupted by a signal, it was truly unkillable. The SIGKILLs simply piled up never to be delivered.
THIS is your big "You won't believe what happened to me...." story???
sigh
When I was 14, I took the power cord for the original PS1 and shaved the rubber off the end until metal prongs were sticking out. Then I noticed if the outlet end was plugged in, and you touched the metal prongs on the other end, you couldn't drop it. It would electricute you, but it would also stick to your skin for 5-10 seconds as it electricuted you.
So being a 14 year old male, I did the only logical thing. I put it on my penis.
It was quite shocking!
I used to stick forks in the electrical outlets.
Now I post Linux memes.
That tracks.
I can't believe what happened next
I....can't tell what is happening here. Is he having an orgasm? Is he supposed to be a priest, or a slave?
That's Frodo Baggins on the verge of death thou fool!
I don't recall. Just having fun. Be well!
I would assume that was a kernel issue.
In this case it was a driver holding that thread captive and making an assumption about the hardware eventually responding to a request which never completes.
So yes indeed it was the kernel, and ideally the driver could be written better, but that’s probably easier said than done when the hardware can do weird things.
This was a long time ago, so for all I know the issue has been long corrected.
It honestly was the thing that pushed me to Linux. Once I could no longer kill programs at-will I couldn't handle it. xkill ftw.
Yeah... It doesn't happen often and when it does, it's usually a driver and/or hw issue that is likely to leak memory and/or hold file descriptors but procs in
D(uninterruptible_sleep) state do happen. It's really obnoxious that murdering them withSIGKILLdoes nothing.
A while ago I kept a shortcut in the taskbar that ran a batch file that killed any unresponsive task, worked even on those tasks that Task Manager can’t seem to close. As long as explorer was still running and I could alt tab and press that button it worked 100% of the time
How do you determine if a task is unresponsive?
It was something like this. It would just kill all tasks that haven’t responded in X amount of time. Obviously this is not a great solution as it can cause data loss and you could accidentally close more than just the program you intend to close, but sometimes you have little choice.
That's proper mental, I don't know why you'd keep that running unnecessarily (unless fiddling with something you can easily replicate).
Im pretty sure it's still not going to catch the stuck things that aren't actually killable
It wasn’t something I kept running, just a shortcut that would run the batch file and kill anything that wasn’t responding at the time. I’m not sure if this uses the same command I had set up at the time, but I remember it having a 100% success rate. I had it for one game in particular which would crash and stop responding but any attempts to get to the task manager (even with keyboard) would fail.
I haven’t had to use anything like this since Windows 10 as now you can just press Windows+Tab and move the task to a different desktop and then get into the task manager on your original desktop.
But I also remember the times when there was no foe Task Manager could not kill.
“This computer is hereby deconstituted.”