How to get process information with Windows PowerShell
In this column, Christa Anderson explains how to use Windows PowerShell's get-process cmdlet to retrieve information about the processes on your computer and how to kill the unnecessary ones.
Previous Scripting School columns have discussed how to collect user input, assign it to a variable, and report variables surrounded by helper text. This column will explain how to retrieve basic information about processes on your computer and how to kill the processes you don't want using Windows PowerShell.
Retrieving information about processes
To help you retrieve information about the processes on your computer, Windows PowerShell includes a get-process cmdlet. Run it without parameters, and you'll receive output that looks like:
Handles | NPM(K) | PM(K) | WS(K) | VM(M) | CPU(s) | ID ProcessName |
------- | ------ | ----- | ----- | ----- | ------ | -- ----------- |
21018 | 4 | 2084 | 5036 | 35 | 1.84 | 496 1XConfig |
103 | 5 | 1156 | 3560 | 32 | 0.08 | 2308 alg |
69 | 2 | 604 | 2336 | 19 | 2.52 | 1176 ati2evxx |
66 | 2 | 572 | 2216 | 19 | 1.58 | 1772 ati2evxx |
668 | 8 | 3384 | 7592 | 63 | 25.98 | 1512 csrss |
108 | 5 | 940 | 3756 | 35 | 0.95 | 2220 ctfmon |
NPM? WS? VM? For those who aren't sure what these abbreviations stand for, this table can help:
Resource Name | Abbreviation | Description |
Handles | none | Number of smart pointers a process has opened to storage areas in memory. When handles close, the memory is released. |
Non-paged pool (in kilobytes) | (NPM, for non-paged memory) | Non-paged pool is memory storage that is never paged to the hard disk, so it's more quickly accessible. |
Paged pool (in kilobytes) | (PM, for paged memory) | Paged pool may be sent to disk if space is required. This makes paged pool effectively larger than non-paged pool (since the storage is limited only by the page file on disk). Some memory reads may take longer because the data requested is now stored on disk. |
Working set (in kilobytes) | WS | The working set is the set of pages of physical memory that a process is using. Only data stored in physical memory (not currently paged to disk) is in the working set. |
Virtual memory (in megabytes) | VM | The amount of virtual memory committed for the process's sole use. |
CPU time (in seconds) | CPU (s) | The amount of processor time the process is using (on all available processors). |
Process ID | none | Unique identifier for a given process. Even on a shared computer, only one process will have a given process ID. |
Process name | none | Friendly identifier for a process, but unlike Process ID, not necessarily unique. |
Note: There's quite a few more process properties available to you. To see them all and get their property names, type get-process | get-member. The basic list is sufficient for our purposes today, but you'll need to see the complete list in order to work with the process properties.
How to retrieve highest-load processes
You don't necessarily need a list of all the processes, but you will need a general idea of which processes are consuming the most resources. For example, a working set (see box above) of a processes serves as a good indicator of its memory stress on the system. To find all processes with a working set greater than 10MB, type the following command:
get-process | where-object {$_.WorkingSet -gt 10000000}
Remember that dollar signs indicate variables. We're looking at the process name, its working set property and whether its working set is greater than (gt in the above command) a given size.
This command finds every process and then sends this output to the where-object cmdlet for evaluation. You'll then receive a list formatted exactly the way it was in the complete list, but this list is much shorter.
Killing unnecessary processes
If you're managing your own computer, it's easy to acquire useless processes. Spend a day in the airport when you need to be online, and you could end up with a Boingo client. Downloading a trial version of some system auditing software? Your process list might include a system auditing agent even if you haven't used it for months.
More on Windows PowerShell
Read Christa's other columns on Windows PowerShell.
Visit our topical resource center and find news, tips and expert advice on Windows PowerShell.
Compare Windows, PowerShell, and Bash here.
Granted, Task Manager will show you the same thing, but there's something about get-process that makes the data easier to look at, even if it's only that you can see a complete list without scrolling. You need to dispose of these junk processes (and you will) but in the meantime you can also kill them. (Be sure you know what you're doing before you terminate a process. If you're not certain what a process does, don't kill it.)
To kill a process, retrieve a list of processes and their identifying information from the entire list or a Top Ten list of the most resource-hungry processes. Next, run stop-process. If run without parameters, it will prompt you for the process ID. (Merely typing the name won't kill the process.) You can kill as many processes as you like. When you're done, just press Enter and the cmdlet will exit.
You can also stop processes by name using the –name parameter, stop-process –name processname. However, I don't recommend it. You should develop the habit of killing processes by process ID. Although it's harder to remember a process ID than a process name, this will help you avoid killing someone else's process on a shared computer.
About the Author: Christa Anderson is the author of Windows Terminal Services and The Definitive Guide to MetaFrame XP. She is also co-author of the book Mastering Windows 2003 Server.