How UMDF Handles Driver Failures

This topic describes actions that User-Mode Driver Framework (UMDF) and the operating system take when a UMDF driver fails. It applies to both UMDF versions 1 and 2.

The following events occur in the order presented:

• The operating system notifies the reflector (WUDFRd.sys).

• The reflector tracks outstanding I/O in the host process:

  • The reflector completes outstanding I/O with the STATUS_DRIVER_PROCESS_TERMINATED error code.
  • Microsoft Win32 applications receive the ERROR_DRIVER_PROCESS_TERMINATED error code for the outstanding I/O.

  Note   The reflector that runs on Microsoft Windows XP completes outstanding I/O with STATUS_DRIVER_INTERNAL_ERROR, and Win32 applications, in turn, receive the ERROR_IO_DEVICE error code for the outstanding I/O. Therefore, applications that run on Windows XP should not use ERROR_IO_DEVICE to detect a driver failure because they cannot determine any difference from the status that is returned from a typical I/O request (for example, the status that is returned from a call to the Win32 DeviceIoControl function).

• The reflector sends the GUID_WUDF_DEVICE_HOST_PROBLEM custom Plug and Play (PnP) event to the operating system after the operating system reports a problem with the host process.

  If an application previously called the Win32 RegisterDeviceNotification function to register GUID_WUDF_DEVICE_HOST_PROBLEM for the device, that application will receive a DBT_CUSTOMEVENT notification when the host process fails. For more information about RegisterDeviceNotification and DBT_CUSTOMEVENT, see the Windows SDK documentation.

• The operating system writes an entry to the system event log that indicates that the driver failed. It also indicates how many more times the operating system will restart the driver. The operating system writes the following event numbers into the system event log to indicate the specified problems:

  • 10110 if the host process was at fault
  • 10111 if the device went offline and was restarted
  • 10112 if the device went offline and was not restarted

  The framework can attempt to restart a failing driver. The UMDF code verifier provides a registry value that controls the number of restart attempts. If the user either disables and enables the device in the Device Manager or unplugs and plugs in the device, the operating system creates a new instance of the device and the framework resets the restart counter.

• The operating system unloads the kernel drivers in the device stack.

  Note   The operating system will not tear down and restart the device stack until all handles to the old stack have closed. An application will detect the device failure and a surprise removal notification for the device (DBT_REMOVEDEVICEPENDING). However, if any handle to the old stack is kept open, the device is not restarted.

• The driver manager either restarts or disables the device. If the device is disabled, the operating system displays a yellow exclamation point in Device Manager.

Note that after a UMDF driver fails, the following operations can occur in an arbitrary order:

• The operating system tears down and restarts the device.

• The reflector sends the GUID_WUDF_DEVICE_HOST_PROBLEM PnP event to the operating system.

• The reflector completes outstanding I/O with STATUS_DRIVER_PROCESS_TERMINATED.

Therefore, an application might receive ERROR_DRIVER_PROCESS_TERMINATED for the outstanding I/O after the operating system has restarted the device. After receiving ERROR_DRIVER_PROCESS_TERMINATED, the application might also receive the DBT_CUSTOMEVENT notification that results from the GUID_WUDF_DEVICE_HOST_PROBLEM event.