A User Unplugs a Device
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.
For more info, see Getting Started with UMDF.
While a system is running, a user can remove a device in one of the following two ways: by orderly removal, which means that the user informs the system that the device is about to be removed (for example, by using the Unplug or Eject Hardware program); or by surprise removal, which means that the user unplugs the device without informing the system. If the bus supports surprise removal (for example, USB), the device's drivers must be able to handle the device's sudden disappearance.
The user requests removal by using the system's Unplug or Eject Hardware program, by disabling the device by using Device Manager, or by pushing an ejectable device's eject button. The framework allows the device to be removed or disabled, unless the driver has supplied an IPnpCallback::OnQueryRemove callback function, and the callback function has vetoed the removal.
The following figure shows the sequence of UMDF callbacks in power-down and removal. The sequence starts at the top of the figure with a device that is in the working power state (D0).
In this scenario, a user unplugs a device unexpectedly. In the surprise-removal sequence, UMDF calls the IPnpCallback::OnSurpriseRemoval callback to notify the driver that the device has been unexpectedly removed. This callback is not guaranteed to occur in any particular order with the other callbacks in the removal sequence.
Generally, the driver should avoid accessing the hardware in the remove path. The reflector times out if an attempt to access the hardware waits indefinitely. The following figure shows the surprise-removal sequence for a UMDF driver.