User-Mode Drivers (Compact 2013)

3/26/2014

User-mode drivers can improve system stability, fault-tolerance, and security. Because a user-mode driver can be isolated from the kernel and other user-mode drivers, it can be reloaded if it fails without restarting the operating system. Unlike kernel-mode drivers, user-mode drivers do not have access to kernel memory or kernel APIs, and there are performance penalties when running in user mode. User-mode drivers have only limited access to user memory buffers, and they cannot directly access device hardware.

To communicate with underlying hardware and perform useful tasks, user-mode drivers must be able to access system memory and privileged APIs unavailable to standard user-mode processes. To facilitate this, user mode drivers rely on two system components:

• The User Mode Driver Reflector, which resides inside Device Manager
• The User Mode Driver Host, which is a user-mode application that is launched and managed by the User Mode Driver Reflector

More than one user-mode device driver can run inside the User Mode Driver Host, and user-mode drivers can be separated from each other by being loaded into different host processes. When a driver is flagged as a user-mode driver in the registry, Device Manager connects it to the User Mode Driver Reflector. The User Mode Driver Reflector launches the appropriate User Mode Driver Host process and forwards I/O requests to it. The User Mode Driver Host process in turn forwards I/O requests to the user-mode driver. This relationship is shown in the following figure.

The User Mode Driver Reflector runs in kernel mode, translates memory addresses of the calling process to the driver’s address space (also known as buffer marshaling), and calls privileged memory management APIs on behalf of user-mode drivers. The Reflector also validates input parameters before it performs a driver’s requested action by checking the registry settings for that device driver to determine whether it can perform the requested action.

Because applications do not differentiate between user-mode and kernel-mode drivers, the User Mode Driver Reflector is responsible for masking the differences between user-mode drivers and kernel-mode drivers from the rest of the system. If a driver does not use kernel APIs that are unavailable in user mode, the driver can run in either kernel mode or user mode through the Reflector. The Reflector is transparent so that the driver can work the same way, either in either kernel mode or user mode, without modifications.

To configure a driver to run as a user-mode driver, you must configure registry settings to specify that the driver can run in a user-mode driver host process, and you specify the name of the process that the driver must run in (such as Udevice.exe). For more information about how to configure the registry to run a device driver in user-mode, see User Mode Driver Framework Registry Settings.

When to Create a User-Mode Driver

The user-mode driver model is a good choice for a new device driver implementation if any one of the following is true:

• You want to protect your system from a possibly compromised device driver.
• You are willing to incur minor performance losses so that the system can recover more gracefully from a driver error.
• Your driver must be able to display to a user interface (UI).
• You are developing your device driver by reusing code from an existing user-mode driver.
• You want to first develop your device driver in user mode (for ease of development) so that you can later adapt it for kernel mode.

For More Information About User-Mode Drivers

To learn more about user-mode drivers, see the Windows Embedded Compact 2013 topics described in the following table.

See Also

Concepts

Kernel-Mode and User-Mode Drivers