Do I have to handle IRP_MN_SURPRISE_REMOVAL?


You might think that just because your device is root enumerated or is plugged into fix slot (llike PCI) and not in a hot plug bus (like USB or PCCARD/PCMCIA) that your driver will not get a IRP_MN_SURPRISE_REMOVAL irp.  This would be a bad assumption to make.


Why?  IRP_MN_SURPRISE_REMOVAL is actually an overloaded message.  Not only is it sent when the underlying bus has detected that the device is now missing, it is also sent in error conditions where the PDO is still reported as present.  For instance, if you call IoInvalidateDeviceState and then set PNP_DEVICE_FAILED in the subsequent IRP_MN_QUERY_PNP_DEVICE_STATE PIRP, your device stack will get a surprise remove, no matter how it is connected to the PC!  You don’t have to modify your driver either, you can use pnpdtest (in the DDK) to cause the surprise removal.  There is no way to differentiate between these two messages , so you must handle this PIRP regardless of how your device is connected

Comments (6)

  1. ringzero says:

    This is a great blog, Doran. Thanks for sharing your knowledge.

    So how does IRP_MN_SURPRISE_REMOVAL handling differ from IRP_MN_REMOVE_DEVICE?

  2. The devil is in the details here and when you move from stack to device stack, what you have to do might change, but the gist of it is pretty simple.  if you look at the following actions that you do in remove device (assuming a graceful remove), you have:

    1)  stop accepting new I/O

    2)  stop touching your hardware and free any hardware resources like memory mapped I/O and disconnect interrupts

    3)  disable WMI & device interfaces

    4)  free memory allocated for the device

    5)  delete the device object

    when processing a surprise remove, you would do steps 1-3 and then when processing a remove after a surprise remove, steps 4-5.

  3. The quick answer answer that you must assume your hardware is present and at least probe the hardware…

  4. Conan says:

    We have an USB composite device with 2 interface, a NDIS NIC and virtual COM port respectively.

    The WDM driver of VCOM and NDIS(5.1)-WDM driver of NIC are developped by DDK, they function well while  leaving alone for single interface device. But when work together for composite device, they cann’t be successfully removed after an surprise removal sometimes.

    I found that PNP dispatch routine of VCOM driver received IRP_MN_SURPRISE_REMOVAL and PNPEVENTNOTIFY routine of NIC received SURPRISE_REMOVAL  after device removed,  and reference count of VCOM is 0, but no subsequent IRP_MN_REMOVE_DEVICE for VCOM and MPHALT for NDIS NIC, Is this a bug of windows or I neglect something??

    any suggestion is helpful and thanks in advance!!

  5. Conan, it could that the FDO has a handle open against it.  you should check the handle count of the FDO as well.  Also, you look at the output of !devnode for the FDO and each PDO to see if the states indicate what the OS is waiting for.  Finally, run !locks and see if the pnp lock is being held (run !thread on each thread reported holding a lock and it should be clear in the callstack who is holding the pnp lock)

    d

  6. Jiang Jun says:

    Doron, Thanks a lot for sharing your information.

    I met a BSOD when to run Pnp test of DTM. I google IRP_MN_SURPRISE_REMOVAL and got your explanation. It is great.

    Audleyswood