Tag Archives: Command Line

How to kill windows tasks, even those that just won’t die

I recently created a video that shows how to kill tasks via the command line, and if that doesn’t work, how to kill them via Process Explorer, and if that doesn’t work how to disable them using the Services window. It’s embedded just below, but if you’re not in a video mood, fear not! I have summed up its contents, although the video shows you the steps and comes complete with witty commentary.

If you’re running Windows, any version of Windows, you know there are what seems like thousands of things going on in the background. All you have to do is bring up the Task Manager ([Ctrl]-[Shift]-[Esc], or the well-known [Ctrl]-[Alt]-[Delete] if you’re old-school and enjoy the extra steps) and you’ll come face-to-face with the process party happening inside your machine.

Task Manager - Hello, running tasks!

Task Manager – Hello, running tasks!

As you may also know, each of those running tasks requires some of your machine’s resources; sometimes a little, sometimes a lot, and you can see in Task Manager how much of each resource each process is using. If the process is something you don’t use or don’t need, then it’s not a bad idea to stop the process and recover whatever amount of system resources it’s hogging to itself, and it even turns out that while taking the above screenshot I happened to notice Windows’ Photo App, Movies & TV app, and Messaging app were taking up a lot, so away they went! Right-clicking brings up a menu that allows you to ‘End Task.’

But that’s also where an insidious problem lies. Sometimes, when you right click and select End Task, the task just doesn’t end. This can manifest in a couple of ways: The task may continue to run, mocking and taunting you to click End Task again, reveling in your failure to stop it. It might stop for a moment, only to reappear a second later, better, stronger, faster (not really better or stronger or faster, but it will reappear).

This even happens when using the command line to kill tasks. Normally this is done by listing the running tasks using tasklist, then, once the Process ID (PID) is known, using taskkill /PID actualPID, however even here that doesn’t guarantee a termination, with a similarly mocking response from your system.



Why does that happen? The main but not necessarily only reason is that it is actually part of a complex hierarchy of tasks that prevent it from being shut down. Either it is a child spawned from a parent process and upon being stopped, the parent just restarts it, or it’s a parent process that can’t be terminated because we can’t have orphaned tasks.

To determine which of these is the case, I am a big fan of Process Explorer, part of Microsoft’s SysInternals software suite that helps maintain and monitor Windows. If you click on the link, you can see in the left-hand sidebar the other packages available; They’re quite comprehensive.

Process explorer shows you everything that is going on, how many resources are being used by each process including specific and shared memory, the Process ID (PID), the name of the company that developed the software, it color codes by category, it’s a great program that shows a lot and really gives an idea of not just what is going on but how it all relates.

Process Explorer

Process Explorer

You can see that some processes are child processes and some are parent processes and whether you can or can’t kill a process is very dependent on the nature of that hierarchy. Trying to stop a task even here will prove futile as the hierarchy is the same. Interestingly, in Task Manager right clicking gives the option to End Task, while in Process Explorer it gives the option to Kill Task. Hmm. The deeper we go, the more violent we get.

Ultimately, if you really want a process to not run, you should first make sure it’s not something you need. Google, even Bing, is your friend. If you are certain the process is just leeching resources, then you’ll have to go into services.msc, which you can run by typing it in to the search bar there by the start menu, and disable the service by right-clicking the service and selecting Properties, then Startup Type. Don’t set it to Automatic, obviously, or even Automatic Delayed Start, but also don’t set it to Manual, because then it will just start up again if the system decides it’s needed. Be sure to set it to Disabled.



Set Startup Type to 'Disabled'

Set Startup Type to ‘Disabled’

That will stop the process from starting up, even if the system thinks it should. Remember, though, that if you *do* end up needing the service, you’ll have to go back into Services.msc and start it up yourself again, as this shuts it down completely. And I have to say it again: be careful about disabling processes. If you disable one that you need, or worse, the system needs, you may find your device acting very strangely, or in a worst-case scenario, software or even hardware not working at all. Even if you don’t disable anything, this is a good way and a good opportunity to learn what your system is actually doing.

And here comes PowerShell!

DOS Prompt

I love the DOS prompt. I really do. I have books about it, watch videos about it, and teach HCI students about how many of the conventions used in the Graphical User Interface (e.g. cut/copy/paste) are taken from the command line, which were themselves taken from manual conventions used with typewriters (when typists made an error, they would often type the intended word on a separate paper, cut it out with an X-acto knife, and paste it over the mistyped word on the original document).

Although I frequently criticize techy types for being unnecessarily proud of their cult-like, obtuse, user-unfriendly platforms that require deep-dive understandings of underlying technology to get them anywhere close to working (I’m looking at you, FreeNAS and DD-WRT), I have to give the command line credit as it was all we had back then, we didn’t use it for bragging rights, and it worked well enough at the time while requiring some understanding of the underlying machine and software architecture.

However, it appears that the command line is being pushed to the back row. You’ll notice in the image below, which is of my very own Windows 10 Start context menu which appears when right-clicking on the start menu, there is the option for command prompt and command prompt admin.

Win 10 context menu

Win 10 context menu

In the following image, though, taken from a PCWorld post about the most recent Windows 10 Insider Build, Build 14971, you can see that the entries for command prompt are no more, and instead have been replaced with PowerShell.

Windows 10 Power Shell entries

Windows 10 Power Shell entries (credit: PC World)

What is PowerShell you might ask? If you were to just look at it, it might not look all that different from a standard command line. In fact, it IS a command line. However, rather than carrying out one command at a time as is typical with traditional command lines, hence their name, PowerShell allows for a host of capabilities that would be very difficult – although not impossible – via traditional command line commands. It allows for system and network/remote management, as well as scripting functionality supported by the .NET platform. It has many functions, which is also why the name PowerShell is both accurate and misleading.

You see, a shell is a command line. We’ve been using shells forever now, they even have allowed for the authoring of some basic scripts called batches in which a bunch of commands run all at once, but they were also very limited in the universe of the GUI. When a criminal attempts to put malicious code into or onto a system in the hopes it will run, that is often known as shellcode because it provides command-line access to the compromised system (if you’re interested, this is most commonly done through buffer/stack overflow attacks, of which there are many different kinds). Even PowerShell itself has been around for a long time. These types of interfaces have been a staple of computing since the birth of the PC and before.

PowerShell is powerful, and has extensive capabilities that make it as useful as a GUI if you know how it works. Why not just use the GUI? Because a command line interface doesn’t use nearly the resources of a GUI, can run on a low-power system, gives much finer and more focused control than a GUI, and a command line interface won’t crash. You can see that I appreciate the power of the command line, and while I have nothing against PowerShell specifically, I also see it as the end of an era. The DOS prompt was so insanely unintuitive, yet comparatively simple as well; a true paradox. In PowerShell’s defense, here is a screenshot from the carlwebster.com blog showing it running a script that displays firewall rules. And that is just one example of the infinite amount of ways in which it can be used.

PowerShell showing firewall rules

PowerShell showing firewall rules

Apparently ‘Command Prompt’ can be brought back to the context menu through taskbar personalization settings so I may do that when the update finally rolls out, but I also want to give powerShell a chance – I haven’t used it that much but use the command prompt extensively, so who knows, maybe it will all be for the best. I’m approaching it with an open mind, and I’ll post my thoughts here when I’ve had the chance to work with it for a bit.