User Mode Driver Framework for Windows 7 Drivers
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The User Mode Driver Framework (UMDF) is one of two major sub-frameworks in the Windows Driver Foundation (WDF) Framework. It in essence sits on top of the Windows 7 Operating System, and uses the Windows Win32 API’s primarily to communicate with the Operating System, which ultimately communicates with the computer system hardware device.
If your device utilization allows, one should always look at using the UMDF to create the Device Driver. One of many reasons this approach is best is the ease at which one can create a new device driver with minimum risk of taking down the computer operating system when using the device. This is because the UMDF driver only has access to the application process in which it is running. At most, a driver fault can only take down that process, and is therefore very unlikely to affect the overall operation of the system. Also, there is the advantage of only using only one computer for development and debug of the driver. Another great advantage is the fact that one can use C++ and the object-oriented approach for creation of the driver. The UMDF also is based upon the COM Object Model, and allows the use of this well-proven approach to object model programming. It only uses a subset of COM which we call COM-Lite, thereby reducing the complexity of using the overall COM Run Time Library.
UMDF Architecture
Figure 1 shows the overall architecture of a UMDF driver. A UMDF driver runs in a driver host process that also hosts UMDF and a run-time environment. Each such driver operates as part of a stack of drivers that manage a device. The User Mode Drivers are loaded above the Kernel Mode Drivers at the top of the stack. Because user mode components do not have access to the system address space where the system and Kernel Mode Drivers maintain I/O requests and other shared data, the UMDF architecture includes components that communicate between kernel mode and user mode.
)
Figure 1 UMDF driver architecture
Figure 1 shows two device stacks that service two different devices. Each device stack includes a UMDF driver that runs in its own driver host process. The figure includes the following components, described according to the typical flow of an I/O request.
Applications
The applications are clients of the drivers. These applications are user mode processes that issue I/O requests through the Win32 File I/O API. The Win32 functions call I/O routines in the Windows kernel.
Windows kernel
The Windows kernel creates I/O request packets (IRPs) to represent the user mode I/O requests and forwards them to the top of the Kernel Mode Driver stack for the target device.
Reflector
The reflector is a Kernel Mode WDM Filter Driver that is installed at the top of the kernel mode device stack for each device that a UMDF driver manages. The reflector manages communication between the kernel mode components and the User Mode Driver host process. The reflector forwards I/O, power, and Plug and Play messages from the operating system to the driver host process, so that User Mode Drivers can respond to I/O requests and participate in Plug and Play device installations, enumeration, and management.
The reflector also monitors the driver host process to ensure that it responds properly to messages and completes critical operations in a timely manner, thus helping to prevent driver and application hangs. Microsoft provides the reflector.
Driver Manager
The driver manager creates and shuts down the host processes and maintains status information about them. It also responds to messages from the reflector. The driver manager runs as a Windows service and is started during installation of the first device that has a UMDF driver. One instance of the driver manager handles all of the driver host processes. The driver manager must be running all of the time that any device controlled by a UMDF driver is installed on the system. Microsoft provides the driver manager.
Host Process
The host process is the process in which the User Mode Driver runs. It is separate from the application process and the driver manager. It runs in the security credentials of a LocalService account, although it is not a Windows service. The host process contains the user mode device stack for the device. The device stack is visible to all applications across the system. Each instance of a device has its own device stack. Currently each instance has a separate driver host process, too. The host process includes the following components:
- The UMDF driver is an in-process component object model (COM) component that controls the hardware from user mode.
- The framework exposes the user mode DDI, which is a dynamic-link library (DLL) of COM-style objects that support the presentation, flow, and management of I/O, power, and Plug and Play requests to the driver.
- The run-time environment dispatches I/O requests, loads the driver, constructs and destroys the user mode device stack, manages a user mode thread pool, and handles message from the reflector and the driver manager.
Kernel Mode-Drivers
Additional Kernel Mode Drivers can service each device. These device drivers are supplied either by Microsoft or by the device writer.