Christophe Nasarre here. I’m the Technical Reviewer of the upcoming sixth edition of Windows Internals, by Mark Russinovich, David Solomon, and Alex Ionescu, which is being released in two parts, the first part this month!
My introduction to this series of posts, in which I choose excerpts from the book to share with you, and my first excerpt (from Chapter 1, “Concepts and Tools”) are here.
Today I’d like to share an excerpt from Chapter 2, “System Architecture.”
In Chapter 2, you get a view of the architecture of Windows. The System processes are examined with their relationships (which is starting which, for example), and the surface of the Idle process is scratched. (I’ll get back to this particular process later.) You are also presented with a way to figure out which system thread is related to which device driver.
Here’s the excerpt; enjoy.
The following system processes appear on every Windows system. (Two of these—Idle and System— are not full processes because they are not running a user-mode executable.)
To understand the relationship of these processes, it is helpful to view the process “tree”—that is, the parent/child relationship between processes. Seeing which process created each process helps to understand where each process comes from. Figure 2-5 is a screen snapshot of the process tree viewed after taking a Process Monitor boot trace. Using Process Monitor allows you to see processes that have since exited (indicated by the muted icon).
The next sections explain the key system processes shown in Figure 2-5. Although these sections brieﬂy indicate the order of process startup, Chapter 13 in Part 2 contains a detailed description of the steps involved in booting and starting Windows.
System Idle Process
The ﬁrst process listed in Figure 2-5 is the system idle process. As we’ll explain in Chapter 5, processes are identiﬁed by their image name. However, this process (as well as the process named System) isn’t running a real user-mode image (in that there is no “System Idle Process.exe” in the \Windows directory). In addition, the name shown for this process differs from utility to utility (because of implementation details). Table 2-6 lists several of the names given to the Idle process (process ID 0). The Idle process is explained in detail in Chapter 5.
Now let’s look at system threads and the purpose of each of the system processes that are running real images.
System Process and System Threads
The System process (process ID 4) is the home for a special kind of thread that runs only in kernel mode: a kernel-mode system thread. System threads have all the attributes and contexts of regular user-mode threads (such as a hardware context, priority, and so on) but are different in that they run only in kernel-mode executing code loaded in system space, whether that is in Ntoskrnl.exe or in any other loaded device driver. In addition, system threads don’t have a user process address space and hence must allocate any dynamic storage from operating system memory heaps, such as a paged or nonpaged pool.
System threads are created by the PsCreateSystemThread function (documented in the WDK), which can be called only from kernel mode. Windows, as well as various device drivers, create system threads during system initialization to perform operations that require thread context, such as issuing and waiting for I/Os or other objects or polling a device. For example, the memory manager uses system threads to implement such functions as writing dirty pages to the page ﬁle or mapped files, swapping processes in and out of memory, and so forth. The kernel creates a system thread called the balance set manager that wakes up once per second to possibly initiate various scheduling and memory management related events. The cache manager also uses system threads to implement both read-ahead and write-behind I/Os. The file server device driver (Srv2.sys) uses system threads to respond to network I/O requests for ﬁle data on disk partitions shared to the network. Even the ﬂoppy driver has a system thread to poll the floppy device. (Polling is more efﬁcient in this case because an interrupt-driven ﬂoppy driver consumes a large amount of system resources.) Fur- ther information on speciﬁc system threads is included in the chapters in which the component is described.
By default, system threads are owned by the System process, but a device driver can create a system thread in any process. For example, the Windows subsystem device driver (Win32k.sys) creates a system thread inside the Canonical Display Driver (Cdd.dll) part of the Windows subsystem process (Csrss.exe) so that it can easily access data in the user-mode address space of that process.
When you’re troubleshooting or going through a system analysis, it’s useful to be able to map the execution of individual system threads back to the driver or even to the subroutine that contains the code. For example, on a heavily loaded file server, the System process will likely be consuming con- siderable CPU time. But the knowledge that when the System process is running that “some system thread” is running isn’t enough to determine which device driver or operating system component is running.
So if threads in the System process are running, ﬁrst determine which ones are running (for example, with the Performance Monitor tool). Once you ﬁnd the thread (or threads) that is running, look up in which driver the system thread began execution (which at least tells you which driver likely created the thread) or examine the call stack (or at least the current address) of the thread in question, which would indicate where the thread is currently executing.
Both of these techniques are illustrated in the following experiment.
EXPERIMENT: Mapping a System Thread to a Device Driver
In this experiment, we’ll see how to map CPU activity in the System process to the responsible system thread (and the driver it falls in) generating the activity. This is important because when the System process is running, you must go to the thread granularity to really understand what’s going on. For this experiment, we will generate system thread activity by generating file server activity on your machine. (The file server driver, Srv2.sys, creates system threads to handle inbound requests for ﬁle I/O. See Chapter 7 for more information on this component.)
1. Open a command prompt.
2. Do a directory listing of your entire C drive using a network path to access your C drive. For example, if your computer name is COMPUTER1, type dir \\computer1\c$ /s (The /s switch lists all subdirectories.)
3. Run Process Explorer, and double-click on the System process.
4. Click on the Threads tab.
5. Sort by the CSwitch Delta (context switch delta) column. You should see one or more threads in Srv2.sys running, such as the following:
If you see a system thread running and you are not sure what the driver is, click the Module button, which will bring up the ﬁle properties. Clicking the Module button while highlighting the thread in the Srv2.sys previously shown results in the following display.