User-Mode Driver Framework Frequently Asked Questions

Published: October 08, 2005 | Updated: November 05, 2007

The Windows Driver Foundation (WDF) is the new Microsoft platform for writing Microsoft Windows drivers. WDF defines a single driver model that is supported by two frameworks: a user-mode driver framework (UMDF) and a kernel-mode driver framework (KMDF). WDF also includes driver verification and testing tools, such as Static Driver Verifier (SDV) and PREfast.

This paper provides answers to frequently asked questions about UMDF from Windows driver developers.

This information applies for the following operating systems:
Windows Vista
Windows XP

Which operating systems support UMDF?
UMDF drivers can run on Microsoft Windows Vista and Windows XP.

Which device classes and driver models does UMDF support?
UMDF supports devices such as the following:

Digital cameras
Portable media players
Cell phones
Personal digital assistants (PDAs)
Other devices, such as USB, that connect to a protocol bus

You can implement a UMDF driver for any device that can comply with the constraints listed in "What are the constraints on user-mode drivers?" You can also implement software-only drivers with UMDF.

Why is UMDF based on COM?
Microsoft chose the component object model (COM) as the basis for UMDF objects and interfaces for several reasons:

Many user-mode programmers are already familiar with COM.
C++ is the preferred language for writing user-mode drivers and COM applications.
Numerous tools, including Microsoft Visual Studio and Active Template Library (ATL), support COM-based applications and objects, thus helping driver writers to quickly generate code.
COM interfaces enable functions to be grouped logically, so that the device driver interface (DDI) is easy to understand and navigate.
Using COM enables the DDI to evolve without requiring existing driver dynamic-link libraries (DLLs) to be recompiled.

UMDF uses only the query-interface and reference-counting features of COM; it does not depend on the entire COM infrastructure and run-time library.

What are the constraints on user-mode drivers?
A user-mode driver cannot directly access hardware or use kernel-mode resources. For example, it cannot perform direct memory access (DMA), handle interrupts, or allocate memory from nonpaged pool. However, you might be able to split your driver so that part of it runs in kernel mode and part of it runs in user mode.

A user-mode driver cannot have kernel-mode clients because Windows does not allow calls from kernel mode to user mode. The majority of drivers for input, display, and most network and storage devices cannot be migrated to user mode because they have kernel-mode clients. For the same reason, user-mode drivers must be at the top of the device stack; they cannot attach to the middle of the stack. However, a stack can contain more than one user-mode driver; that is, a user-mode driver can have user-mode children.

Can I write part of my driver to run in user mode and part in kernel mode?
Yes. Even if your driver requires access to some kernel-mode resources or features, you might be able to split your driver into two parts. This approach enables you to benefit from some of the advantages of developing and running drivers in user mode.

Is there any advantage to rewriting an existing kernel-mode driver to run in user mode?
If a user-mode driver is suitable for your device, you should seriously consider writing one. User-mode drivers have these important advantages over kernel-mode drivers:

Increased stability. User-mode drivers can crash or hang only their own process, not the entire system.
Ease of development. User-mode drivers can be written in C++ and debugged by using user-mode debuggers, without requiring a separate debugging system.
Increased security. User-mode drivers do not have access to the kernel-mode address space and therefore cannot expose kernel-mode data, such as system information or data belonging to other processes.

Microsoft's experience with printer drivers provides a useful example. Although the printer driver architecture was developed long before UMDF, moving printer drivers from kernel mode to user mode resulted in significant improvements in stability and reliability. Before printer drivers moved to user mode (with the release of Windows 2000), they were the primary cause of Driver Development Kit (DDK) support calls and one of the top five reasons for calls to Microsoft Customer Service and Support (PSS). Since moving to user mode, printer drivers generate very few calls.

Furthermore, the number of online crash analysis (OCA) reports involving printer drivers is tiny in comparison to the size of the installed product base. Windows Error Reporting (WER) data, which tracks user-mode issues, typically averages about two issues related to printer drivers in the top 250 items that they track.

How do user-mode drivers handle security?
UMDF drivers run in a driver host process, which runs in the security credentials of a LocalService account, although the host process itself is not a Windows service. Thus, user-mode drivers are as secure as any other user-mode service.

When a UMDF driver issues I/O requests, it can optionally impersonate its client process. Impersonation enables the driver thread to run in the security context of the client so that the system performs access checks against the client's identity rather than that of the driver host process.

A user-mode driver can impersonate its client process only for I/O requests, and not for Plug and Play or other system messages.

At driver installation, the INF file sets a maximum impersonation level for the driver. Impersonation should be set at the lowest level possible to prevent "elevation-of-privilege" attacks. When a client application calls the CreateFile function, it specifies an impersonation level. The driver then requests this level of impersonation for each individual I/O request.

Will a user-mode driver be fast enough?
Performance is a high priority in developing UMDF. Although latency and CPU usage both increase somewhat, bus capacity is the primary gating factor for the types of devices that UMDF supports.

What is the difference between a user-mode driver and an application?

A user-mode driver is started by the Driver Manager and runs in a driver host process. A single instance of the driver can service simultaneous requests from multiple applications. To communicate with the driver, applications issue I/O requests to the driver's device through the Win32 API. The primary entry point in a user-mode driver is the IDriverEntry interface, rather than a main() function.

A driver also includes additional interfaces that are invoked in response to I/O requests and Plug and Play and power notifications. A device that is managed by a UMDF driver is integrated into the system and participates in Plug and Play and power management.

How do I debug a UMDF driver?
You can debug a UMDF driver by using user-mode debuggers or kernel-mode debuggers. Both have benefits and drawbacks.

See " Debugging UMDF Drivers" in the WDK documentation.

Where can I find more information?
You can find more information about the UMDF in the following places:

Windows Driver Foundation on the WHDC Web Site
http://msdn.microsoft.com/en-us/windows/hardware/gg463268.aspx

Newsgroups
Microsoft moderates a newsgroup for the UMDF beta. You must be enrolled in the beta program to participate in this newsgroup:
microsoft.beta.windows.driverfoundation.umdf

Top of page