Overview of the UMDF

The User-Mode Driver Framework (UMDF) architecture allows hardware vendors to create user-mode drivers for their hardware that provides more security and stability to the operating system than kernel-mode drivers. If a kernel-mode driver crashes, then the entire system crashes; if a user-mode driver crashes, then only the process hosting the driver crashes, while the rest of the system remains stable. The UMDF architecture contains the following components:

• UMDF drivers

  UMDF drivers abstract hardware functionality, run in the user-mode environment, and can access various services. UMDF drivers operate as part of a stack of drivers that manage a device. File system drivers, display drivers, and print drivers cannot be UMDF drivers.

• Driver host process

  A driver host process contains UMDF drivers, the framework, and a runtime environment for the framework and drivers. The driver host process is isolated from the application process and other driver host processes. The driver host process runs in the LocalService account. One stack of drivers per device exists. This driver stack consists of function and filter drivers for a particular device. The stack is accessible to applications running in different sessions and provides a central point for arbitrating access to the device. The runtime environment handles I/O dispatching, driver loading, driver layering, thread pool, and messages from the reflector and driver manager.

• Reflector

  The reflector is a Microsoft Windows Driver Model (WDM) kernel-mode driver that permits an application and a driver host process to communicate. The reflector creates a separate device object for each device instance and handles Plug and Play (PnP) and power I/O requests associated with each device instance. All communication between the application and the driver host process happens through the reflector.

• Driver manager

  The driver manager can be thought of as an extension to the reflector. The driver manager launches and tracks information about each driver host process, which is a child process of the driver manager. Only one driver manager exists per system. The driver manager starts during installation of the first UMDF device and runs on the system thereafter.

Similar to the kernel-mode driver framework (KMDF), the UMDF provides an event-driven driver model for UMDF drivers. UMDF drivers are stackable in a driver host process. UMDF drivers are loaded on behalf of device nodes enumerated in the PnP device tree. When a request is sent to a device, it travels from the top of the device stack down to the physical device. Each layer of the stack can contribute to the request as the request travels through the stack.

Each driver in a stack provides a standard interface for accepting requests from the driver above. A request travels down the stack in the form of a self-contained, asynchronous request packet. Whenever a request packet arrives at a driver, the packet enters one of the driver's request queues and waits for processing. After each driver finishes processing a request, it can either forward the request to the next driver layer for further processing or complete the request.

A device stack cannot be split across processes. All function and filter drivers for a given device must run in the same driver host process.

Send comments about this topic to Microsoft

Build date: 4/1/2013