New book: Windows Internals, Sixth Edition, Part 1

We’re happy to announce that Windows Internals, Part 1, 6th Edition (ISBN 9780735648739; 752 pages) is available for purchase! Long considered a classic among Windows enthusiasts, this book was written by some of the most esteemed experts in the internals field today, Mark Russinovich, David Solomon, and Alex Ionescu. This latest edition covers the kernel changes made in Windows 7 and Windows Server 2008 R2 and contains a myriad of hands-on experiments that have been updated to reflect the evolution of the tools.

Order your own copy of this book here, here, or here.

For information on why this edition was split across two books, please read this previous post, which also includes the book’s Table of Contents.

In today’s post, please enjoy this excerpt from Chapter 5, “Processes, Threads, and Jobs.”

Chapter 5
Processes, Threads, and Jobs

In this chapter, we’ll explain the data structures and algorithms that deal with processes, threads, and jobs in the Microsoft Windows operating system. The first section focuses on the internal structures that make up a process. The second section outlines the steps involved in creating a process (and its initial thread). The internals of threads and thread scheduling are then described. The chapter concludes with a description of jobs.

Because processes and threads touch so many components in Windows, a number of terms and data structures (such as working sets, objects and handles, system memory heaps, and so on) are referred to in this chapter but are explained in detail elsewhere in the book. To fully understand this chapter, you need to be familiar with the terms and concepts explained in Chapter 1, “Concepts and Tools,” and Chapter 2, “System Architecture,” such as the difference between a process and a thread, the Windows virtual address space layout, and the difference between user mode and kernel mode.

Process Internals

This section describes the key Windows process data structures maintained by various parts of the system and describes different ways and tools to examine this data.

Data Structures

Each Windows process is represented by an executive process (EPROCESS) structure. Besides containing many attributes relating to a process, an EPROCESS contains and points to a number of other related data structures. For example, each process has one or more threads, each represented by an executive thread (ETHREAD) structure. (Thread data structures are explained in the section “Thread Internals” later in this chapter.)

The EPROCESS and most of its related data structures exist in system address space. One exception is the process environment block (PEB), which exists in the process address space (because it contains information accessed by user-mode code). Additionally, some of the process data structures used in memory management, such as the working set list, are valid only within the context of the current process, because they are stored in process-specific system space. (See Chapter 10, “Memory Management,” in Part 2 for more information on process address space.)

For each process that is executing a Win32 program, the Win32 subsystem process (Csrss) maintains a parallel structure called the CSR_PROCESS. Finally, the kernel-mode part of the Win32 subsystem (Win32k.sys) maintains a per-process data structure, W32PROCESS. The W32PROCESS structure is created the first time a thread calls a Windows USER or GDI function that is implemented in kernel mode.

With the exception of the idle process, every EPROCESS structure is encapsulated as a process object by the executive object manager (described in Chapter 3, “System Mechanisms”). Because processes are not named objects, they are not visible in the WinObj tool. You can, however, see the Type object called “Process” in the \ObjectTypes directory. A handle to a process provides, through use of the process-related APIs, access to some of the data in the EPROCESS structure and also in some of its associated structures.

Figure 5-1 is a simplified diagram of the process and thread data structures. Each data structure shown in the figure is described in detail in this chapter.


Many other drivers and system components, by registering process creation notifications, can choose to create their own data structures to track information they store on a per-process basis. When one discusses the overhead of a process, the size of such data structures must often be taken into consideration, although it is nearly impossible to obtain an accurate number.

First let’s focus on the process object. (The thread object is covered in the section “Thread Internals” later in the chapter.) Figure 5-2 shows the key fields in an EPROCESS structure.


Similar to the way that the kernel’s APIs and components are divided into isolated and layered modules with their own naming conventions, the data structures for a process follow a similar design. As shown in Figure 5-2, the first member of the executive process structure is called Pcb, for process control block. It is a structure of type KPROCESS, for kernel process. Although routines in the executive store information in the EPROCESS, the dispatcher, scheduler, and interrupt/time accounting code—being part of the operating system kernel—use the KPROCESS instead. This allows a layer of abstraction to exist between the executive’s high-level functionality and its underlying low-level implementation of certain functions, and it helps prevent unwanted dependencies between the layers.


EXPERIMENT: Displaying the Format of an EPROCESS Structure and Its Fields

For a list of the fields that make up an EPROCESS structure and their offsets in hexadecimal, type dt nt!_eprocess in the kernel debugger. (See Chapter 1 for more information on the kernel debugger and how to perform kernel debugging on the local system.) The output (truncated for the sake of space) on a 32-bit system looks like this:

lkd> dt nt!_eprocess
    +0x000 Pcb                : _KPROCESS
    +0x080 ProcessLock        : _EX_PUSH_LOCK
    +0x088 CreateTime         : _LARGE_INTEGER
    +0x090 ExitTime           : _LARGE_INTEGER
    +0x098 RundownProtect     : _EX_RUNDOWN_REF
    +0x09c UniqueProcessId    : Ptr32 Void
    +0x0dc ObjectTable        : Ptr32 _HANDLE_TABLE
    +0x0e0 Token              : _EX_FAST_REF
    +0x108 Win32Process       : Ptr32 Void
    +0x10c Job                : Ptr32 _EJOB
    +0x2a8 TimerResolutionLink : _LIST_ENTRY
    +0x2b0 RequestedTimerResolution : Uint4B
    +0x2b4 ActiveThreadsHighWatermark : Uint4B
    +0x2b8 SmallestTimerResolution : Uint4B
    +0x2bc TimerResolutionStackRecord : Ptr32 _PO_DIAG_STACK_RECORD

The first member of this structure (Pcb) is an imbedded structure of type KPROCESS. This is where scheduling and time-accounting data is stored. You can display the format of the kernel process structure in the same way as the EPROCESS:

lkd> dt _kprocess
    +0x000 Header             : _DISPATCHER_HEADER
    +0x010 ProfileListHead    : _LIST_ENTRY
    +0x018 DirectoryTableBase : Uint4B
    +0x074 StackCount         : _KSTACK_COUNT
    +0x078 ProcessListEntry   : _LIST_ENTRY
    +0x080 CycleTime          : Uint8B
    +0x088 KernelTime         : Uint4B
    +0x08c UserTime           : Uint4B
    +0x090 VdmTrapcHandler    : Ptr32 Void

The dt command also enables you to view the specific contents of one field or multiple fields by typing their names following the structure name—such as dt nt!_eprocess UniqueProcessId, which displays the process ID field. In the case of a field that represents a structure—such as the Pcb field of EPROCESS, which contains the KPROCESS substructure—adding a period after the field name will cause the debugger to display the substructure.

For example, an alternative way to see the KPROCESS is to type dt nt!_eprocess Pcb. You can continue to recurse this way by adding more field names (within KPROCESS) and so on. Finally, to recurse through all the substructures, the –r switch of the dt command allows you to do just that. Adding a number after the switch controls the depth of recursion the command will follow.

The dt command used as shown earlier shows the format of the selected structure, not the contents of any particular instance of that structure type. To show an instance of an actual process, you can specify the address of an EPROCESS structure as an argument to the dt command. You can get the addresses of almost all of the EPROCESS structures in the system by using the !process 0 0 command (the exception being the system idle process). Because the KPROCESS is the first thing in the EPROCESS, the address of an EPROCESS will also work as the address of a KPROCESS with dt _kprocess.

Processes and threads are such integral parts of Windows that it’s impossible to talk about them without referring to many other parts of the system. To keep the length of this chapter manageable, however, those related subjects (such as memory management, security, objects, and handles) are covered elsewhere.


EXPERIMENT: Using the Kernel Debugger !process Command

The kernel debugger !process command displays a subset of the information in a process object and its associated structures. This output is arranged in two parts for each process. First you see the information about the process, as shown here. (When you don’t specify a process address or ID, !process lists information for the process owning the thread currently running on CPU 0, which will be WinDbg itself on a single-processor system.)

lkd> !process
PROCESS 85857160 SessionId: 1 Cid: 0bcc Peb: 7ffd9000 ParentCid: 090c
DirBase: b45b0820 ObjectTable: b94ffda0 HandleCount: 99.
Image: windbg.exe
VadRoot 85a1c8e8 Vads 97 Clone 0 Private 5919. Modified 153. Locked 1.
DeviceMap 9d32ee50
Token ebaa1938
' PageFaultCount 37066
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 6242

After the basic process output comes a list of the threads in the process. That output is explained in the “Experiment: Using the Kernel Debugger !thread Command” section later in the chapter.

Other commands that display process information include !handle, which dumps the process handle table (which is described in more detail in the section “Object Handles and the Process Handle Table” in Chapter 3). Process and thread security structures are described in Chapter 6, “Security.”

Note that the output gives you the address of the PEB, which you can use with the !peb command shown in the next experiment to see the PEB of an arbitrary process. However, because the PEB is in the user-mode address space, it is valid only within the context of its own process. To look at the PEB of another process, you must first switch WinDbg to that process. You can do this with the .process command, followed by the EPROCESS pointer.

The PEB lives in the user-mode address space of the process it describes. It contains information needed by the image loader, the heap manager, and other Windows components that need to access it from user mode. The EPROCESS and KPROCESS structures are accessible only from kernel mode. The important fields of the PEB are illustrated in Figure 5-3 and are explained in more detail later in this chapter.



EXPERIMENT: Examining the PEB

You can dump the PEB structure with the !peb command in the kernel debugger, which displays the PEB of the process that owns the currently running thread on CPU 0. By using the information in the previous experiment, you can also use the PEB pointer as an argument to the command.

lkd> !peb 7ffd9000
PEB at 7ffd9000
InheritedAddressSpace: No
ReadImageFileExecOptions: No
BeingDebugged: No
ImageBaseAddress: 002a0000
Ldr 77895d00
WindowTitle: 'C:\Users\Alex Ionescu\Desktop\WinDbg.lnk'
ImageFile: 'C:\Program Files\Debugging Tools for Windows\windbg.exe'
CommandLine: '"C:\Program Files\Debugging Tools for Windows\windbg.exe" '
DllPath: 'C:\Program Files\Debugging Tools for Windows;C:\Windows\
Environment: 001850a8
APPDATA=C:\Users\Alex Ionescu\AppData\Roaming

The CSR_PROCESS structure contains information about processes that is specific to the Windows subsystem (Csrss). As such, only Windows applications have a CSR_PROCESS structure associated with them (for example, Smss does not). Additionally, because each session has its own instance of the Windows subsystem, the CSR_PROCESS structures are maintained by the Csrss process within each individual session. The basic structure of the CSR_PROCESS is illustrated in Figure 5-4 and is explained in more detail later in this chapter.




You can dump the CSR_PROCESS structure with the !dp command in the user-mode debugger while attached to the Csrss process of the session you want to inspect. Use the File, Attach To A Process option to get a list of processes, and select the Csrss process for the correct session. (You can see the session of the process by expanding the tree item for it.) Make sure to select the Noninvasive check box to avoid freezing your system.

The !dp command takes as input the PID of the process whose CSR_PROCESS structure should be dumped. Alternatively, the structure pointer can be given directly as an argument. Because !dp already performs a dt command internally, there is no need to use dt on your own.

0:000> !dp v 0x1c0aa8-8
PCSR_PROCESS @ 001c0aa0:
+0x000 ClientId : _CLIENT_ID
+0x008 ListLink : _LIST_ENTRY [ 0x1d8618 - 0x1b1b10 ]
+0x010 ThreadList : _LIST_ENTRY [ 0x1c0b80 - 0x1c7638 ]
+0x018 NtSession : 0x001c0bb8 _CSR_NT_SESSION
+0x054 Luid : _LUID
+0x05c ServerDllPerProcessData : [1] (null)
Thread 001c0b78, Process 001c0aa0, ClientId 198.19c, Flags 0, Ref Count 1
Thread 001c0e78, Process 001c0aa0, ClientId 198.1cc, Flags 0, Ref Count 1

The W32PROCESS structure is the final system data structure associated with processes that we’ll look at. It contains all the information that the Windows graphics and window management code in the kernel (Win32k) needs to maintain state information about GUI processes (which were defined earlier as processes that have done at least one USER/GDI system call). The basic structure of the W32PROCESS is illustrated in Figure 5-5 and is explained in more detail later in this chapter.




There is no command provided by the debugger extensions to dump the W32PROCESS structure, but it is present in the symbols of the Win32k driver. As such, by using the dt command with the appropriate symbol name win32k!_W32PROCESS, it is possible to dump the fields as long as the pointer is known. Because the !process command does not actually output this pointer (even though it is stored in the EPROCESS object), the field must be inspected manually with dt nt!_EPROCESS Win32Process followed by an EPROCESS pointer.

In the following example, the W32PROCESS structure for the shell, Explorer.exe, is shown:

lkd> dt win32k!_W32PROCESS 0xff991490
   +0x000 Process           : 0x84a2b030 _EPROCESS
   +0x004 RefCount          : 1
   +0x020 W32Pid            : 0x590
   +0x024 GDIHandleCount    : 383
   +0x028 GDIHandleCountPeak  : 0x239
   +0x02c UserHandleCount   : 228
   +0x030 UserHandleCountPeak : 0x16c
   +0x088 hSecureGdiSharedHandleTable : 0x84a24159
   +0x08c DxProcess         : 0xa2c93980

The DxProcess field is a pointer to yet another per-process data structure—in this case, maintained by the DirectX Video Card Port Driver—but its description is beyond the scope of this book.

Comments (1)
  1. Luigi Bruno says:

    The first edition of Windows Internals I've read was the third one, talking about Windows 2000.

    This is always one of my favourite books.

Comments are closed.

Skip to main content