Windows Power Tools, "PsExec" (July 2004, InstantDoc ID 42919), 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
PsList works in mixed-installation environments and provides process details not available with other tools. psList Screenshot 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.
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:
pslist \\remote s 2
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 \\remote s leakyapp
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
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.