Creating UMDF HID Minidrivers

[This topic applies to UMDF 1.x.]

Starting in User-Mode Driver Framework (UMDF) version 1.11 and continuing in UMDF version 2.0, you can create UMDF-based drivers for devices that follow the Human Interface Device (HID) specification. These drivers are called HID minidrivers. This topic describes how to create a HID minidriver using UMDF version 1.11.

The system-supplied HID class driver (HidClass.sys) and the framework provide conflicting WDM dispatch routines to handle some I/O requests (such as Plug and Play and power management requests) for minidrivers. As a result, your HID minidriver cannot link to both the class driver and the framework. Therefore, Microsoft provides an additional WDM driver, called MsHidUmdf.sys, that serves as a minidriver paired with HidClass.sys.

The functional device object (FDO) is associated with MsHidUmdf.sys, while HidClass.sys serves as a helper module for MsHidUmdf.sys. The reflector (WudfRd.sys) is in this case a lower filter driver. The following diagram illustrates this relationship.

Location of HidUmdf.sys in the driver stack

Note  The system-supplied MsHidUmdf.sys driver can be replaced by a vendor-supplied HidUmdf.sys driver.

The MsHidUmdf.sys driver is included with Windows 8 and later versions of Windows.

The MsHidUmdf.sys driver calls the HID class driver's HidRegisterMinidriver routine to register as the actual minidriver. Although MsHidUmdf.sys is the device's function driver, it passes I/O requests from the class driver to your driver after updating IRP buffer locations to match those required by UMDF. The UMDF-based HID minidriver that you supply is actually a lower filter driver that resides under MsHidUmdf.sys. The driver's IDriverEntry::OnDeviceAdd callback function must call IWDFDeviceInitialize::SetFilter. The reflector (WudfRd.sys) then brokers communication between MsHidUmdf.sys and your UMDF driver.

Your driver creates I/O queues to receive I/O requests that MsHidUmdf.sys passes from the class driver to your driver. Your driver can register the IQueueCallbackDeviceIoControl interface to be notified when a device I/O control (IOCTL) request is available for the driver. Typically, a driver's IQueueCallbackDeviceIoControl::OnDeviceIoControl method branches to IOCTL-specific method handlers that are defined as methods on the queue. Your driver must handle relevant IOCTLs described in UMDF HID Minidriver IOCTLs.

Starting in Windows 8, the Windows Driver Kit (WDK) provides a sample UMDF-based HID minidriver called WUDFVhidmini that demonstrates how to write a HID minidriver using UMDF.

A driver targeting Windows 8 or later versions of the operating system can use the system-supplied MsHidUmdf.sys driver. If you want to provide a UMDF-based HID minidriver for earlier versions of Windows, you must include HidUmdf.sys and UMDF 1.11 in your driver package. The sample code for HidUmdf.sys is included in the WDK starting in Windows 8. You can build the sample code, rename it, and make it part of your driver package.

A UMDF-based HID minidriver must set the following INF directives in a WDF-specific DDInstall section of its INF file:


This directive must be set to AllowKernelModeClients so that the kernel-mode pass-through driver can be loaded in the stack.

UmdfKernelModeClientPolicy = AllowKernelModeClients


This directive must be set to Copy to allow UMDF to process IOCTLs of METHOD_NEITHER type.



This directive must be set to AllowNullAndUnknownFileObjects to allow UMDF to process requests that are associated with a NULL or unknown file object (a file object for which a driver has not previously seen a create request).



This directive must be set to CanUseFsContext2 to allow the framework to store information in the FsContext2 member of the WDM file object.

UmdfFsContextUsePolicy = CanUseFsContext2



Send comments about this topic to Microsoft

© 2014 Microsoft