Edit

Framework Object Hierarchy

  • Article

Warning

UMDF 2 is the latest version of UMDF and supersedes UMDF 1. All new UMDF drivers should be written using UMDF 2. No new features are being added to UMDF 1 and there is limited support for UMDF 1 on newer versions of Windows 10. Universal Windows drivers must use UMDF 2.

The archived UMDF 1 samples can be found in the Windows 11, version 22H2 - May 2022 Driver Samples Update.

For more info, see Getting Started with UMDF.

The following figure shows the parent-child framework object hierarchy.

umdf parent-child object hierarchy.

The lifetime scope of framework objects is determined by their location in the hierarchy and how the objects are created. The lifetime scope of framework objects falls into one of the following categories:

  • The framework controls the creation and destruction of the objects.

    The framework creates and destroys objects, such as the driver object and device object, in response to system events. When a user-mode driver calls the IWDFDriver::CreateDevice method to create the device object, the driver can optionally register to be notified by the framework before the device object is destroyed.

  • The framework creates the object; however, the driver controls when the object is released.

    The I/O request object follows this pattern when I/O is presented to the driver. The framework creates the request object, and the request object's lifetime is valid until the driver calls the IWDFIoRequest::Complete method.

  • The driver creates the object and associates the object with another framework object.

    Some framework objects are created by a method that is exposed by a parent framework object instance that the objects are to be associated to for lifetime-management purposes. The IWDFDevice::CreateIoQueue method is an example of this pattern. If a call to IWDFDevice::CreateIoQueue succeeds, the newly created I/O queue is associated with the device instance that the IWDFDevice interface represents. When the parent object is destroyed, the framework automatically cleans up child instances. Drivers are notified of these events if the drivers register appropriate callback functions with the framework.