What's New for WDF Drivers in Windows 10 Technical Preview
This topic summarizes the new features and improvements for Windows Driver Frameworks (WDF) drivers in Windows 10 Technical Preview.
Windows 10 Technical Preview includes Kernel-Mode Driver Framework (KMDF) version 1.15 and User-Mode Driver Framework (UMDF) version 2.15.
You can use these framework versions to build drivers for:
- Windows 10 Technical Preview for desktop editions (Home, Pro, and Enterprise)
- Windows 10 Technical Preview for phones
- Windows 10 code-named "Athens"
- Windows Server Technical Preview
- The WDF source code is now available as open source on GitHub. This means that you can debug your driver using WDF source code. Download it from http://github.com/Microsoft/Windows-Driver-Frameworks.
- The Windows Driver Kit (WDK) 10 samples are also now published to GitHub. Download them from http://github.com/Microsoft/Windows-Driver-Samples.
- Want to benefit from the universal capabilities of UMDF 2? To learn how to port your old UMDF 1 driver, see Porting a Driver from UMDF 1 to UMDF 2.
In Windows 10 Technical Preview, the frameworks include the following improvements. Except where noted, UMDF references describe version 2 functionality that is not available in UMDF version 1.
- All KMDF and UMDF 2 functionality is universal driver compliant. The requirements section of both KMDF and UMDF API reference pages includes a Target platform entry that tells you if a universal driver can call the DDI in question. UMDF version 1 drivers run only on Windows 10 Technical Preview for desktop editions and earlier versions of desktop Windows.
New always-on, crash resilient Inflight Trace Recorder (IFR). See Inflight Trace Recorder (IFR) for logging traces and Using Inflight Trace Recorder in KMDF and UMDF Drivers.
- If you turn on the IFR in your driver binary, the IFR is present and running during the lifetime of your driver. You don't need to start an explicit trace collection session.
- IFR logs are included in minidump files except when the responsible driver is undetermined or if the crash was a host timeout.
- You can access both the driver and framework IFR logs by issuing !wdfkd.wdflogdump rather than !rcdrkd.rcdrlogdump.
- When debugging a UMDF driver, you can merge framework logs with driver logs by issuing: !wdfkd.wdflogdump <drivername.dll> -m
The enhanced logging functionality is also available in UMDF version 1.
- UMDF supports interrupts for GPIO-backed devices like hardware push-buttons. KMDF supports these devices natively, without the workaround described in Handling Active-Both Interrupts. For more information, see Creating an Interrupt Object.
- For KMDF and UMDF, the new WdfDeviceOpenDevicemapKey method allows a driver to access subkeys and values under HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP.
- A UMDF driver can call WdfIoTargetWdmGetTargetFileHandle to obtain a file handle to the next-lower kernel-mode driver in its stack. The driver can write data to that handle, bypassing the framework's abstractions for sending I/O to the local I/O target.
- A UMDF driver can request that the the underlying bus driver re-enumerate it by calling WdfDeviceSetFailed with FailedAction set to WdfDeviceFailedAttemptRestart. The bus driver must support the GUID_REENUMERATE_SELF_INTERFACE_STANDARD interface.
- Setting the UmdfDirectHardwareAccess directive is no longer always necessary for devices that have connection resources. See Specifying WDF Directives in INF Files.
- New support for USB drivers in UMDF. WinUSB is no longer required. Instead, set the UmdfDispatcher directive to NativeUSB. See Specifying WDF Directives in INF Files.
- UMDF now fully supports HID filters and minidrivers. Simply port your existing KMDF driver or write a new UMDF filter; the functionality is automatically enabled.
- UMDF HID minidrivers enumerated by ACPI can perform selective suspend. In the device's hardware key, add a EnableDefaultIdleNotificationHandler subkey and set it to 1.
- UMDF drivers can now be installed in the HID stack for low latency input devices such as touch and mouse. A driver for an input device should specify the UmdfHostPriority INF directive. For information, see Specifying WDF Directives in INF Files.
- UMDF logs (WudfTrace.etl) and dumps are now located in %ProgramData%\Microsoft\WDF instead of %systemDrive%\LogFiles\Wudf.
- New debugger command: !wdfkd.wdfumtriage provides a kernel-centric view of all UMDF devices on the system.
- You can run !analyze to investigate UMDF verifier failures or UMDF unhandled exceptions. This works for live kernel debugging as well as debugging user crash dump files from %ProgramData%\Microsoft\WDF.
- In KMDF and UMDF, you can monitor power reference usage in the debugger. For info, see Debugging Power Reference Leaks in WDF.
- Using !wdfkd.wdfcrashdump without a parameter causes an automated minidump analysis, displaying:
- New metadata, such as the driver that caused the crash, the error code, the fault type, and more.
- A list of all loaded drivers in the failing host process. Drivers with associated logs are clickable and highlighted.
- UMDF system components consume less disk space.
- KMDF and UMDF drivers use less non-paged memory.
- Improved framework version checking reduces header/library mismatches.
- UMDF provides improved buffer mapping for HID transfers.