Colored rows and heatmap columns - sysinternas
Process list
Each row in the process list represents a running process on the local computer. Actually, that’s not technically accurate. As my friend and Windows Internals co-author David Solomon likes to point out, processes do not run—only threads can run. Threads—not processes—are the entities that Windows schedules for execution and that consume CPU time. A process is simply the container for a set of resources, including one or more threads. It’s also not accurate to refer to “active processes” or to “processes with running threads,” because many processes spend most of their lifetimes with none of their threads running or scheduled for execution. So each row in the process list really represents a process object on the system that has its own virtual address space and one or more threads that conceivably could execute code at some point. And as we’ll discuss later, the first few rows in the default (tree) view are exceptions. Going forward, I’ll refer to them as running processes.
Colored rows and heatmap columns
A heatmap graphically highlights larger values in a table with shading or with different colors. The CPU Usage, Private Bytes, Working Set, and GPU Usage2 columns each show a pale shade of a distinct background color. For example, the CPU column is a very light green. When a process consumes a significant percentage of the resource’s availability, Procexp highlights that number with a correspondingly darker background shade. In Figure 3-2, you can see how the darker shades in the CPU and memory columns call your attention to the two processes consuming those resources. Similarly, the column headers’ shading corresponds to the systemwide consumption of that resource. For example, the Working Set column header’s background color becomes darker when total working set usage increases, even if no single process is consuming a significant percentage of working set. You can disable the heatmap feature by unselecting View | Show Column Heatmaps.
2 The GPU Usage column is not displayed by default.
Although you can configure which process types and states are highlighted and in what row color, these are the defaults:
3 According to the IsImmersiveProcess API.
If a process belongs to more than one of these color categories, the precedence order is Suspended, Immersive, Protected, Packed, .NET, Jobs, Services, Own Process. For example, if a process hosts a service and uses the .NET Framework, Procexp applies the highlight color associated with .NET processes because that has higher precedence than Services. Procexp requires administrative rights to recognize a packed image, a .NET process, or association with a job if the process is running at a higher integrity level or in a different user account from Procexp.
In addition to highlighting process types, Procexp highlights new processes and processes that have just exited. By default, when Procexp identifies a new process, it highlights its row in the process list with a green background for one second. When a process exits, Procexp keeps it in the list for one second, highlighted in red. Note that even though the process appears in the list, if it is highlighted in red, the process has already exited and no longer exists. You can configure how long the “difference highlight” lasts by choosing Difference Highlight Duration from the Options menu and entering a number from 0 to 9 in the dialog box. (See Figure 3-3.) Note that the actual duration also depends on the Procexp refresh interval. The difference highlighting changes only when the display is refreshed.
To change whether a process type or difference is highlighted and in what color, choose Configure Colors from the Options menu. As indicated by Figure 3-4, you can enable or disable the highlighting of changes or process types by selecting or clearing the corresponding boxes. New Objects and Deleted Objects also refer to items appearing in the DLL view and Handle view. Relocated DLLs, which is not selected by default, applies only to DLL view. Click the Change button to display a color-picker dialog box to change the highlighting color for the corresponding highlight type. By clicking the Change button next to the
Graph Background option, you can change the background color for all of Procexp’s graphical representations described throughout this chapter. The Defaults button restores Procexp’s default colors but leaves the check box selections as they are.
Updating the display
By default, Procexp updates dynamic attributes in the display once per second. Dynamic attributes are those that are likely to change regularly, such as CPU time. You can pause the updating by pressing the space bar; pressing space again resumes the automatic refresh. (Procexp’s status bar indicates when updating is paused.) You can trigger a one-time update of all the displayed data (dynamic and static attributes) by pressing F5 or clicking the Refresh icon in the toolbar. Finally, you can change the automatic refresh duration through the Update Speed submenu of the View menu. The available intervals range from 0.5 seconds to 10 seconds.
Manually updating the display combined with difference highlighting is a great way to see all new and deleted objects across a time span of your choosing. Pause the update, perform actions on the system, and then press F5 in Procexp.
You can choose to display many more attributes, which will be described in the “Customizing column selections” section later in this chapter.
You can resize columns by dragging the border lines in the column headers. You can autosize a column to its current content by double-clicking the border line to the right of the column title. And you can reorder columns—except for the Process column, which is always the leftmost—by dragging the column headers. The Process column is also always kept in the view; if the other columns are wider than can fit in the window, they can be scrolled horizontally.
Clicking on a column header sorts the table by the data in that column in ascending order. Clicking the same column header again toggles between ascending and descending order. For example, clicking on the CPU column to get a descending sort shows the processes consuming the most CPU at the top of the list. The list automatically reorders at each refresh interval as different processes consume more or less CPU. Again here, there’s an exception for the Process column.
One hidden trick in Procexp is that in both the main window and in the lower pane, pressing Ctrl+C copies the content of the selected row to the clipboard as tab-separated text.
By default, Procexp displays processes in a tree view, which shows the processes’ parent/child relationships. Whenever a process creates another process, Windows puts the process ID (PID) of the creating process (the parent) into the internal data structure of the new process (the child). Procexp uses this information to build its tree view. Unlike in UNIX, the process parent/child relationship is not used by Windows, so when a process exits, processes it created are not updated to identify another ancestor. In the Procexp tree view, processes that have no existing parent are left-aligned in the column.
You can collapse or expand portions of the tree by clicking the plus (+) and minus (–) icons to the left of parent processes in the tree, or you can do it by selecting those nodes and pressing the left and right arrow keys. Nodes that you collapse remain collapsed if you switch to an ascending or descending sort on the Process column or any other column.
Clicking the Process column header cycles through an ascending sort by process name, a descending sort, and the tree view. You can also switch to the tree view at any time by pressing Ctrl+T or by clicking the Show Process Tree toolbar icon.
Tooltips
By default, hovering the pointer over any process name displays its command line and the full path to its executable image, if Procexp can obtain that information. As mentioned earlier, obtaining that information can require administrative rights in some cases. The command line and image path are not shown in the tooltip if the corresponding columns are enabled for display. Likewise, if the Description or Company Name column is not enabled, the tooltip displays that information.
The tooltip shows additional information when possible. For example, when you hover the pointer over a service process, the tooltip lists the display and internal names of all the services hosted within that process. Hovering it over a WMI Provider Host (WmiPrvSe.exe) process shows the WMI providers, namespaces, and DLLs in that instance. The tooltips for different operating systems’ task host processes—such as taskeng.exe, taskhost.exe, taskhostw.exe, or taskhostex.exe—displays the tasks running within it. And hovering the pointer over a “modern” app on Windows 8 or newer shows its full package name.
If the process has a user-defined comment associated with it and the Comment column is not selected for display, the comment also appears in the tooltip. (A user-defined comment can be entered in the Image tab of the process’ Properties dialog box. See the “Process details” section later in the chapter for more information.)
System processes
The System Idle Process (called just “Idle” by some utilities) has one “thread” per CPU and is used to account for CPU idle time when Windows is not running any program code. Because it isn’t a real process, it doesn’t have a PID—there’s no PID 0 in Windows. However, because Task Manager shows an artificial System Idle Process and displays 0 in its PID column, Procexp follows suit and assigns it PID 0.
The System process hosts only kernel-mode system threads, which only ever run (as you might expect) in kernel mode. These threads typically execute operating system code from Ntoskrnl.exe and device driver code.
The Interrupts pseudo-process represents kernel-mode time spent servicing interrupts and deferred procedure calls (DPCs). Procexp represents Interrupts as a child process of System because its time is spent entirely in kernel mode. Windows does not charge the time represented by this pseudo-process to the System process nor to any other process. Older versions of Task Manager incorrectly included interrupt and DPC time in its numbers for the System Idle Process. A system with heavy interrupt activity would therefore have appeared to be idle according to Task Manager. If you have a high interrupt or DPC load, you might want to investigate the reason by using Xperf to trace interrupts and DPCs or Kernrate to monitor kernel-mode CPU usage. For more information about interrupts and DPCs, see Windows Internals.
Startup and Logon Processes
From the time Windows starts until the first user logs on, there’s a well-defined sequence of processes. By the time you log on and are able to see the process tree in Procexp, some of these processes have exited, so the user shell (typically Explorer.exe) appears on the left edge of the window with no parent process. For much more information on the startup and logon sequences, see Windows Internals.
As shown in Figure 3-5, the System process starts an instance of Smss.exe (the Session Manager), which remains running until system shutdown. That Smss.exe launches two new instances of Smss.exe, one in session 0 and one in session 1, which create processes in their respective sessions. Both of these instances end up exiting before a user logs on, so the initial Smss.exe always appears not to have child processes. The instance of Smss.exe in session 0 starts an instance of Csrss.exe (the “client-server runtime” Windows subsystem) in session 0 and Wininit.exe. Wininit.exe starts Services.exe (the Service Control Manager process) and Lsass.exe (the Local Security Authority subsystem). In session 1, Smss.exe starts a new instance of Csrss.exe and Winlogon.exe. Winlogon starts LogonUI.exe to prompt the interactive user for credentials, and then it starts Userinit.exe (which starts Explorer) after the user has authenticated. Both LogonUI and Userinit typically exit before the shell initializes and the user can start Procexp. Most services are descendants of Services.exe; Services.exe does not host any services itself.
To view the complete startup process tree for yourself, refer to the “Boot logging” section in Chapter 5, “Process Monitor.”
User Processes
There are some typical patterns you might wonder about in the Procexp display. For example, you might see “own processes” that are children of service processes rather than descendants of Explorer. The most common examples are out-of-process DCOM components. An application invokes a component that COM determines needs to be hosted in a separate process. Even though the new process might run as the interactive user, the new process is launched by the process hosting the DcomLaunch service rather than directly by the client process. Similarly, on Windows Vista and Windows 7, the Desktop Window Manager (Dwm.exe) is launched as the desktop user by the Desktop Window Manager Session Manager service (UxSms). On Windows 8 and newer, Dwm.exe runs as a system-managed Window Manager account and is started by Winlogon.exe.
Another frequent pattern is the use of job objects. Some DCOM components, particularly Windows Management Instrumentation (WMI) hosting processes, run with restrictions on the amount of memory they can allocate, the number of child processes they can start (if any), or the maximum amount of CPU time they can charge. Anything launched through the Secondary Logon service (for example, with RunAs) is added to a job so that the process and any children it launches can be tracked as a unit and terminated if they’re still running when the user logs off. Finally, the Program Compatibility Assistant (PCA) tracks legacy applications on some versions of Windows so that it can offer a compatibility fix to the user if the PCA detects a potential compatibility problem for which it might have a solution after the last process in the job has exited. Jobs are not highlighted by default; see the “Colored rows and heatmap columns” section earlier in this chapter for more information.
Virtualization-based security in Windows 10 and Windows Server 2016 enables features such as Credential Guard and Device Guard, and it creates user-mode processes that are outside of the direct control of Windows. Procexp can display the existence of the Secure System and LsaIso.exe4 processes, but little else about them.
4 That’s an upper-case “i” and not a lower-case “L” – it’s short for “LSA Isolated.” It’s not “LS Also.”
Process actions
Forcibly terminating a process does not give the process an opportunity to shut down cleanly and can cause data loss or system instability. In addition, Procexp does not provide extra warnings if you try to terminate a system-critical process such as Csrss.exe. Terminating a system-critical process results in an immediate Windows blue screen crash.
Suspend can be useful when dealing with “buddy system” malware, in which two or more processes watch for each other’s termination, with the nonterminated one restarting its buddy if it dies. To defeat such malware, suspend the processes first and then terminate them. See Chapter 20, “Malware,” for additional information and for several real-world troubleshooting cases that succeeded with this technique.