System Architecture

Chapter 2

Operating System Model

• The OS kernel code runs in a privileged processor mode (kernel mode), with access to system data and to the hardware. Application code runs in a non-privileged processor mode (user mode), with a limited set of interfaces available, limited access to system data, and no direct access to hardware.

• When a user-mode program calls a system service, the processor executes a special instruction that switches the calling thread to kernel mode. When the system service completes, the OS switches the thread context back to user mode and allows the caller to continue.

• The kernel-mode components of Windows also embody basic object-oriented design principles. For example, in general they don’t reach into one another’s data structures to access information maintained by individual components. Instead, they use formal interfaces to pass parameters and access and/or modify data structures.

• Despite its pervasive use of objects to represent shared system resources, Windows is not an object oriented system in the strict sense. Most of the kernel-mode OS code is written in C for portability. The C programming language doesn’t directly support object-oriented constructs such as polymorphic functions or class inheritance. Therefore, the C-based implementation of objects in Windows borrows from, but doesn’t depend on, features of particular object-oriented languages.

---

Architecture Overview

Windows Architecture Overview

• User-mode threads execute in a private process address space (although while they are executing in kernel mode, they have access to system space). Thus, system processes, service processes, user processes, and environment subsystems each have their own private process address space.

• A second dividing line between kernel-mode parts of Windows and the hypervisor is also visible. Strictly speaking, the hypervisor still runs with the same CPU privilege level (0) as the kernel, but because it uses specialized CPU instructions (VT-x on Intel, SVM on AMD), it can both isolate itself from the kernel while also monitoring it (and applications).

• The four basic types of user-mode processes:

  • User processes: These processes can be one of the following types: Windows 32-bit or 64-bit (Windows Apps running on top of the Windows Runtime in Windows 8 and later are included in this category), Windows 3.1 16-bit, MS-DOS 16-bit, or POSIX 32-bit or 64-bit. Note that 16-bit applications can be run only on 32-bit Windows, and that POSIX apps are no longer supported as of Windows 8.

  • Service processes: These are processes that host Windows services, such as the Task Scheduler and Print Spooler services. Services generally have the requirement that they run independently of user logons. Many Windows server applications, such as Microsoft SQL Server and Microsoft Exchange Server, also include components that run as services.

  • System processes: These are fixed, or hardwired, processes, such as the logon process and the Session Manager, that are not Windows services. That is, they are not started by the Service Control Manager.

  • Environment subsystem server processes: These implement part of the support for the OS environment, or personality, presented to the user and programmer.

• Under Windows, user applications don’t call the native Windows OS services directly. Rather, they go through one or more subsystem dynamic-link libraries (DLLs). The role of subsystem DLLs is to translate a documented function into the appropriate internal (and generally undocumented) native system service calls implemented mostly in Ntdll.dll. This translation might or might not involve sending a message to the environment subsystem process that is serving the user process.

• The kernel-mode components of Windows include the following:

  • Executive: The Windows executive contains the base OS services, such as memory management, process and thread management, security, I/O, networking, and inter-process communication.

  • The Windows kernel: This consists of low-level OS functions, such as thread scheduling, interrupt and exception dispatching, and multiprocessor synchronization. It also provides a set of routines and basic objects that the rest of the executive uses to implement higher-level constructs.

  • Device drivers: This includes both hardware device drivers, which translate user I/O function calls into specific hardware device I/O requests, and non-hardware device drivers, such as file system and network drivers.

  • The Hardware Abstraction Layer (HAL): This is a layer of code that isolates the kernel, the device drivers, and the rest of the Windows executive from platform-specific hardware differences (such as differences between motherboards).

  • The windowing and graphics system: This implements the graphical user interface (GUI) functions (better known as the Windows USER and GDI functions), such as dealing with windows, user interface controls, and drawing.

  • The hypervisor layer: This is composed of a single component: the hypervisor itself. There are no drivers or other modules in this environment. That being said, the hypervisor is itself composed of multiple internal layers and services, such as its own memory manager, virtual processor scheduler, interrupt and timer management, synchronization routines, partitions (virtual machine instances) management and inter-partition communication (IPC), and more.

Core Windows System Files

Portability

• Windows achieves portability across hardware architectures and platforms in two primary ways:

  • By using a layered design Windows has a layered design, with low-level portions of the system that are processor-architecture–specific or platform-specific isolated into separate modules so that upper layers of the system can be shielded from the differences between architectures and among hardware platforms. The two key components that provide OS portability are the kernel (contained in Ntoskrnl.exe) and the HAL (contained in Hal.dll). Both these components are described in more detail later in this chapter. Functions that are architecture- specific, such as thread context switching and trap dispatching, are implemented in the kernel. Functions that can differ among systems within the same architecture (for example, different motherboards) are implemented in the HAL. The only other component with a significant amount of architecture-specific code is the memory manager, but even that is a small amount compared to the system as a whole. The hypervisor follows a similar design, with most parts shared between the AMD (SVM) and Intel (VT-x) implementation.

  • By using C The vast majority of Windows is written in C, with some portions in C++. Assembly language is used only for those parts of the OS that need to communicate directly with system hardware (such as the interrupt trap handler) or that are extremely performance-sensitive (such as context switching). Assembly language code exists not only in the kernel and the HAL but also in a few other places within the core OS (such as the routines that implement interlocked instructions as well as one module in the local procedure call facility), in the kernel-mode part of the Windows subsystem, and even in some user-mode libraries, such as the process startup code in Ntdll.dll.

Symmetric Multiprocessing

• Windows is a symmetric multiprocessing (SMP) OS. There is no master processor—the OS as well as user threads can be scheduled to run on any processor.

• Also, all the processors share just one memory space. This model contrasts with asymmetric multiprocessing (ASMP), in which the OS typically selects one processor to execute OS kernel code while other processors run only user code.

Symmetric vs. asymmetric multiprocessing

• Windows also supports four modern types of multiprocessor systems: multicore, simultaneous multi-threaded (SMT), heterogeneous, and non-uniform memory access (NUMA).

  1. SMT was first introduced to Windows systems by adding support for Intel’s Hyper-Threading Technology, which provides two logical processors for each physical core. Newer AMD processors under the Zen micro-architecture implement a similar SMT technology, also doubling the logical processor count. Each logical processor (or a so-called "thread") has its own CPU state, but the execution engine and onboard cache are shared. This permits one logical CPU to make progress while the other logical CPU is stalled (such as after a cache miss or branch misprediction). The scheduling algorithms are enhanced to make optimal use of SMT-enabled machines, such as by scheduling threads on an idle physical processor versus choosing an idle logical processor on a physical processor whose other logical processors are busy.

  2. In NUMA systems, processors are grouped in smaller units called nodes. Each node has its own processors and memory and is connected to the larger system through a cache-coherent interconnect bus. Windows on a NUMA system still runs as an SMP system, in that all processors have access to all memory. It’s just that node-local memory is faster to reference than memory attached to other nodes. The system attempts to improve performance by scheduling threads on processors that are in the same node as the memory being used. It attempts to satisfy memory-allocation requests from within the node, but it will allocate memory from other nodes if necessary.

  3. Windows also natively supports multicore systems. Because these systems have real physical cores (simply on the same package), the original SMP code in Windows treats them as discrete processors, except for certain accounting and identification tasks that distinguish between cores on the same processor and cores on different sockets. This is especially important when dealing with cache topologies to optimize data-sharing.

  4. ARM versions of Windows also support a technology known as heterogeneous multi-processing, whose implementation on such processors is called big.LITTLE. This type of SMP-based design differs from traditional ones in that not all processor cores are identical in their capabilities, yet unlike pure heterogeneous multi-processing, they are still able to execute the same instructions. The difference, then, comes from the clock speed and respective full load/idle power draws, allowing for a col- lection of slower cores to be paired with faster ones.

• Windows does keep track of processors (total number, idle, busy, and other such details) in a bitmask (sometimes called an affinity mask) that is the same number of bits as the native data type of the machine (32-bit or 64-bit). This allows the processor to manipulate bits directly within a register.

• To maintain compatibility, as well as support larger processor systems, Windows implements a higher-order construct called a processor group. The processor group is a set of processors that can all be defined by a single affinity bitmask, and the kernel as well as the applications can choose which group they refer to during affinity updates.

• Compatible applications can query the number of supported groups and then enumerate the bitmask for each group. Meanwhile, legacy applications continue to function by seeing only their current group.

• As mentioned, the actual number of supported licensed processors depends on the edition of Windows being used. This number is stored in the system license policy file %SystemRoot%\ServiceProfiles\LocalService\AppData\Local\Microsoft\WSLicense\tokens.dat in the variable kernel-RegisteredProcessors.

Scalability

• Windows incorporates several features that are crucial to its success as a multiprocessor OS:

  • The ability to run OS code on any available processor and on multiple processors parallelly

  • Multiple threads of execution within a single process, each of which can execute simultaneously on different processors

  • Fine-grained synchronization within the kernel (such as spinlocks, queued spinlocks, and pushlocks) as well as within device drivers and server processes, which allows more components to run concurrently on multiple processors

  • Programming mechanisms such as I/O completion ports that facilitate the efficient implementation of multithreaded server processes that can scale well

Virtualization-based Security Architecture Overview

VBS Architecture Diagram

• With VBS enabled, a VTL of 1 is now present, which contains its own secure kernel running in the privileged processor mode (that is, ring 0 on x86/x64). Similarly, a run-time user environment mode, called the Isolated User Mode (IUM), now exists, which runs in unprivileged mode (that is, ring 3).

• In this architecture, the secure kernel is its own separate binary, which is found under the name securekernel.exe on disk. As for IUM, it’s both an environment that restricts the allowed system calls that regular user-mode DLLs can make (thus limiting which of these DLLs can be loaded) and a framework that adds special secure system calls that can execute only under VTL 1.

• These additional system calls are exposed in a similar way as regular system calls: through an internal system library named Iumdll.dll (the VTL 1 version of Ntdll.dll) and a Windows subsystem–facing library named Iumbase.dll (the VTL 1 version of Kernelbase.dll).

• Kernel-mode code running at VTL 0 cannot touch user mode running at VTL 1 because VTL 1 is more privileged. Yet, user-mode code running at VTL 1 cannot touch kernel mode running at VTL 0 either because user (ring 3) cannot touch kernel (ring 0). Similarly, VTL 1 user-mode applications must still go through regular Windows system calls and their respective access checks if they wish to access resources.

• VTL 1 applications aren’t just not more powerful; in many cases, they’re much less so. Because the secure kernel does not implement a full range of system capabilities, it hand-picks which system calls it will forward to the VTL 0 kernel.

• The secure kernel however, by both running at VTL 1 and being in kernel mode, does have complete access to VTL 0 memory and resources. It can use the hypervisor to limit the VTL 0 OS access to certain memory locations by leveraging CPU hardware support known as Second Level Address Translation (SLAT).

• SLAT is the basis of Credential Guard technology, which can store secrets in such locations. Similarly, the secure kernel can use SLAT technology to interdict and control execution of memory locations, a key covenant of Device Guard.

• To prevent normal device drivers from leveraging hardware devices to directly access memory, the system uses another piece of hardware known as the I/O memory management unit (I/O MMU), which effectively virtualizes memory access for devices. This can be used to prevent device drivers from using direct memory access (DMA) to directly access the hypervisor or secure kernel’s physical regions of memory.

• Because the hypervisor is the first system component to be launched by the boot loader, it can program the SLAT and I/O MMU as it sees fit, defining the VTL 0 and 1 execution environments. Then, while in VTL 1, the boot loader runs again, loading the secure kernel, which can configure the system further to its needs. Only then is the VTL dropped, which will see the execution of the normal kernel, now living in its VTL 0 jail, unable to escape.

• Only a special class of specially signed binaries, called Trustlets, are allowed to execute in VTL 1. Each Trustlet has a unique identifier and signature, and the secure kernel has hard-coded knowledge of which Trustlets have been created so far.

Environment subsystems and subsystem DLLs

• The subsystem startup information is stored under the registry key HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems.

• Windows designers decided to locate all basic functions in the Windows subsystem and have the other subsystems call on the Windows subsystem to perform display I/O. As a result of this design decision, the Windows subsystem is a required component for any Windows system, even on server systems with no interactive users logged in. Because of this, the process is marked as a critical process (which means if it exits for any reason, the system crashes).

• The Windows subsystem consists of the following major components

  • Each session (Csrss.exe) loads four DLLs (Basesrv.dll, Winsrv.dll, Sxssrv.dll, and Csrsrv.dll) that contain support for the following:

    • Various housekeeping tasks related to creating and deleting processes and threads

    • Shutting down Windows applications (through the ExitWindowsEx API)

    • Containing .ini file to registry location mappings for backward compatibility

    • Sending certain kernel notification messages (such as those from the Plug-and-Play manager) to Windows applications as Window messages (WM_DEVICECHANGE)

    • Side-by-Side (SxS)/Fusion and manifest cache support

    • Several natural language support functions, to provide caching

  • Additionally, the Csrss.exe instances associated with interactive user sessions contain a fifth DLL called the Canonical Display Driver (Cdd.dll). CDD is responsible for communicating with the DirectX support in the kernel.

  • A kernel-mode device driver (Win32k.sys) that contains the following:

    • The window manager

    • The Graphics Device Interface (GDI)

    • Wrappers for DirectX support that is implemented in another kernel driver (Dxgkrnl.sys)

  • The console host process (Conhost.exe), which provides support for console (character cell) applications.

  • The Desktop Window Manager (Dwm.exe), which allows for compositing visible window rendering into a single surface through the CDD and DirectX

  • Subsystem DLLs (such as Kernel32.dll, Advapi32.dll, User32.dll, and Gdi32.dll) that translate documented Windows API functions into the appropriate and undocumented (for user-mode) kernel-mode system service calls in Ntoskrnl.exe and Win32k.sys

  • Graphics device drivers for hardware-dependent graphics display drivers, printer drivers, and video miniport drivers

Executive

• The Windows executive is the upper layer of Ntoskrnl.exe. (The kernel is the lower layer) The executive includes the following types of functions:

  1. Functions that are exported and callable from user mode (exported from NTDLL.DLL)

  2. Device driver functions that are called through the DeviceIoControl function

  3. Functions that can be called only from kernel mode that are exported and documented in the WDK

  4. Functions that are exported and can be called from kernel mode but are not documented in the WDK

  5. Functions that are defined as global symbols but are not exported

  6. Functions that are internal to a module that are not defined as global symbols

• The executive is composed of these following components:

  1. Configuration Manager

  2. Process Manager

  3. Security Reference Monitor (SRM)

  4. I/O Manager

  5. Plug and Play (PnP) manager

  6. Power Manager

  7. Windows Driver Model (WDM) Windows Management Instrumentation (WMI) routines

  8. Memory Manager

  9. Cache Manager

  10. Object manager

  11. Asynchronous LPC (ALPC) facility

  12. Run-time library functions

  13. Executive support routines

  14. Kernel debugger library

  15. User-Mode Debugging Framework

  16. Hypervisor library and VBS library

  17. Errata manager

  18. Driver Verifier

  19. Event Tracing for Windows (ETW)

  20. Windows Diagnostic Infrastructure (WDI)

  21. Windows Hardware Error Architecture (WHEA) support routines

  22. File-System Runtime Library (FSRTL)

  23. Kernel Shim Engine (KSE)

Kernel

• The kernel consists of a set of functions in Ntoskrnl.exe that provides fundamental mechanisms. These include thread-scheduling and synchronization services, used by the executive components, and low-level hardware architecture dependent support.

Kernel Objects

• The kernel separates itself from the rest of the executive by implementing OS mechanisms and avoiding policy making. It leaves nearly all policy decisions to the executive, with the exception of thread scheduling and dispatching, which the kernel implements.

• Simpler objects, called kernel objects, help the kernel control central processing and support the creation of executive objects. Most executive-level objects encapsulate one or more kernel objects, incorporating their kernel-defined attributes.

• One set of kernel objects, called control objects, establishes semantics for controlling various OS functions. This set includes the Asynchronous Procedure Call (APC) object, the Deferred Procedure Call (DPC) object, and several objects the I/O manager uses, such as the interrupt object.

• Another set of kernel objects, known as dispatcher objects, incorporates synchronization capabilities that alter or affect thread scheduling. The dispatcher objects include the kernel thread, mutex, event, kernel event pair, semaphore, timer, and waitable timer. The executive uses kernel functions to create instances of kernel objects, to manipulate them, and to construct the more complex objects it provides to user mode.

Kernel processor control region and control block

• The kernel uses a data structure called the kernel processor control region (KPCR) to store processor-specific data. The KPCR contains basic information such as the processor’s interrupt dispatch table (IDT), task state segment (TSS), and global descriptor table (GDT).

• It also includes the interrupt controller state, which it shares with other modules, such as the ACPI driver and the HAL. To provide easy access to the KPCR, the kernel stores a pointer to it in the fs register on 32-bit Windows and in the gs register on an x64 Windows system.

• The KPCR also contains an embedded data structure called the kernel processor control block (KPRCB). Unlike the KPCR, which is documented for third-party drivers and other internal Windows kernel components, the KPRCB is a private structure used only by the kernel code in Ntoskrnl.exe. It contains the following:

  1. Scheduling information such as the current, next, and idle threads scheduled for execution on the processor

  2. The dispatcher database for the processor, which includes the ready queues for each priority level

  3. The DPC queue

  4. CPU vendor and identifier information, such as the model, stepping, speed, and feature bits

  5. CPU and NUMA topology, such as node information, cores per package, logical processors per core, and so on

  6. Cache sizes

  7. Time accounting information, such as the DPC and interrupt time.

  8. I/O statistics

  9. Cache manager statistics

  10. DPC statistics

  11. Memory manager statistics

• Finally, the KPRCB is sometimes used to store cache-aligned, per-processor structures to optimize memory access, especially on NUMA systems. For example, the non-paged and paged-pool system look-aside lists are stored in the KPRCB.

Hardware Abstraction Layer

• The hardware abstraction layer (HAL) is a key part of making Windows portable. The HAL is a loadable kernel-mode module (Hal.dll) that provides the low-level interface to the hardware platform on which Windows is running.

• It hides hardware-dependent details such as I/O interfaces, interrupt controllers, and multiprocessor communication mechanisms; any functions that are both architecture-specific and machine-dependent. So rather than access hardware directly, Windows internal components and user-written device drivers maintain portability by calling the HAL routines when they need platform-dependent information.

• For x86:

• On x64 and ARM machines, there is only one HAL image, called Hal.dll. This results from all x64 machines having the same motherboard configuration, because the processors require ACPI and APIC support. Therefore, there is no need to support machines without ACPI or with a standard PIC. Similarly, all ARM systems have ACPI and use interrupt controllers, which are similar to a standard APIC.

• For IoT Windows versions, it supports modules known as HAL extensions, which are additional DLLs on disk that the boot loader may load if specific hardware requiring them is needed (usually through ACPI and registry-based configuration).

Device Drivers

• Device drivers are loadable kernel-mode modules (files typically ending with the .sys extension) that interface between the I/O manager and the relevant hardware or software. They run in kernel mode in one of three contexts:

  • In the context of the user thread that initiated an I/O function (such as a read operation)

  • In the context of a kernel-mode system thread (such as a request from the Plug and Play manager)

  • As a result of an interrupt and therefore not in the context of any particular thread but rather of whichever thread was current when the interrupt occurred

• There are several types of device drivers:

  1. Hardware device drivers

  2. File system drivers

  3. File system filter drivers

  4. Network redirectors and servers

  5. Protocol drivers

  6. Kernel streaming filter drivers

  7. Software Drivers

Windows Driver Model

• From the WDM perspective, there are three kinds of drivers:

  1. Bus drivers A bus driver services a bus controller, adapter, bridge, or any device that has child devices. Bus drivers are required drivers, and Microsoft generally provides them. Each type of bus (such as PCI, PCMCIA, and USB) on a system has one bus driver. Third parties can write bus drivers to provide support for new buses, such as VMEbus, Multibus, and Futurebus.

  2. Function drivers A function driver is the main device driver and provides the operational interface for its device. It is a required driver unless the device is used raw, an implementation in which I/O is done by the bus driver and any bus filter drivers, such as SCSI PassThru. A function driver is by definition the driver that knows the most about a particular device, and it is usually the only driver that accesses device-specific registers.

  3. Filter drivers A filter driver is used to add functionality to a device or existing driver, or to modify I/O requests or responses from other drivers. It is often used to fix hardware that pro- vides incorrect information about its hardware resource requirements. Filter drivers are optional and can exist in any number, placed above or below a function driver and above a bus driver. Usually, system original equipment manufacturers (OEMs) or independent hardware vendors (IHVs) supply filter drivers.

• In the WDM driver environment, no single driver controls all aspects of a device. A bus driver is concerned with reporting the devices on its bus to PnP manager, while a function driver manipulates the device.

• Lower-level filter drivers modify the behavior of device hardware. For example, if a device reports to its bus driver that it requires 4 I/O ports when it actually requires 16 I/O ports, a lower- level, device-specific function filter driver could intercept the list of hardware resources reported by the bus driver to the PnP manager and update the count of I/O ports.

• Upper-level filter drivers usually provide added-value features for a device. For example, an upper- level device filter driver for a disk can enforce additional security checks.

Windows Driver Foundation

• The Windows Driver Foundation (WDF) simplifies Windows driver development by providing two frameworks: the Kernel-Mode Driver Framework (KMDF) and the User-Mode Driver Framework (UMDF).

• KMDF provides a simple interface to WDM and hides its complexity from the driver writer without modifying the underlying bus/function/filter model. KMDF drivers respond to events that they can register and call into the KMDF library to perform work that isn’t specific to the hardware they are managing, such as generic power management or synchronization.

• UMDF enables certain classes of drivers - mostly USB-based or other high-latency protocol buses, such as those for video cameras, MP3 players, cell phones, and printers to be implemented as user-mode drivers. UMDF runs each user-mode driver in what is essentially a user-mode service, and it uses ALPC to communicate to a kernel-mode wrapper driver that provides actual access to hardware. If a UMDF driver crashes, the process dies and usually restarts. That way, the system doesn’t become un- stable; the device simply becomes unavailable while the service hosting the driver restarts.

Commonly used driver prefixes

System Processes

System Idle Process

• This contains one thread per CPU to account for idle CPU time.

• There is no image on the disk for this process. So while strictly not being a "Windows defined process", it is named as such due to implementation of the operating system. In addition, because of implementation details, the name shown for this process differs from utility to utility.

• The Idle process accounts for idle time. That’s why the number of “threads” in this “process” is the number of logical processors on the system.

• Below table lists several of the names given to the idle process (PID 0):

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 differ 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 OS memory heaps, such as a paged or non-paged pool.

• System threads are created by the PsCreateSystemThread or IoCreateSystemThread functions, both documented in the WDK. These threads 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.

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

Secure System process

• The Secure System process (variable process ID) is technically the home of the VTL 1 secure kernel address space, handles, and system threads.

• That being said, because scheduling, object management, and memory management are owned by the VTL 0 kernel, no such actual entities will be associated with this process. Its only real use is to provide a visual indicator to users that VBS is currently active.

Memory Compression process

• The Memory Compression process uses its user-mode address space to store the compressed pages of memory that correspond to standby memory that’s been evicted from the working sets of certain processes.

• Unlike the Secure System process, the Memory Compression process does actually host a number of system threads, usually seen as SmKmStoreHelperWorker and SmStReadThread. Both of these belong to the Store Manager that manages memory compression.

• Additionally, unlike the other System processes in this list, this process actually stores its memory in the user-mode address space. This means it is subject to working set trimming and will potentially have large visible memory usage in system-monitoring tools.

Session Manager

• The Session Manager (%SystemRoot%\System32\Smss.exe) is the first user-mode process created in the system. The kernel-mode system thread that performs the final phase of the initialization of the executive and kernel creates this process. It is created as a Protected Process Light (PPL).

• When Smss.exe starts, it checks whether it is the first instance (the master Smss.exe) or an instance of itself that the master Smss.exe launched to create a session. If command-line arguments are present, it is the latter.

• By creating multiple instances of itself during boot-up and Terminal Services session creation, Smss.exe can create multiple sessions at the same time—as many as four concurrent sessions, plus one more for each extra CPU beyond one. This ability enhances logon performance on Terminal Server systems where multiple users connect at the same time.

• Once a session finishes initializing, the copy of Smss.exe terminates. As a result, only the initial Smss.exe process remains active.

• The master Smss.exe performs the following one-time initialization steps:

  1. It marks the process and the initial thread as critical. If a process or thread marked critical exits for any reason, Windows crashes.

  2. It causes the process to treat certain errors as critical, such as invalid handle usage and heap corruption, and enables the Disable Dynamic Code Execution process mitigation.

  3. It increases the process base priority to 11.

  4. If the system supports hot processor add, it enables automatic processor affinity updates. That way, if new processors are added, new sessions will take advantage of the new processors.

  5. It initializes a thread pool to handle ALPC commands and other work items.

  6. It creates an ALPC port named \SmApiPort to receive commands.

  7. It initializes a local copy of the NUMA topology of the system.

  8. It creates a mutex named PendingRenameMutex to synchronize file-rename operations.

  9. It creates the initial process environment block and updates the Safe Mode variable if needed.

  10. Based on the ProtectionMode value in the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager key, it creates the security descriptors that will be used for various system resources.

  11. Based on the ObjectDirectories value in the HKLM\SYSTEM\CurrentControlSet\Control\ Session Manager key, it creates the object manager directories that are described, such as \ RPC Control and \Windows. It also saves the programs listed under the values BootExecute, BootExecuteNoPnpSync, and SetupExecute.

  12. It saves the program path listed in the S0InitialCommand value under the HKLM\SYSTEM\ CurrentControlSet\Control\Session Manager key.

  13. It reads the NumberOfInitialSessions value from the HKLM\SYSTEM\CurrentControlSet\ Control\Session Manager key, but ignores it if the system is in manufacturing mode.

  14. It reads the file rename operations listed under the PendingFileRenameOperations and PendingFileRenameOperations2 values from the HKLM\SYSTEM\CurrentControlSet\Control\ Session Manager key. 1

  15. t reads the values of the AllowProtectedRenames, ClearTempFiles, TempFileDirectory, and DisableWpbtExecution values in the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager key.

  16. It reads the list of DLLs in the ExcludeFromKnownDllList value found under the HKLM\SYSTEM\ CurrentControlSet\Control\Session Manager key.

  17. It reads the paging file information stored in the HKLM\SYSTEM\CurrentControlSet\Control\ Session Manager\Memory Management key, such as the PagingFiles and ExistingPageFiles list values and the PagefileOnOsVolume and WaitForPagingFiles configuration values.

  18. It reads and saves the values stored in the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\DOS Devices key.

  19. It reads and saves the KnownDlls value list stored in the HKLM\SYSTEM\CurrentControlSet\ Control\Session Manager key.

  20. It creates system-wide environment variables as defined in HKLM\SYSTEM\CurrentControlSet\ Control\Session Manager\Environment.

  21. It creates the \KnownDlls directory, as well as \KnownDlls32 on 64-bit systems with WoW64.

  22. It creates symbolic links for devices defined in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\DOS Devices under the \Global?? directory in the object manager namespace.

  23. It creates a root \Sessions directory in the object manager namespace.

  24. It creates protected mailslot and named pipe prefixes to protect service applications from spoofing attacks that could occur if a malicious user-mode application executes before a service does.

  25. It runs the programs part of the BootExecute and BootExecuteNoPnpSync lists parsed earlier. (The default is Autochk.exe, which performs a disk check.)

  26. It initializes the rest of the registry (HKLM software, SAM, and security hives).

  27. Unless disabled by the registry, it executes the Windows Platform Binary Table (WPBT) binary registered in the respective ACPI table. This is often used by anti-theft vendors to force the execution of a very early native Windows binary that can call home or set up other services for execution, even on a freshly installed system. These processes must link with Ntdll.dll only (that is, belong to the native subsystem).

  28. It processes pending file renames as specified in the registry keys seen earlier unless this is a Windows Recovery Environment boot.

  29. It initializes paging file(s) and dedicated dump file information based on the HKLM\System\ CurrentControlSet\Control\Session Manager\Memory Management and HKLM\System\CurrentControlSet\Control\CrashControl keys.

  30. It checks the system’s compatibility with memory cooling technology, used on NUMA systems.

  31. It saves the old paging file, creates the dedicated crash dump file, and creates new paging files as needed based on previous crash information.

  32. It creates additional dynamic environment variables, such as PROCESSOR_ARCHITECTURE, PROCESSOR_LEVEL, PROCESSOR_IDENTIFIER, and PROCESSOR_REVISION, which are based on registry settings and system information queried from the kernel.

  33. It runs the programs in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SetupExecute. The rules for these executables are the same as for BootExecute in step 11.

  34. It creates an unnamed section object that is shared by child processes (for example, Csrss.exe) for information exchanged with Smss.exe. The handle to this section is passed to child processes via handle inheritance.

  35. It opens known DLLs and maps them as permanent sections (mapped files) except those listed as exclusions in the earlier registry checks (none listed by default).

  36. It creates a thread to respond to session create requests.

  37. It creates the Smss.exe instance to initialize session 0 (non-interactive session).

  38. It creates the Smss.exe instance to initialize session 1 (interactive session) and, if configured in the registry, creates additional Smss.exe instances for extra interactive sessions to prepare itself in advance for potential future user logons. When Smss.exe creates these instances, it requests the explicit creation of a new session ID using the PROCESS_CREATE_NEW_SESSION flag in NtCreateUserProcess each time. This has the effect of calling the internal memory manager function MiSessionCreate, which creates the required kernel-mode session data structures (such as the Session object) and sets up the Session Space virtual address range that is used by the kernel-mode part of the Windows subsystem (Win32k.sys) and other session-space device drivers.

• After these steps have been completed, Smss.exe waits forever on the handle to the session 0 instance of Csrss.exe. Because Csrss.exe is marked as a critical process (and is also a protected process), if Csrss.exe exits, this wait will never complete because the system will crash.

• A session startup instance of Smss.exe does the following:

  • It creates the subsystem process(es) for the session (by default, the Windows subsystem Csrss.exe).

  • It creates an instance of Winlogon (interactive sessions) or the Session 0 Initial Command, which is Wininit (for session 0) by default unless modified by the registry values seen in the preceding steps.

  • Finally, this intermediate Smss.exe process exits, leaving the subsystem processes and Winlogon or Wininit as parent-less processes.

Windows initialization process

• The Wininit.exe process performs the following system initialization functions:

  1. It marks itself and the main thread critical so that if it exits prematurely and the system is booted in debugging mode, it will break into the debugger. (Otherwise, the system will crash.)

  2. It causes the process to treat certain errors as critical, such as invalid handle usage and heap corruption.

  3. It initializes support for state separation, if the SKU supports it.

  4. It creates an event named Global\FirstLogonCheck (this can be observed in Process Explorer or WinObj under the \BaseNamedObjects directory) for use by Winlogon processes to detect which Winlogon is first to launch.

  5. It creates a WinlogonLogoff event in the BasedNamedObjects object manager directory to be used by Winlogon instances. This event is signaled (set) when a logoff operation starts.

  6. It increases its own process base priority to high (13) and its main thread’s priority to 15.

  7. Unless configured otherwise with the NoDebugThread registry value in the HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon key, it creates a periodic timer queue, which will break into any user-mode process as specified by the kernel debugger. This enables remote kernel debuggers to cause Winlogon to attach and break into other user-mode applications.

  8. It sets the machine name in the environment variable COMPUTERNAME and then updates and configures TCP/IP-related information such as the domain name and host name

  9. It sets the default profile environment variables USERPROFILE, ALLUSERSPROFILE, PUBLIC, and ProgramData.

  10. It creates the temp directory by expanding %SystemRoot%\Temp.

  11. It sets up font loading and DWM if session 0 is an interactive session, which depends on the SKU.

  12. It creates the initial terminal, which is composed of a window station (always named Winsta0) and two desktops (Winlogon and Default) for processes to run on in session 0.

  13. It initializes the LSA machine encryption key, depending on whether it’s stored locally or if it must be entered interactively.

  14. It creates the Service Control Manager (SCM or Services.exe).

  15. It starts the Local Security Authentication Subsystem Service (Lsass.exe) and, if Credential Guard is enabled, the Isolated LSA Trustlet (Lsaiso.exe). This also requires querying the VBS provision- ing key from UEFI.

  16. If Setup is currently pending (that is, if this is the first boot during a fresh install or an update to a new major OS build or Insider Preview), it launches the setup program.

  17. It waits forever for a request for system shutdown or for one of the aforementioned system processes to terminate (unless the DontWatchSysProcs registry value is set in the Winlogon key mentioned in step 7). In either case, it shuts down the system.

Service Control Manager

• The Service Control Manager (SCM) is a special system process running the image %SystemRoot%\ System32\Services.exe that is responsible for starting, stopping, and interacting with service processes. It is also a protected process, making it difficult to tamper with.

• Service programs are really just Windows images that call special Windows functions to interact with the SCM to perform such actions as registering the service’s successful startup, responding to status requests, or pausing or shutting down the service. Services are defined in the registry under HKLM\SYSTEM\CurrentControlSet\Services.

• Services have three names: the process name you see running on the system, the internal name in the registry, and the display name shown in the Services administrative tool.

• To map a service process to the services contained in that process, use the tlist /s (from Debugging Tools for Windows) or tasklist /svc (built-in Windows tool) command.

Winlogon, LogonUI, and Userinit

• The Windows logon process (%SystemRoot%\System32\Winlogon.exe) handles interactive user logons and logoffs. Winlogon.exe is notified of a user logon request when the user enters the secure attention sequence (SAS) keystroke combination.

• The default SAS on Windows is Ctrl+Alt+Delete. The reason for the SAS is to protect users from password-capture programs that simulate the logon process because this keyboard sequence cannot be intercepted by a user-mode application.

• Winlogon.exe is active not only during user logon and logoff, but also whenever it intercepts the SAS from the keyboard.

• The identification and authentication aspects of the logon process are implemented through DLLs called credential providers. Because Winlogon.exe is a critical system process on which the system depends, credential providers and the UI to display the logon dialog box run inside a child process of Winlogon.exe called LogonUI.exe.

• When Winlogon.exe detects the SAS, it launches this process, which initializes the credential providers. When the user enters their credentials (as required by the provider) or dismisses the logon interface, the LogonUI.exe process terminates. Winlogon.exe can also load additional network provider DLLs that need to perform secondary authentication. This capability allows multiple network providers to gather identification and authentication information all at one time during normal logon.

• After the user name and password (or another information bundle as the credential provider requires) have been captured, they are sent to the Local Security Authentication Service process (Lsass.exe) to be authenticated. Lsass.exe calls the appropriate authentication package, implemented as a DLL, to perform the actual verification, such as checking whether a password matches what is stored in the Active Directory or the SAM (the part of the registry that contains the definition of the local users and groups).

• If Credential Guard is enabled, and this is a domain logon, Lsass.exe will communicate with the Isolated LSA Trustlet (Lsaiso.exe) to obtain the machine key required to authenticate the legitimacy of the authentication request.

• Upon successful authentication, Lsass.exe calls a function in the SRM (for example, NtCreateToken) to generate an access token object that contains the user’s security profile. If User Account Control (UAC) is used and the user logging on is a member of the administrators group or has administrator privileges, Lsass.exe will create a second, restricted version of the token. This access token is then used by Winlogon to create the initial process(es) in the user’s session. The initial process(es) are stored in the Userinit registry value under the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon registry key. The default is Userinit.exe, but there can be more than one image in the list.

• Userinit.exe performs some initialization of the user environment, such as running the login script and reestablishing network connections. It then looks in the registry at the Shell value (under the same Winlogon key mentioned previously) and creates a process to run the system-defined shell (by default, Explorer.exe or Edge.exe). Then Userinit exits.