User mode and kernel mode

A processor in a computer running Windows has two different modes: user mode and kernel mode. The processor switches between the two modes depending on what type of code is running on the processor. Applications run in user mode, and core operating system components run in kernel mode. While many drivers run in kernel mode, some drivers may run in user mode.

When you start a user-mode application, Windows creates a process for the application. The process provides the application with a private virtual address space and a private handle table. Because an application’s virtual address space is private, one application cannot alter data that belongs to another application. Each application runs in isolation, and if an application crashes, the crash is limited to that one application. Other applications and the operating system are not affected by the crash.

In addition to being private, the virtual address space of a user-mode application is limited. A processor running in user mode cannot access virtual addresses that are reserved for the operating system. Limiting the virtual address space of a user-mode application prevents the application from altering, and possibly damaging, critical operating system data.

All code that runs in kernel mode shares a single virtual address space. This means that a kernel-mode driver is not isolated from other drivers and the operating system itself. If a kernel-mode driver accidentally writes to the wrong virtual address, data that belongs to the operating system or another driver could be compromised. If a kernel-mode driver crashes, the entire operating system crashes.

This diagram illustrates communication between user-mode and kernel-mode components.

Windows Kernel-Mode Process and Thread Manager

A process is a software program that is currently running in Windows. Every process has an ID, a number that identifies it. A thread is an object that identifies which part of the program is running. Each thread has an ID, a number that identifies it.

A process may have more than one thread. The purpose of a thread is to allocate processor time. On a machine with one processor, more than one thread can be allocated, but only one thread can run at a time. Each thread only runs a short time and then the execution is passed on to the next thread, giving the user the illusion that more than one thing is happening at once. On a machine with more than one processor, true multi-threading can take place. If an application has multiple threads, the threads can run simultaneously on different processors.

The Windows kernel-mode process and thread manager handles the execution of all threads in a process. Whether you have one processor or more, great care must be taken in driver programming to make sure that all threads of your process are designed so that no matter what order the threads are handled, your driver will operate properly.

If threads from different processes attempt to use the same resource at the same time, problems can occur. Windows provides several techniques to avoid this problem. The technique of making sure that threads from different processes do not touch the same resource is called synchronization. For more information about synchronization, see Synchronization Techniques.

Routines that provide a direct interface to the process and thread manager are usually prefixed with the letters «Ps«; for example, PsCreateSystemThread. For a list of kernel DDIs, see Windows kernel.

This set of guidelines applies to these callback routines:

• Keep routines short and simple.
• Do not make calls into a user mode service to validate the process, thread, or image.
• Do not make registry calls.
• Do not make blocking and/or Interprocess Communication (IPC) function calls.
• Do not synchronize with other threads because it can lead to reentrancy deadlocks.
• Use System Worker Threads to queue work especially work involving:
  • Slow API’s or API’s that call into other process.
  • Any blocking behavior which could interrupt threads in core services.
• If you use System Worker Threads do not wait on the work to complete. Doing so defeats the purpose of queuing the work to be completed asynchronously.
• Be considerate of best practices for kernel mode stack usage. For examples, see How do I keep my driver from running out of kernel-mode stack? and Key Driver Concepts and Tips.

Subsystem Processes

Starting in WindowsВ 10, the Windows Subsystem for Linux (WSL) enables a user to run native Linux ELF64 binaries on Windows, alongside other Windows applications. For information about WSL architecture and the user-mode and kernel-mode components that are required to run the binaries, see the posts on the Windows Subsystem for Linux blog.

One of the components is a subsystem process that hosts the unmodified user-mode Linux binary, such as /bin/bash. Subsystem processes do not contain data structures associated with Win32 processes, such as Process Environment Block (PEB) and Thread Environment Block (TEB). For a subsystem process, system calls and user mode exceptions are dispatched to a paired driver.

Here are the changes to the Process and Thread Manager Routines in order to support subsystem processes:

• The WSL type is indicated by the SubsystemInformationTypeWSL value in the SUBSYSTEM_INFORMATION_TYPE enumeration. Drivers can call NtQueryInformationProcess and NtQueryInformationThread to determine the underlying subsystem. Those calls return SubsystemInformationTypeWSL for WSL.
• Other kernel mode drivers can get notified about subsystem process creation/deletion by registering their callback routine through the PsSetCreateProcessNotifyRoutineEx2 call. To get notifications about thread creation/deletion, drivers can call PsSetCreateThreadNotifyRoutineEx, and specify PsCreateThreadNotifySubsystems as the type of notification.
• The PS_CREATE_NOTIFY_INFO structure has been extended to include a IsSubsystemProcess member that indicates a subsystem other than Win32. Other members such as FileObject, ImageFileName, CommandLine indicate additional information about the subsystem process. For information about the behavior of those members, see SUBSYSTEM_INFORMATION_TYPE.

—>

Windows Kernel-Mode I/O Manager

A computer consists of various devices that provide input and output (I/O) to and from the outside world. Typical devices are keyboards, mice, audio controllers, video controllers, disk drives, networking ports, and so on. Device drivers provide the software connection between the devices and the operating system. For this reason, I/O is very important to the device driver writer.

The Windows kernel-mode I/O manager manages the communication between applications and the interfaces provided by device drivers. Because devices operate at speeds that may not match the operating system, the communication between the operating system and device drivers is primarily done through I/O request packets (IRPs). These packets are similar to network packets or Windows message packets. They are passed from operating system to specific drivers and from one driver to another.

The Windows I/O system provides a layered driver model called stacks. Typically IRPs go from one driver to another in the same stack to facilitate communication. For example, a joystick driver would need to communicate to a USB hub, which in turn would need to communicate to a USB host controller, which would then need to communicate through a PCI bus to the rest of the computer hardware. The stack consists of joystick driver, USB hub, USB host controller, and the PCI bus. This communication is coordinated by having each driver in the stack send and receive IRPs.

It cannot be stressed enough that your driver must send and receive IRPs on a timely basis for the whole stack to operate efficiently. If your driver is part of a stack and does not properly receive, handle, and pass on the information, your driver may cause system crashes.

For more information about IRPs, see Handling IRPs.

For more information about driver stacks, see Device Objects and Device Stacks.

For programming techiques related to I/O management, see I/O Manager Programming Techniques.

Routines that provide a direct interface to the I/O manager are usually prefixed with the letters «Io«; for example, IoCreateDevice. For a list of I/O manager routines, see I/O Manager Routines.

For lists of routines that relate to IRPS, see IRPs.

The I/O manager has two subcomponents: the Plug and Play manager and power manager. They manage the I/O functionality for the technologies of PlugВ andВ Play and power management. For more information about PlugВ andВ Play management, see Windows Kernel-Mode Plug and Play Manager and for more information about power management, see Windows Kernel-Mode Power Manager.

Kernel-Mode Driver Architecture Design Guide

For information about programming interfaces that your driver can implement or call, see the Kernel-Mode Driver Reference.

This section includes general concepts to help you understand kernel-mode programming and describes specific techniques of kernel programming. For a general overview of Windows Drivers, see Getting Started with Windows Drivers, which provides a general overview of Windows components, lists the types of device drivers used in Windows, discusses the goals of Windows device drivers, and discusses generic sample device drivers included in the kit.

This section contains conceptual information that describes and helps you build kernel-mode drivers.

An Overview containing:

Kernel-Mode Components describes the primary kernel-mode managers and components of the Windows operating system.

Component	Description
Managers
Windows Kernel-Mode Object Manager	Manages objects: files, devices, synchronization mechanisms, registry keys, and so on.
Windows Kernel-Mode Memory Manager	Manages physical memory for the operating system.
Windows Kernel-Mode Process and Thread Manager	Handles the execution of all threads in a process.
Windows Kernel-Mode I/O Manager	Manages the communication between applications and the interfaces provided by device drivers.
Windows Kernel-Mode Plug and Play Manager	A subsystem of the I/O manager, the Plug and Play (PnP) Manager enables a PC to recognize when a device is added to the system.
Windows Kernel-Mode Power Manager	Manages the orderly change in power status for all devices that support power state changes.
Windows Kernel-Mode Configuration Manager	Manages the registry, such as monitoring changes in the registry or registering callbacks on specific registry data.
Windows Kernel-Mode Kernel Transaction Manager	Implements transaction processing in kernel mode.
Windows Kernel-Mode Security Reference Monitor	Provides routines for your driver to work with access control.
Libraries
Windows Kernel-Mode Kernel Library	Implements the core functionality that everything else in the operating system depends upon. The Microsoft Windows kernel provides basic low-level operations such as scheduling threads or routing hardware interrupts.
Windows Kernel-Mode Executive Support Library	Refers to kernel-mode components that provide a variety of services to device drivers, including: object management, memory management, process and thread management, input/output management, and configuration management.
Windows Kernel-Mode Run-Time Library	A set of common utility routines needed by various kernel-mode components.
Windows Kernel-Mode Safe String Library	A safe string library to provide greater security in kernel-mode development.
Windows Kernel-Mode DMA Library	A direct memory access (DMA) library for device driver developers.
Windows Kernel-Mode HAL Library	A hardware abstraction layer (HAL) for kernel-mode driver development.
Windows Kernel-Mode CLFS Library	A transactional logging system, the Common Log File System (CLFS).
Windows Kernel-Mode WMI Library	A general mechanism for managing components, called Windows Management Instrumentation (WMI).

Writing WDM Drivers and Introduction to WDM provide information needed to write drivers using the Windows Driver Model (WDM).

Device Objects and the other topics in Device Objects and Device Stacks describe how the operating system represents devices by device objects.

Memory Management for Windows Drivers illustrates how kernel-mode drivers allocate memory for purposes such as storing internal data, buffering data during I/O operations, and sharing memory with other kernel-mode and user-mode components.

Security From Controlling Device Access and Privileges to SDDL for Device objects, ensure that your drivers are as secure as possible.

Handling IRPs describes how kernel-mode drivers handle I/O request packets (IRPs).

DMA Direct Memory Access (DMA) is a critical aspect of driver development, and the topics in this node cover DMA from A to Z.

Controller Objects represent a physical device controller with attached devices.

Interrupt Service Routines (ISRs) handle interrupts for drivers of a physical device that receives interrupts.

Message-Signaled Interrupts trigger an interrupt by writing a value to a particular memory address.

Deferred Procedure Calls (DPC Objects) can be queued from ISRs and are executed at a later time and at a lower IRQL than the ISR.

Plug and Play (PnP) focuses on the system software support for PnP and how drivers use that support to implement PnP.

Power Management describes the architecture that provides a comprehensive approach to system and device power management.

Windows Management Instrumentation (WMI) are extensions to your kernel-mode driver, which enable your driver to become a WMI provider. A WMI provider makes measurement and instrumentation data available to WMI consumers, such as user-mode applications.

Driver Programming Techniques Programming drivers in the kernel mode of Windows requires techniques that sometimes differ significantly from those of ordinary user-mode programming.