Windows 7 : Programming Drivers for the User Mode Driver Framework - Windows I/O Overview, Brief COM Information, UMDF Architecture

9/26/2012 1:45:20 AM

1. Windows I/O Overview

Before writing a driver—even a User Mode Driver—you must understand the basics of the Windows I/O architecture, as shown in Figure 1. In this overview, we will discuss some of the major principles behind the I/O system and define the most important terms. 

Figure 1. Block Diagram Windows I/O

As Figure 4.1 shows, Windows supports a layered I/O architecture. User mode applications and services issue I/O requests through the Win32 API and communicate with the user mode PnP manager to perform Plug and Play and power activities. The Win32 API and user mode PnP manager, in turn, communicate with the kernel mode I/O system, which includes the kernel mode I/O manager, PnP manager, and power manager. The kernel mode I/O system communicates with the Kernel Mode Drivers.

Drivers are also layered. Most devices are driven by not one but by several drivers, each layered atop the next. Together, the group of drivers that operates a particular device is called the device stack (sometimes also called the driver stack). At the bottom of the device stack is a bus driver, which controls a bus and enumerates the devices that are connected to the bus. Layered above the bus driver are filter drivers and a function driver. The function driver is the primary driver for the device and exposes the device interface to the I/O manager. Filter drivers can be layered above or below the function driver and provide additional features, such as encryption or security, or change the behavior of a device. Each driver in the device stack is represented by a device object. The device object is a data structure that contains information about the driver and the device.

Drivers receive I/O, Plug and Play, and power management requests in the form of I/O request packets (IRPs). When the Windows I/O manager receives an I/O request, it determines which device stack corresponds to the virtual file that is specified in the request. It then packages the request into an IRP and forwards it to the target device object. Plug and Play and power management notifications are also packaged as IRPs, and drivers communicate with other drivers by sending IRPs.

When a driver receives an IRP, it takes whatever actions are required to satisfy the request and then completes it. Sometimes, however, a driver cannot satisfy an IRP by itself. If the driver cannot complete the IRP, it typically passes the IRP down the device stack to the next driver and optionally sets an I/O completion routine for callback when the request is complete. Eventually, the IRP arrives at a driver that satisfies and completes the request. When the request is complete, the I/O manager calls any completion callback routines that drivers set as the request traveled down the device stack. It calls these routines in the opposite order in which they were set—that is, it “unwinds” back up the device stack.

2. Brief COM Information

The UMDF interfaces are defined in terms of COM. UMDF does not depend on the COM infrastructure and run-time library. Instead, it uses only the COM programming pattern, specifically the query-interface and reference-counting features. It does not use the COM run-time loader.

The following is a brief overview on COM:

  • COM is based on a client-server model.

  • COM maintains reference counts for all of its objects.

  • COM objects expose interfaces, which support callable methods.

  • COM interfaces are C++ abstract base classes. An interface contains one or more methods that form the contract for any caller that wants to use the class.

  • The query-interface (QI) feature of COM enables a client to query a server to determine whether the server supports a particular interface. UMDF drivers can request notification of particular system events by exposing callback interfaces. UMDF uses the QI feature to discover these callback interfaces.

  • IUnknown is the fundamental COM interface, and every COM object supports it. IUnknown supports the QueryInterface, AddRef, and Release methods. The QueryInterface method enables other components to determine which interfaces the object supports. The AddRef and Release methods manage object lifetime.

  • The IClassFactory interface creates instances of class objects. UMDF calls DllGetClassObject to get a pointer to an IClassFactory interface in the driver and then uses the CreateInstance method of the IClassFactory interface to create an instance of the driver object.

  • When COM returns an interface pointer to a driver, it takes out a reference on the corresponding object. The driver should release this reference by calling the object’s Release method when it has finished using the object. Failing to release references causes object leaks, which consume memory unnecessarily.

3. UMDF Architecture

A UMDF driver is a dynamic-link library (DLL) that runs as an in-process COM server. Figure 2 shows the components that are involved when a UMDF driver controls a device.

Figure 2. User Mode Driver Architecture

As Figure 2 shows, the User Mode Driver runs under the Host Process, which combines with Kernel Mode Drivers (including the reflector) to form the device stack for the device.

The following describes the preceding components in the figure according to the typical flow of an I/O request.

Application. The application issues I/O requests through the Win32 API, which in turn calls I/O routines in the Windows kernel.

Windows kernel. The Windows kernel creates IRPs to represent the requests and forwards them to the top of the kernel mode device 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 is managed by a UMDF driver. The reflector manages communication between the kernel mode components and the User Mode Driver host process.

Driver manager. The driver manager creates and shuts down all 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 is managed by a UMDF driver. The driver manager must be running all 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. The host process is a child process of the driver manager and runs in the security credentials of a LocalService account, although it is not a Windows service. The host process includes the following components:

  • The UMDF driver is an in-process COM component that controls the hardware from user mode.

  • UMDF exposes the User Mode device-driver interface (DDI). UMDF is a DLL of COM-style objects that support the presentation, flow, and management of I/O 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 managers.

Kernel Mode Drivers. Additional Kernel Mode Drivers can service each device.

Most View
Sharepoint 2013 : Add a Document Library to Microsoft Office, Delete a File or List Item
Cancel Your Phone Line (Part 1)
Silverlight : Data Binding - Controlling Updates
Letter Of The Month – November 2012 (Part 2)
Top 10 Hi-Fi Music Streaming
The Return Of RAID
Windows Vista : Programming the WshShell Object (part 1) - Displaying Information to the User
Rise Of The Thingthernet (Part 1)
Seasonic And Enhance Junior PSUs - Compact Power Supply (Part 1)
Motorola Droid Razr M - Big Performance From A Small Smartphone
Top 10
Sharepoint 2013 : Farm Management - Disable a Timer Job,Start a Timer Job, Set the Schedule for a Timer Job
Sharepoint 2013 : Farm Management - Display Available Timer Jobs on the Farm, Get a Specific Timer Job, Enable a Timer Job
Sharepoint 2013 : Farm Management - Review Workflow Configuration Settings,Modify Workflow Configuration Settings
Sharepoint 2013 : Farm Management - Review SharePoint Designer Settings, Configure SharePoint Designer Settings
Sharepoint 2013 : Farm Management - Remove a Managed Path, Merge Log Files, End the Current Log File
SQL Server 2012 : Policy Based Management - Evaluating Policies
SQL Server 2012 : Defining Policies (part 3) - Creating Policies
SQL Server 2012 : Defining Policies (part 2) - Conditions
SQL Server 2012 : Defining Policies (part 1) - Management Facets
Microsoft Exchange Server 2010 : Configuring Anti-Spam and Message Filtering Options (part 4) - Preventing Internal Servers from Being Filtered