Christophe Nasarre: Excerpt #2 from Windows Internals 6E

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.

System Processes

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.)

• Idle process (contains one thread per CPU to account for idle CPU time)  
• System process (contains the majority of the kernel-mode system threads)  
• Session manager (Smss.exe) 
• Local session manager (Lsm.exe) 
• Windows subsystem (Csrss.exe) 
• Session 0 initialization (Wininit.exe) 
• Logon process (Winlogon.exe) 
• Service control manager (Services.exe) and the child service processes it creates (such as the
  system-supplied generic service-host process, Svchost.exe) 
• Local security authentication server (Lsass.exe)

   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
briefly 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 first process listed in Figure 2-5 is the system idle process. As we’ll explain in Chapter 5, processes
are identified 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 file 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 file data on disk partitions shared to the network. Even the
floppy driver has a system thread to poll the floppy device. (Polling is more efficient in this case
because an interrupt-driven floppy driver consumes a large amount of system resources.) Fur-
ther information on specific 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, first determine which ones are running (for
example, with the Performance Monitor tool). Once you find 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 file 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 file properties. Clicking the Module
button while highlighting the thread in the Srv2.sys previously shown results in the
following display.