Introduction to Windows Operating System Architecture

---

The Windows system architecture consists of the following components:

1. Kernel: The Windows kernel is the core part of the operating system. It is responsible for tasks such as managing system resources, handling requests from user programs and drivers, and coordinating communication between various system components. The Windows kernel is divided into user mode and kernel mode. The kernel mode is a higher-level and safer mode, and user programs cannot directly access the kernel mode.

2. Drivers: Windows systems require many different types of drivers to manage hardware devices and provide system functionality, such as network drivers, sound card drivers, graphics drivers, and more. These drivers run in kernel mode and can access the underlying resources and hardware devices of the system.

3. User Mode: User mode is the mode in which applications are run in the Windows operating system. In user mode, applications can access some system resources, such as file systems, networks, processes, and threads, but cannot directly access kernel mode or underlying hardware devices.

4. Win32 subsystem: The Win32 subsystem is an application programming interface in the Windows operating system that allows 32-bit applications to run on the Windows operating system. The Win32 subsystem provides a standard interface for accessing operating system resources and functions, enabling applications to run on various Windows systems.

5. Windows API: The Windows API is a set of application programming interfaces for accessing various resources and functions of the Windows operating system. The Windows API can be used in any programming language, including C/C++, Java, Python, and C#, among others.

6. User Interface: The user interface of the Windows operating system includes components such as the desktop, taskbar, windows, menus, and dialog boxes. Implemented through the Windows API and user mode, these components provide the means by which the user interacts and operates with the operating system.

Generally speaking, the Windows system architecture is a complex system including multiple components and modes, through which these components and modes work together to provide a stable, secure, and easy-to-use operating system environment.

Here will briefly introduce the basic system architecture of Windows. Through the content of the previous chapters, we already know that Windows is divided into two parts: user mode and kernel mode. A simple schematic diagram is as follows:

Here you can see a "virtual machine monitor" at the bottom layer, which also runs in kernel mode (RING-0), but because i uses special CPU instructions (VT-x, SVM), it can continue to monitor the kernel (or application) while isolating itself from the kernel. So we often hear the name Ring-1.

The 4 Basic Types of User-Mode Processes

Here we need to briefly introduce the four basic user-mode processes under the Windows operating system:

• user process
• service process
• system process
• Environment Subsystem Server Process

user process

User processes can be one of the following types:

• A 32-bit or 64-bit (and in Windows 8 and later, Windows apps that run on top of the Windows Runtime) process of Windows.
• 16-bit process for Windows 3.1
• 16-bit process for MS-DOS
• 32-bit or 64-bit processes for POSIX

(Note: 16-bit processes can only run on 32-bit Windows, and Windows 8 no longer supports POSIX applications)

service process

The service process hosts Windows services such as the Task Scheduler and Print Spooler services.

Typically, services need to be able to run without the user being logged on, as many Windows server applications do. Services such as Microsoft SQL Server and Microsoft Exchange Server also contain components that run as services.

system process

System processes are static or hard-coded processes, such as login processes and session managers for non-Windows services. That is, these processes are not started by the Service Control Manager.

Environment Subsystem Service Process

Environment subsystem service processes are those that implement the supporting parts of the operating system environment.

The so-called "environment" refers to the personalization part of the operating system presented to users and programmers. When Windows NT first launched, it provided three environmental subsystems: Windows, POSIX, and OS/2. But support for the OS/2 subsystem stopped after Windows 2000, and support for POSIX stopped after Windows XP. Windows 7 Ultimate and Enterprise client and server editions of Windows 2008 R2 provide an enhanced POSIX subsystem called Subsystem for UNIX-based Applications (SUA). SUA is now end of support and is no longer included as an optional feature in Windows (client or server editions).

Windows kernel-mode components

In Windows, user applications cannot directly call native Windows operating system services, but need to call through one or more subsystem dynamic link libraries (DLL). The role of the subsystem DLL is to translate documented functions into corresponding internal (often undocumented) native system service calls, which are usually implemented in Ntdll.dll. This conversion may or may not involve sending messages to the environment subsystem process for servicing the user process.

The Windows kernel-mode components are as follows:

• Executor. The Windows executive contains the basic services of the operating system, such as memory management, process and thread management, security, I/O, networking, and interprocess communication.
• Windows kernel. The Windows kernel contains low-level operating system functions such as thread scheduling, interrupt and exception dispatch, and multiprocessor synchronization. The kernel also provides a series of routines and basic objects that other parts of the executive use to implement higher-level functions.
• device driver. Device drivers include hardware device drivers that translate user I/O function calls into I/O requests for specific hardware devices, as well as nonhardware device drivers such as file system and network drivers.
• Hardware abstraction layer (HAL, hardware abstraction layer). This layer of code is responsible for isolating the kernel, device drivers, and other parts of the Windows executive from platform-specific differences.
• Window and graphics system. The windowing and graphics system is used to implement user interface (GUI) functions (also commonly referred to as Windows USER and GDI functions), such as handling windows, user interface controls, and drawing.
• Hypervisor layer. This section only contains the hypervisor itself. This section contains no other drivers or modules. But the hypervisor itself is made up of various internal layers and drivers, such as its own memory manager, virtual processor scheduler, interrupt and timer management, synchronization routines, partition (virtual machine instance) management, inter-partition communication (IPC), etc.

important system components

The basic structure of Windows and common process types have been mentioned earlier, and the content of Windows system components has also been mentioned incidentally. The following figure combines this part of the system components to visualize the Windows core system architecture and components.

From the figure above, we can see that several important system components in the Windows operating system environment are:

1. Ambient Subsystems and Subsystem DLLs
2. other subsystems
3. Executor
4. kernel
5. hardware abstraction layer
6. device driver
7. system process

The following is a detailed description and introduction of the above content analysis.

Ambient Subsystems and Subsystem DLLs

The role of the environment subsystem is to expose some subset of basic Windows executive system services to applications. Such subsystems can access a different subset of Windows native services. This means that an application built on one subsystem may not be able to do something that an application built on another subsystem can do. For example, Windows applications cannot use SUA's fork function.

Each executable image (.exe) is bound to a unique subsystem. When the image is running, the code responsible for creating the process checks the type code of the subsystem in the image header, and then notifies the new process to the correct subsystem. This type code can be specified by using the /SUBSYSTEM linker option in the linker command of Microsoft Visual Studio (or by using the SubSystem option of the Linker/System property page in the project properties).

As mentioned earlier, user applications do not call Windows system services directly, but through one or more subsystem DLLs. The interfaces exported by these libraries have corresponding documentation, and the programs linked to the corresponding subsystems can be called. For example, the Windows subsystem DLLs (such as Kernel32.dll, Advapi32.dll, User32.dll, and Gdi32.dll) implement the Windows API functions, and the SUA subsystem DLL (Psxdll.dll) implements the SUA API functions.

Here, you can use the Dependency Walker tool (Dependency.exe) to view the subsystem type of the image file. (About this tool, you can check how to download and use it mentioned in this article, https://blog.csdn.net/qq_37596943/article/details/131515390?spm=1001.2014.3001.5501）

Check the Notepad.exe and CMD.exe that come with the Windows operating system respectively.

As can be seen from the above two figures, the dependent DLL of Notepad.exe is completely different from the dependent DLL of CMD.exe. And Notepad.exe will depend on GDI32.DLL because it is a GUI application, while CMD.exe simply depends on the most basic NTDLL.DLL library.

Here's what happens when an application calls a function in a subsystem DLL:

• Functions are implemented entirely in user mode inside the subsystem DLL. In other words, no messages are sent to the environment subsystem process, nor are any Windows executive system services called. The function will be executed in user mode, and the execution result will be returned to the caller, such as GetCurrentProcess and GetCurrentProcessId functions. (A running process ID does not change, so the ID can be obtained from some cached location to avoid calls to the kernel.)
• A function requires one or more calls to the Windows executive. For example, the Windows ReadFile and WriteFile functions call the underlying internal (and undocumented for user-mode use) Windows I/O system services NtReadFile and NtWriteFile, respectively.
• A function to perform some work in the environment subsystem process. (The environment subsystem process running in user mode is responsible for maintaining the state of the client applications running under its control.) In this case, client/server requests are sent to the environment subsystem in the form of messages through ALPC, so that the subsystem can perform the required operation. The subsystem DLL then waits for a response and returns it to the caller.

Some functions will be used in combination with the second and third above, such as Windows' CreateProcess and ExitWindowsEx functions.

Startup of the subsystem

The subsystem is started by the session manager (Smss.exe) process. Subsystem startup information is stored in the registry under the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems key.

The Required key in the figure lists the subsystems loaded at system boot. The value consists of two strings: Windows and Debug.

The Windows value contains the file specification for the Windows subsystem, where Csrss.exe represents the client/server runtime subsystem.

The Debug value is empty (this value is not needed since Windows XP, and the unit remains for compatibility), so it will not take effect.

The optional value represents an optional subsystem, which is also empty in this example, because Windows 10 can no longer use SUA. What would have been available would be to point a value through POSIX to another value, which in turn points to Psxss.exe (the POSIX subsystem process). Optional values ​​are all "load on demand", which means that the POSIX image will be loaded when it first encounters it. The Kmode registry value contains the filename of the kernel-mode portion of the Windows Subsystem (Win32K.sys).

Windows Subsystem

While Windows was designed to support multiple independent environmental subsystems, actually having each subsystem implement all the code to handle window and display I/O would create a lot of duplication of system functions that would ultimately adversely affect system size and performance. Since Windows is the most important subsystem, the designers of Windows decided to put basic functions in the Windows subsystem and let other subsystems call the Windows subsystem to achieve display I/O, so the SUA subsystem calls services in the Windows subsystem to achieve display I/O.

As a result of this design decision, the Windows subsystem has become a mandatory component of any Windows system, even on server systems that do not provide interactive user logins. So this process also becomes a critical process (if the process exits for any reason, then the system will crash).

The Windows subsystem consists of the following important components:

1. For each session, an instance of the Environment Subsystem process (Csrss.exe) loads 4 DLLs (Basesrv.dll, Winsrv.dll, Sxssrv.dll, Csrsrv.dll), thereby providing support for:

• Various administrative tasks related to the creation and deletion of processes and threads
• Closing of Windows applications (via ExitWindowsEx API)
• Contains .ini files for registry location mappings to maintain backwards compatibility
• Send certain kernel notification messages (such as those from the Plug and Play manager) to Windows applications as Windows messages (WM_DEVICECHANGE)
• Partial support for 16-bit Virtual Machine for DOS (VDM) processes (32-bit Windows only)
• Support for Side-by-Side (SxS)/Fusion and Manifest Caching
• Provides caching for various natural language support functions

2. A kernel-mode device driver (Win32k.sys) that provides the following support.

• window manager. Controls the display of windows, manages screen output, collects input from the keyboard, mouse, and other devices, and passes user messages to applications
• Graphics Device Interface (GDI). This is a function library specially designed for graphics output devices, including drawing functions related to lines, text and graphics, as well as graphics control functions.
• Wrapper functions for DirectX functionality. This is a function implemented by another kernel-mode driver (Dxgkrnl.sys).

3. Console host process (Conhost.exe), used to provide support for console (character interface) applications.
4. The Desktop Window Manager (Dwm.exe), which renders results in a surface layer visible to windows via CDD and DirectX.
5. Subsystem DLLs (such as Kernel32.dll, Advapi32.dll, User32.dll, Gdi32.dll) that translate documented Windows API functions into corresponding undocumented (for user mode) kernel-mode system service calls in Ntoskrnl.exe and Win32k.sys.
6. Graphics device driver. Used to provide hardware-dependent graphics display drivers, printer drivers, and video miniport drivers.

Windows 10 and Win32k.sys

The most basic window management requirements for Windows 10 devices are highly dependent on the specific device type, a full desktop computer running Windows needs to have all the window management capabilities such as resizing windows, window owners, child windows, etc. And Windows mobile 10 running on a phone or a small tablet doesn't need as much because there's only one foreground window that can't be minimized or resized. The same is true for IoT devices, which may not even need a display at all.

Therefore the functionality of Win32K.sys is split into multiple kernel modules, and some systems may not require all of these modules. This greatly reduces the attack surface of the window manager due to the reduced code complexity and removes a lot of legacy code.

• On mobile (Windows mobile 10), Win32k.sys loads Win32kMin.sys and Win32kBase.sys
• On a full desktop computer system, Win32k.sys loads Win32kBase.sys and Win32kFull.sys
• In some IoT systems, Win32k.sys may only need to load Win32kBase.sys

Applications need to call standard USER functions to create controls on the user interface, such as windows and buttons, and display them on the screen. The window manager passes these requests to GDI, which passes them on to the graphics device driver, which makes the necessary adjustments in conjunction with the display device. Display drivers are paired with view miniport drivers to provide support for full video display.

GDI provides a standard set of two-dimensional functions that allow applications to communicate with a graphics device without knowing anything about it. GDI functions sit between applications and graphics devices such as display drivers and printer drivers, and are responsible for interpreting image output requests from applications and sending the requests to graphics display drivers. GDI also provides a standardized interface for applications using different graphics output devices. With these interfaces, application code can remain independent from hardware devices and their drivers. GDI also tailors the message to the capabilities of the device, typically breaking the request into manageable parts. For example, some devices can understand commands to draw an ellipse, and some devices may require GDI to interpret the commands as "a series of pixels placed at a certain coordinate position".

Since most of the subsystem runs in kernel mode, only a few Windows functions need to send messages to the Windows Subsystem process for process and thread creation and termination, DOS device drive letter mapping, and so on.

other subsystems

As mentioned earlier, Windows initially supported the POSIX and OS/2 subsystems. Since the new Windows does not contain these subsystems, it will not be described in detail here.

Pico Provider and Windows Subsystem for Linux

Over the past decade or so, the traditional subsystem model has provided support for POSIX and OS/2 with sufficient scalability and capacity. However, two technical limitations of this model make it difficult to apply to a wider range of non-Windows binaries, and can only be used in some very specific scenarios.

In order to solve a series of problems left by POSIX compatibility under Windows. Windows now uses a new way of building subsystems that eliminates the need for traditional user-mode wrapping of system calls from other environments and execution of traditional PE images.

This model defines the concept of a Pico provider. This is a custom kernel-mode driver that receives access to a dedicated kernel interface through the PsRegisterPicoProvider API. This dedicated interface brings many benefits.

primeval image

Use Dependency Walker to open Smss.exe (session manager process), you can see that it only depends on Ntdll.dll, and here it shows that its subsystem is Native.

Executor

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

• Functions that can be called everywhere and from user mode. These functions are called system services and are available everywhere through Ntdll.dll.
• A device driver function called through DeviceIoControl. This provides a common interface for calling functions in device drivers from user mode to kernel mode, allowing calls to functions that are not related to read/write operations.
• A function that can only be called from kernel mode and is exported and documented in the WDK. These functions contain a variety of supporting routines, such as I/O manager, general executive functions (Ex), etc.
• Functions that are exported and called in kernel mode but are not documented in the WDK. These functions include functions called by the boot video driver, beginning with Inbv.
• A function defined as a global symbol but not exportable. These functions include support functions that are called internally in Ntoskrnl.exe, such as those beginning with Iop (internal I/O manager support functions) or Mi (internal memory management support functions).
• A function inside a module but not defined as a global symbol. These functions are executive and kernel specific.

For the main components of the executive body, here is a brief list:

1. configuration manager
2. process manager
3. Safe Reference Monitor
4. I/O manager
5. Plug and Play (PnP, Plug and Play) manager
6. power manager
7. Windows Driver Model (WDM)
8. memory manager
9. cache manager
10. object manager
11. Asynchronous LPC (ALPC) facility
12. runtime library functions
13. Executive support routines.

In addition, various other infrastructure routines are included:

• Kernel-mode debugger library.
• User Mode Debugging Framework
• Hypervisor library and VBS library
• Errata Manager
• Driver Verifier
• Time Tracking for Windows (ETW)
• Windows Diagnostic Infrastructure
• Windows Hardware Error Architecture
• file system runtime
• Kernel shim engine

kernel

The kernel consists of a series of functions in Ntoskrnl.exe to provide basic mechanisms, such as thread scheduling and synchronization services used by executables, and support independent of the underlying hardware architecture. The kernel code is primarily written in C, although assembly code continues to be used for tasks that require the use of special processor instructions and registers that are difficult to access in C code.

Many kernel functions are documented in the WDK (search for functions starting with Ke) because they are also required for device driver implementations.

kernel object

The kernel provides a well-defined, predictable underlying primitives and mechanisms of the operating system, which can be used by the high-level components in the executive body to perform the operations they need.

Outside the kernel, the executive body sees threads and other shared resources as objects.

There is a set of kernel objects called control objects that establish the semantics needed to control various operating system functions. These include Asynchronous Procedure Call (APC) objects, Deferred Procedure Call (DPC) objects, and various objects used by the I/O Manager, such as interrupt objects.

Another set of kernel objects called dispatcher objects contain synchronization capabilities that can change or affect the scheduling of threads. Dispatcher objects include kernel threads, mutexes, times, kernel event pairs, semaphores, timers, and waitable timers. The executive body uses kernel functions to create and maintain kernel object instances, build more complex objects and provide them to user mode.

Kernel Processor Control Region (KPCR) and Control Block

The kernel uses a data structure called the Kernel Processor Control Region (KPCR) to store processor-related data. KPCR contains some basic information, such as the processor's interrupt distribution table (interrupt Dispatch Table, IDT), task state segment (Task State Segment, TSS) and global descriptor table (Global Descriptor Table, GDT).

KPCR also contains interrupt controller state, which is shared with other modules (ACPI, HAL).

The KPCR also contains an embedded data structure called the Kernel Processor Control Block (KPRCB). For use by third-party drivers and other internal Windows kernel components, KPCR is a documented data structure; while KPCB is a private structure used exclusively by kernel code in Ntoskrnl.exe, which contains the following:

• Scheduling information. Such as the current thread being scheduled on the processor, the next executing thread, and the idle thread
• The processor's distributor database. which contains a ready queue for each priority
• DPC queue
• CPU vendor and identifier information such as model, stepping, speed, flags
• CPU and NUMA topologies. Such as node information, number of cores per chip, number of logical processors per core, etc.
• cache size
• Time count information such as DPC and interrupt time.

You can use !prcb to view the address and data information of PRCB through windbg

hardware support

Another important job of the kernel is to abstract or abstract executives and device drivers from the differences in the different hardware architectures supported by Windows. This job also includes handling differences between various functions such as interrupt handling, exception dispatch, and processor synchronization.

hardware abstraction layer

The Hardware Abstraction Layer (HAL) is the key to portability. HAL is a loadable kernel-mode module (Hal.dll) that provides a low-level interface to hardware platforms running Windows. It can hide details related to specific hardware such as I/O interfaces, interrupt controllers, multiprocessor communication mechanisms, and functions related to specific architectures and computers.

Many HAL routines are introduced in WDK, you can refer to WDK documentation for details. The specific modules are described as follows:

HAL file name	supported system
Halacpi. dll	Advanced configuration and power interface (ACPI) computer, implying that there is only one processor and does not support APIC (interrupt controller). If any of the two conditions are not met, use the following HAL
Halmacpi. dll	Advanced Programmable Interrupt Controller (APIC) computers that support ACPI, using an APIC also means supporting SMP

Here, you can use the Dependency Walker tool to view the dependencies of Ntoskrnl.exe.

Several of the DLL libraries can be seen.

• PSHED.DLL. A Platform-Specific Hardware Error Driver (PSHED) provides an abstraction for the underlying platform's hardware error reporting capabilities. This is accomplished by hiding the platform's error handling mechanisms from the operating system and exposing a consistent interface to the Windows operating system.
• BOOTVID.DLL. The boot video driver (Boorvid) on X86 systems provides support for the VGA commands required to display boot text and boot logos during system startup.
• KDCOM.DLL. Kernel-mode debugger protocol (KD) communication library.
• CI.DLL. integrity library
• MSRPC.SYS. A thin remote procedure call (RPC) client driver for kernel mode that allows the kernel (and other drivers) to communicate with user-mode services via RPC, or to manage resources for MES code.

device driver

A device driver is a loadable kernel-mode module (its file usually has a .sys extension) that establishes an interface between the I/O manager and associated hardware. A device driver runs in kernel mode using one of the following three contexts.

1. In the context of a user thread that initiates an I/O function (such as a read operation)
2. In the context of a kernel-mode system thread (such as a request initiated by the Plug and Play manager)
3. Not in any particular thread context as a result of an interrupt, but in the "current" thread context when the interrupt occurred.

The Windows device driver does not directly operate the hardware, but calls the functions in the HAL to interact with the hardware. Drivers are usually written in C or C++, so proper use of HAL routines enables source-level portability between different CPU architectures supported by Windows, and binary portability within the same architecture family.

Device drivers mainly include the following types:

• Hardware device drivers. Use the HAL to manipulate hardware to write output to, or take input from, a physical device or network. Hardware device drivers include many types, such as bus drivers, human-machine interface drivers, mass storage device drivers, and so on.
• File system driver. A Windows driver that takes a file-oriented I/O request and translates it into a device-specific I/O request.
• File system filter driver. Includes drivers that perform disk mirroring and encryption, scan for viruses, intercept I/O requests, and perform additional processing before passing I/O to the next layer.
• Network redirection and servers. This file system driver is responsible for passing file system I/O requests to other computers on the network, or receiving requests from other computers over the network, respectively.
• protocol driver. Responsible for implementing network protocols such as TCP/IP, NetBEUI, and IPX/SPX.
• Kernel streaming filter driver. Such drivers are wired together to perform signal processing on the data stream, such as recording or playing audio and video.
• software drivers. Such a kernel module will perform operations that can only be performed in kernel mode on behalf of some user-mode process.

Windows Driver Model

The original Windows driver was created in the first version of the NT system (3.1), but due to Plug and Play (PnP) reasons (NT drivers do not support PnP), it continued until Windows 2000 was released to support PnP drivers, through WDM. The driver model (Windows driver model, WDM) supports PnP and power option support. Until now, WDM has been preserved after many updates, and has become the basic model for writing hardware drivers for Windows 2000 and subsequent versions.

WDM driver models can be divided into three types:

1. bus driver. Serves bus controllers, adapters, bridges, or any device with sub-devices. There is a bus driver for each type of bus in the system. Third-party vendors can write bus drivers to provide support for new bus types such as VMEbus, Multibus, and Futurebus.
2. Function driver. It is the most important device driver, which provides an operable interface for the corresponding device. Unless the device is running in raw (RAW) mode (I/O is done by bus drivers and bus filters together), the function driver is the driver required for the device, and usually the only driver that can access the registers associated with the device.
3. filter driver. Filter drivers can be used to add additional functionality to a device or to an existing driver sequence. Or modify I/O requests or responses from other drivers. Typically used to repair hardware devices that do not correctly provide information about hardware resource requirements. Filter drivers are optional and can exist in any number above or below function drivers. Filter drivers are typically provided by the system original equipment manufacturer (OEM) or independent hardware vendor (IHV).

In a WDM driver environment, no single driver can control every aspect of a device. The bus driver is responsible for reporting the devices connected to the bus to the PnP manager, and the function driver is responsible for operating the devices.

Windows Driver Basics

Windows Driver Foundation (Windows driver foundation, WDF) provides a kernel-mode driver framework (kernel-mode driver framework, KMDF) and user-mode driver framework (user-mode driver framework, UMDF). These two frameworks simplify the development of Windows drivers.

KMDF provides a more simplified WDM interface, and hides the complexity of the driver development process without changing the underlying bus, bus, and filter models. A KMDF driver responds to things it can register with, and calls the KMDF library to perform various jobs that are not specific to the device it manages, such as general power management and synchronization. In some cases, a single KMDF function call can replace a large amount of WDM code to implement the operation.

UMDF enables user-mode drivers for certain types of devices (mostly USB devices or other high-latency protocol buses, such as video cameras, MP3 players, cell phones, printers, etc.). Essentially, UMDF runs each user-mode driver as a user-mode service and uses ALPC to communicate with the wrapper driver running in kernel-mode to actually access the hardware. If the UMDF driver crashes, the process "dies" and is usually restarted. This will not cause the system to become unreliable, the only cost is that the device is temporarily unavailable while the service host restarts the driver.

Universal Windows Driver

Starting from Windows 10, you can use the universal Windows driver (universal Windows driver, UWD) to use the shared API and device driver interface (device driver interface, DDI) provided by the Windows 10 universal kernel to realize "write once, execute everywhere" of the driver. This type of driver can achieve binary compatibility for a specific CPU architecture and can be used in different forms of devices including IoT devices, mobile phones, HoloLens, Xbox one, and laptops. Universal Windows drivers can use KMDF, UMDF 2.x, or WDM as their driver model.

You can use Msinfo32.exe to check the installed device drivers.

It can be seen from the figure that we can find the currently installed device driver here, and also display the location of the driver file corresponding to the driver and the status of the current service.

When we manually start the service, we can also see that it is now running.

You can also use the process explorer tool to view the currently loaded device drivers through the system process.

system process

Every Windows 10 system contains some special system processes. They do not run user-mode executables; such processes are called minimal processes. (Example: Idle, system, secure system, memory compression)

• Idle process. Contains one thread per CPU to take up idle CPU time
• System process. Contains most kernel-mode system threads and handles
• secure system process. Contains the address space of the secure kernel under VTL1
• memory compression process. Contains the compressed workload of user-mode processes
• Session Manager (Smss.exe)
• Windows Subsystem (Csrss.exe)
• Session 0 initialization (Wininit.exe)
• The Logon process (Winlogon.exe)
• Service Control Manager (services.exe) and its child service processes created, such as the regular service host process (Svchost.exe) provided by the system
• Local Security Authentication Service (Lsass.exe), and Local Security Authentication Server (Lsaiso.exe) isolated after Credential Guard is enabled

You can view the process tree by opening the Process explorer tool to know who created the above processes, which is helpful to understand the source of each process.

appendix

Commonly used API interface naming meaning

The name prefixes of most functions commonly used by Windows executive components have certain meanings. For example, the first letter of the prefix is ​​followed by i (for internal), and the full prefix is ​​followed by the letter p (for private). The common ones are as follows:

prefix	components
Alpc	advanced local procedure call, advanced local procedure call
Cc	public cache, common cache
Cm	configuration manager, configuration manager
Dbg	Kernel debugging support, kernel debug support
Dbgk	User mode debugging framework, debugging framework for user mode
Em	errata manager, errata manager
sth	Windows Event Tracing, event tracing for Windows
Ex	Executive support routine, executive support routine
FsRtl	file system runtime library, file system runtime library
Hv	Hive library, hive library
Hvl	hypervisor library
Io	I/O manager
Kd	kernel mode debugger, kernel debugger
When	kernel
Mr	Kernel shim engine, kernel shim engine
Lsa	local security authority, local security authority
Mm	memory manager, memory manager
Nt	NT system service, NT system service, accessible through system calls in user mode
Ob	object manager
Pf	Pre-reader, Prefetchr
After	Power manager, Power manager
PoFx	power framework, power framework
Pp	PnP manager, PnP manager
Ppm	processor power manager, processor power manager
Ps	Process support, process support
Rtl	Runtime library, Run-time library
Se	security reference monitor, security reference monitor
Sm	store manager
Tm	transaction manager
Ttm	terminal timeout manager, terminal timeout manager
Vf	driver verifier, driver verifier
Vsl	virtual secure mode library, virtual secure mode library
Wdi	Windows diagnostic infrastructure, Windows diagnostic infrastructure
Wfp	Windows fingerprint, Windows finger print
Where	Windows hardware error architecture, Windows hardware error architecture
Wmi	Windows management instrumentation
Zw	System service entry point mirror, which can set the previous access mode to kernel mode.

In general, the naming convention for Windows routines is as follows:

<Prefix><Operation><Object>

Summary of the main content of this article