Edit

RemoveLockMnSurpriseRemove rule (wdm)

  • Article

The RemoveLockMnSurpriseRemove rule verifies that calls to IoAcquireRemoveLock and IoReleaseRemoveLockAndWait are used correctly when processing IRP_MJ_PNP with MinorFunction IRP_MN_SUPRISE_REMOVAL. The driver should acquire the remove lock before forwarding the IRP down the stack.

This rule only applies to FDO and FIDO drivers.

For example, consider a PnP driver stack that consists of a filter driver, a FDO, and a PDO.

The PnP manager sends a query remove through the stack. The FDO is enabled to idle while the system is running. The FDO decides to power down in the query removed state, so it requests a d0 IRP. Before the d0 IRP arrives, the PnP manager sends a PnP remove IRP and that IRP is processed by the filter driver. The filter driver detaches from the stack and cleans up its state. The d0 arrives at the top of the stack, but the filter driver does not send it down the stack because it has no context or data to know where to send it anymore. The FDO is hung waiting for the d0 IRP to arrive but that IRP never will.

To avoid this error

  1. Before a device is detached from the device stack, IoAcquireRemoveLock must succeed before the IRP is forwarded down the stack for the following IRP types:

    • IRP_MN_QUERY_REMOVE
    • IRP_MN_SUPRISE_REMOVAL
    • IRP_MN_REMOVE_DEVICE

  2. IoReleaseRemoveLockAndWait should be called before calling IoDetachDevice or IoDeleteDevice. (This makes sure that all remove locks are released in device drivers).

Driver model: WDM

How to test

At compile time

Run Static Driver Verifier and specify the RemoveLockMnSurpriseRemove rule.

Use the following steps to run an analysis of your code:
  1. Prepare your code (use role type declarations).
  2. Run Static Driver Verifier.
  3. View and analyze the results.

For more information, see Using Static Driver Verifier to Find Defects in Drivers.

Applies to

IoAcquireRemoveLock IoCallDriver IoReleaseRemoveLock PoCallDriver RemoveHeadList