Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
Windows 7

Windows 7 User Mode Drivers Overview and Operation : Devices Supported in User Mode & UMDF Model Overview

- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire
5/4/2012 4:13:56 PM

1. Devices Supported in User Mode

UMDF supports the development of drivers for protocol-based or serial bus-based devices, such as Universal Serial Bus (USB) devices and network-connected devices. For example, drivers for the following types of devices can be written in user mode:

  • Portable storage devices

  • Portable media players

  • USB bulk transfer devices

  • Auxiliary display devices

The device can be directly connected, connected on the network, or connected via a wireless protocol such as Bluetooth. UMDF also supports software-only drivers.

The initial UMDF release includes the following sample UMDF drivers:

  • Skeleton— A minimal driver that is intended for use as a template for driver development.

  • Echo— A simple-software-only driver that shows the use of a serial I/O queue.

  • USB/FX2_Driver and USB/Echo Driver— Function drivers for the USB-FX2 board that was designed by Open Systems Resources, Inc. (OSR). This is the board we will be using for our driver example developments for UMDF.

  • USB/Filter— A filter driver for the USB-FX2 device stack.

User Mode Drivers can support 32-bit or 64-bit devices for any Windows hardware platform and can be distributed on Windows Update. UMDF is currently supported for Windows 7, Windows Vista, and Windows XP.

Drivers that require the following cannot be written as UMDF drivers; they must be written as Kernel Mode Drivers:

  • Handling interrupts

  • Direct access to the hardware, such as direct memory access (DMA)

  • Strict timing loops

  • Use of nonpaged pool or other resources that are reserved for kernel mode.

In addition, a UMDF driver cannot be a client of the Windows kernel or of a Kernel Mode Driver.

2. UMDF Model Overview

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 3.1 shows the overall architecture of the UMDF driver model.

Figure 1. UMDF Driver Architecture

Figure 3.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 installation, 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 driver 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 messages from the reflector and the driver manager.

The host process is a child process of 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.

2.1. UMDF Object Model

UMDF drivers are object oriented and event driven. The driver and the framework create instances of objects that are required to support the driver’s device. The driver implements event callback interfaces to handle events that affect these objects.

The objects and interfaces are based on the COM programming pattern. UMDF uses only a small subset of COM, specifically the COM lifetime model; it does not depend on the entire COM infrastructure and run-time library. The UMDF run-time environment loads the driver by reading information that is stored in the registry under the WDF service key.

UMDF uses only the query-interface and reference-counting features of COM. Every UMDF interface derives from IUnknow and therefore supports the QueryInterface, AddRef, and Release methods by default. The AddRef and Release methods manage object lifetime. The QueryInterface method enables other components to determine which interfaces the driver supports.

2.2. UMDF Objects

UMDF manages a series of objects that are exposed to the User Mode Driver. UMDF creates some of these objects in response to application-triggered actions, such as an I/O request; the driver creates other objects by calling methods on UMDF interfaces.

For each type of object, UMDF defines one or more interfaces through which to manipulate instances of the object. The interfaces provide methods and properties. Methods define actions that can be taken on behalf of the object and return a status to indicate whether they succeeded or failed. Property operations set and get the attributes of the object and cannot fail. Some interfaces are implemented by UMDF, and others are implemented by the driver.

Table 1 lists all the UMDF object types and the interfaces that UMDF implements on each type.

Table 1. UMDF Object Types
Type of ObjectInterfacesDescription
Base objectIWDFObjectExposes a base object for use as the driver requires.
DeviceIWDFDeviceExposes an instance of a device object. A driver typically has one device object for each device that it controls.
DriverIWDFDriverExposes the driver object itself. Every driver has one driver object.
FileIWDFFileExposes a framework file object that was opened by the Win32 CreateFile function, through which applications can access the device.
 IWDFDriverCreatedFileExposes a framework file object that the driver created.
I/O queueIWDFloQueueExposes an I/O queue, which controls the flow of I/O in the driver. A driver can have any number of I/O queues.
I/O requestIWDFloRequestExposes a request for device I/O.
I/O targetIWDFloTargetRepresents the next-lower driver in the device stack, to which the driver sends I/O requests.
MemoryIWDFMemoryExposes memory that the driver uses, typically an input or output buffer that is associated with an I/O request.
USB deviceIWDFUsbTargetDeviceExposes a USB device object that is an I/O target. Inherits from IWdfloTarget.
USB interfaceIWDFUsbInterfaceExposes an interface on a USB device.
USB pipeIWDFUsbTargetPipeExposes a USB pipe that is an I/O target. Inherits from IWdfloTarget.

The driver calls methods on these interfaces to perform operations on its objects. For example, UMDF implements the IWDFloRequest interface, and the driver calls methods in this interface to retrieve the parameters for the I/O request.

For the driver, devices, and queues, both the framework and the driver maintain objects. The driver-created objects are callback objects, on which the driver implements the callback interfaces that are required to service its device. A driver has one callback object, one device callback object for each device that it supports, and one queue callback object for each queue that it creates. The callback objects serve as the “context memory” for the driver.

Other -----------------
- Microsoft Project 2010 : Setting Up a Project Budget - Reviewing Cost Information
- Microsoft Project 2010 : Setting Up a Project Budget - Preparing for Cost Calculations
- Microsoft Outlook 2010 : Processing Messages Automatically - Creating and Using Quick Steps
- Microsoft Outlook 2010 : Processing Messages Automatically - Using Rules to Move Messages Between Accounts & Running Rules Manually and in Specific Folders
- Virtualization : Windows XP Mode
- Virtualization : Creating VHDs from Within Windows 7 & Mounting VHDs
- Microsoft Visio 2010 : Importing rule sets from XML
- Microsoft Visio 2010 : Exporting rule sets to XML
- Microsoft Access 2010 : Editing a Query in Design View
- Microsoft Access 2010 : Copying to and from Other Office Programs
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
programming4us programming4us
Popular tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 windows Phone 7 windows Phone 8
programming4us programming4us
Natural Miscarriage
Windows Vista
Windows 7
Windows Azure
Windows Server
Game Trailer