In Windows Power Tools, "PsExec" (July 2004), I described how to use one of the Sysinternals PsTools suite's 11 tools. I continue my coverage of the suite this month with two tools that work great together: PsList and PsKill. PsList prints information about the processes running on a system, and PsKill lets you terminate processes. The PsTools are all console applications, work on remote systems as well as local ones with no need to manually install software on the remote systems, and support Windows NT 4.0 and later. You can download the tools for free from www.sysinternals.com.
Several command-line process-listing utilities are available for NT-based systems, each with varying capabilities. Tlist, for example, comes with the Support Tools for Windows 2000 and with the Debugging Tools for Windows Server 2003 and Windows XP, but it has no remote capability and shows limited information about a process. Tasklist, a tool introduced and bundled with XP, shows more information and works remotely but doesn't work on NT or Win2K. The Windows 2003 and Win2K resource kits also have several tools, but they suffer similar limitations.
PsList works in mixed-installation environments and provides process details not available with other tools. Figure 1 shows the tool's usage information. PsList doesn't require you to be running in an administrator account to use it. If the account from which you run the command isn't valid on a remote system, you can use the -u and -p switches to specify alternative user ID and password credentials on the command line.
If you run PsList without modifying options, it dumps a list of the processes running on a system with statistics for each process, as Figure 2, page 84, shows. The information is, from left to right, the process ID, priority class, number of threads, number of handles, private virtual memory allocated, amount of CPU time consumed, and time running. Excessive handle counts, high private virtual memory usage, and high CPU times can flag buggy applications. The time that a process started can connect the process with the action that started it, such as logging on.
Three switches (-m, -d, and -x) cause PsList to dump different types of process information. Use the -m switch if you want details about virtual and physical memory behavior. The data PsList presents includes the total virtual memory (shared and private) consumed by the process, the amount of physical memory assigned to the process, the private virtual memory allocated by the process, the peak amount of private memory allocated, the number of page faults, and the nonpaged and paged pool allocated by the process.
Processes that leak memory almost always do so by consuming and not releasing private virtual memory, a resource that the paging file must back and that is therefore finite. Leakers typically have ever -increasing private virtual memory allocation, and their peak amount of private memory allocated is a value that's always nearly the same as the current allocation. Task Manager's default memory number is the process's physical memory consumption (not virtual memory consumption), which isn't the correct indicator for a memory leak.
The -d switch shows details about the threads running within processes, including the context switches performed by the thread, the state of the thread (e.g., running, waiting), and the amount of CPU time consumed by the thread. Finally, the -x switch dumps process, memory, and thread detail.
Another switch that can prove useful is the -t switch, which causes PsList to dump the list of processes in process-tree format, which Figure 3 shows. A process tree is the structure that's built as processes create other processes; processes directly beneath another process and indented a few spaces to the right are descendants of the other process. Seeing processes in process-tree format can help you understand a process's purpose. For example, all processes that are children of SERVICES (i.e., the Service Control Manager) host Windows services. Figure 3 shows descendant processes listed and indented under the SERVICES process.
Dumping a static view of all the processes on a system can be useful for auditing purposes or just to get an idea of what a machine is doing; however, a dynamic view of activity is usually more enlightening. When you use the -s switch, PsList updates displayed information at a default rate of once per second; you can use the -r switch to change the refresh rate. When you use only -s or only -s and -r with no additional options, PsList lists the active processes sorted by CPU usage, which effectively makes PsList a lightweight, remote Task Manager tool. PsList calculates CPU usage by comparing two updates, so the CPU usage column isn't updated until the first refresh interval expires. To exit PsList and return to a command prompt, press the Esc key.
The default view when using -s or -s and -r is useful for tracking down CPU hogs, but if you suspect a process is leaking memory, use -s in conjunction with the -m switch. This combination results in process memory statistics in which the processes are sorted by the amount of private virtual memory they've allocated. Figure 4 shows PsList revealing a leaking process. The Leakyapp process has a private virtual memory value that has grown over time and now equals the peak private virtual memory value.
If instead of monitoring process activity, you want a process listing that reflects CPU usage, you should follow the -s switch with 2, which indicates the number of seconds PsList should run before exiting:
Two seconds gives PsList enough time to calculate CPU usage. If you send the output to a file for archiving, you'll see two process snapshots in the file; the second snapshot shows the process list sorted by CPU usage.
Looking for a Process
PsList takes a process name or a process ID in combination with any of the other command-line options it supports so that you can focus your investigation on one or more particular processes. For example, if you suspect that a process named Leakyapp is leaking memory, you can enter the command
and watch for changes to the process's private virtual memory allocation. You can also take advantage of PsList's process-specific behavior to write batch files that perform operations based on whether a process is running: PsList returns an error code of 0 if it finds a process that matches the name or PID you specify and an error code of 1 if it doesn't.
How PsList Works
Because I wanted PsList to work with NT 4.0, the tool can't use Windows Management Instrumentation (WMI) the way Tasklist does. Instead, PsList relies on the Performance API, the same API that the Performance Monitor tool uses. Because the Performance API supports a remote interface, PsList doesn't require you to install any special software on the remote systems that you want to monitor. Unfortunately, the Performance API doesn't provide all the information that WMI does, so unlike Tasklist, PsList can't obtain the user name of the account in which a process is running or the list of DLLs loaded into a process.
Often, when you display running processes, you see one that you want to stop. The PsKill tool fills that need. The tool takes either a process name or a process ID and terminates all matching processes on the system you specify.
Unlike PsList, PsKill requires that the account from which you run it have administrative privileges on the system you target. This requirement results from the fact that to operate remotely, PsKill, like PsExec (which I described in July), extracts a service from its executable image and copies it to the remote system through the admin$ share, starts the service, sends instructions about what to terminate, and uninstalls and deletes the service after the command has finished. If you need to, you can use the -u and -p switches to specify alternative credentials.
I'm always looking for interesting, real-world examples of PsTools usage that I can share with others. Please send me any stories you have about problems you've solved by using any of these tools.