User-Mode Driver Framework

Last updated
User-Mode Driver Framework (UMDF)
Developer(s) Microsoft
Initial releaseOctober 12, 2004;18 years ago (2004-10-12)
Stable release
2.27 / March 24, 2019;3 years ago (2019-03-24)
Repository github.com/microsoft/Windows-Driver-Frameworks
Written in C, C++
Operating system Microsoft Windows
Type Device-driver development platform
License MIT License
Website docs.microsoft.com/en-us/windows-hardware/drivers/wdf/overview-of-the-umdf

User-Mode Driver Framework (UMDF) is a device-driver development platform first introduced with Microsoft's Windows Vista operating system, and is also available for Windows XP. It facilitates the creation of drivers for certain classes of devices. [1]

Contents

Overview

Standard device drivers can be difficult to write because they must handle a very wide range of system and device states, particularly in a multithreaded software environment. Badly written device drivers can cause severe damage to a system (e.g., BSoD or data corruption) since all standard drivers have high privileges when accessing the kernel directly. The User-Mode Driver Framework insulates the kernel from the problems of direct driver access, instead providing a new class of driver with a dedicated application programming interface at the user level of interrupts and memory management. If an error occurs, the new framework allows for an immediate driver restart without impacting the system. This is particularly useful for devices that are intermittently connected to the system or support hot swapping via a bus technology such as USB or FireWire.

According to Microsoft, UMDF drivers are simpler to write and debug than kernel-mode drivers. [2] However, UMDF would not be used for performance-intensive or highly stateful devices.

The first version of the UMDF was shipped as part of Windows Media Player version 10 on 2004-10-12. Code-named "Crescent", it was designed to support the Media Transfer Protocol driver, and no public interfaces or documentation were provided for it. Later, Microsoft decided to turn UMDF into a device driver development platform. [3]

Version history

Architecture

A UMDF Driver is a DLL based on Microsoft's Component Object Model (COM). However, UMDF does not use COM for loading, unloading, or controlling concurrency; it only uses COM as a programming pattern, for example exploiting COM's IUnknown interface. At startup, 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 callback object.

The driver object is an instance of the framework-provided IWDFDriver interface. The driver provides a set of callbacks via the IDriverEntry COM interface, which is the main entry point for driver customization.

See also

Related Research Articles

The Windows API, informally WinAPI, is Microsoft's core set of application programming interfaces (APIs) available in the Microsoft Windows operating systems. The name Windows API collectively refers to several different platform implementations that are often referred to by their own names ; see the versions section. Almost all Windows programs interact with the Windows API. On the Windows NT line of operating systems, a small number use the Native API.

<span class="mw-page-title-main">Graphics Device Interface</span> Microsoft Windows API

The Graphics Device Interface (GDI) is a legacy component of Microsoft Windows responsible for representing graphical objects and transmitting them to output devices such as monitors and printers. Windows apps use Windows API to interact with GDI, for such tasks as drawing lines and curves, rendering fonts, and handling palettes. The Windows USER subsystem uses GDI to render such UI elements as window frames and menus. Other systems have components that are similar to GDI; for example: macOS has Quartz, and Linux has X Window System and Wayland.

In computing, the Windows Driver Model (WDM) – also known at one point as the Win32 Driver Model – is a framework for device drivers that was introduced with Windows 98 and Windows 2000 to replace VxD, which was used on older versions of Windows such as Windows 95 and Windows 3.1, as well as the Windows NT Driver Model.

NTLDR is the boot loader for all releases of Windows NT operating system from 1993 with the release of Windows NT 3.1 up until Windows XP and Windows Server 2003. From Windows Vista onwards it was replaced by the BOOTMGR bootloader. NTLDR is typically run from the primary storage device, but it can also run from portable storage devices such as a CD-ROM, USB flash drive, or floppy disk. NTLDR can also load a non NT-based operating system given the appropriate boot sector in a file.

Windows Management Instrumentation (WMI) consists of a set of extensions to the Windows Driver Model that provides an operating system interface through which instrumented components provide information and notification. WMI is Microsoft's implementation of the Web-Based Enterprise Management (WBEM) and Common Information Model (CIM) standards from the Distributed Management Task Force (DMTF).

<span class="mw-page-title-main">Windows Registry</span> Database for Microsoft Windows

The Windows Registry is a hierarchical database that stores low-level settings for the Microsoft Windows operating system and for applications that opt to use the registry. The kernel, device drivers, services, Security Accounts Manager, and user interfaces can all use the registry. The registry also allows access to counters for profiling system performance.

<span class="mw-page-title-main">Architecture of Windows NT</span> Overview of the architecture of the Microsoft Windows NT line of operating systems

The architecture of Windows NT, a line of operating systems produced and sold by Microsoft, is a layered design that consists of two main components, user mode and kernel mode. It is a preemptive, reentrant multitasking operating system, which has been designed to work with uniprocessor and symmetrical multiprocessor (SMP)-based computers. To process input/output (I/O) requests, they use packet-driven I/O, which utilizes I/O request packets (IRPs) and asynchronous I/O. Starting with Windows XP, Microsoft began making 64-bit versions of Windows available; before this, there were only 32-bit versions of these operating systems.

As the next version of Windows NT after Windows 2000, as well as the successor to Windows Me, Windows XP introduced many new features but it also removed some others.

The Kernel-Mode Driver Framework (KMDF) is a driver framework developed by Microsoft as a tool to aid driver developers create and maintain kernel mode device drivers for Windows 2000 and later releases. It is one of the frameworks included in the Windows Driver Frameworks. The current version is 1.27.

Windows Driver Frameworks, is a set of Microsoft tools and libraries that aid in the creation of device drivers for Windows 2000 and later versions of Windows. It complements Windows Driver Model, abstracting away much of the boilerplate complexity in writing Windows drivers.

The booting process of Windows NT includes Windows NT 4.0, Windows 2000, Windows XP and Windows Server 2003. In Windows Vista and later, this process has changed significantly; see Windows NT 6 startup process for information about what has changed.

The Speech Application Programming Interface or SAPI is an API developed by Microsoft to allow the use of speech recognition and speech synthesis within Windows applications. To date, a number of versions of the API have been released, which have shipped either as part of a Speech SDK or as part of the Windows OS itself. Applications that use SAPI include Microsoft Office, Microsoft Agent and Microsoft Speech Server.

<span class="mw-page-title-main">Universal Audio Architecture</span>

Universal Audio Architecture (UAA) is an initiative unveiled in 2002 by Microsoft to standardize the hardware and class driver architecture for audio devices in modern Microsoft Windows operating systems. Three classes of audio devices are supported by default: USB, IEEE 1394 (FireWire), and Intel High Definition Audio, which supports PCI and PCI Express.

The Microsoft Windows operating system supports a form of shared libraries known as "dynamic-link libraries", which are code libraries that can be used by multiple processes while only one copy is loaded into memory. This article provides an overview of the core libraries that are included with every modern Windows installation, on top of which most Windows applications are built.

This article describes audio APIs and components in Microsoft Windows which are now obsolete or deprecated.

Client Server Runtime Subsystem, or csrss.exe, is a component of the Windows NT family of operating systems that provides the user mode side of the Win32 subsystem and is included in Windows NT 3.1 and later. Because most of the Win32 subsystem operations have been moved to kernel mode drivers in Windows NT 4 and later, CSRSS is mainly responsible for Win32 console handling and GUI shutdown. It is critical to system operation; therefore, terminating this process will result in system failure. Under normal circumstances, CSRSS cannot be terminated with the taskkill command or with Windows Task Manager, although it is possible in Windows Vista if the Task Manager is run in Administrator mode. On Windows 7 and later, Task Manager will inform the user that terminating the process may result in system failure, and prompt if they want to continue. In Windows NT 4.0 however, terminating CSRSS without the Session Manager Subsystem (SMSS) watching will not crash the system. However in Windows XP, terminating CSRSS without SMSS watching will crash the system due to the critical bit being set in RAM for csrss.exe.

The booting process of Microsoft Windows varies between different releases.

Windows Vista has many significant new features compared with previous Microsoft Windows versions, covering most aspects of the operating system.

<span class="mw-page-title-main">Blue screen of death</span> Error screen displayed after a fatal system error on a computer running Microsoft Windows or ReactOS

The Blue Screen of Death (BSoD), officially known as a Stop error or Blue Screen error, is an error screen that the Windows operating system displays in the event of a fatal system error. It indicates a system crash, in which the operating system has reached a critical condition where it can no longer operate safely, e.g., hardware failure or an unexpected termination of a crucial process.

In computing on Microsoft platforms, WoW64 is a subsystem of the Windows operating system capable of running 32-bit applications on 64-bit Windows. It is included in all 64-bit versions of Windows—including Windows XP Professional x64 Edition, IA-64 and x64 versions of Windows Server 2003, as well as x64 versions of Windows Vista, Windows Server 2008, Windows 7, Windows 8, Windows Server 2012, Windows 8.1, Windows 10, Windows Server 2016, Windows Server 2019, and Windows 11, as well as ARM64 versions of Windows 10, Windows 11 and Windows Server 2022, except in Windows Server Server Core where it is an optional component, and Windows Nano Server where it is not included. WoW64 aims to take care of many of the differences between 32-bit Windows and 64-bit Windows, particularly involving structural changes to Windows itself.

References

  1. Programming Drivers for the UMDF
  2. "Advantages of Writing UMDF Drivers".
  3. Charles Torre, Peter Wieland (2006-09-18). "Peter Wieland: User Mode Driver Framework". Channel 9. Microsoft. Retrieved 2006-09-18.
  4. Microsoft Support. "User-Mode Driver Framework version 1.11 update for Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2". Microsoft. Retrieved 2012-12-01.
  5. "User-Mode Driver Framework Frequently Asked Questions (Windows Drivers)". Microsoft. Retrieved 2014-06-04.