Freigeben über

Do I have to handle IRP_MN_SURPRISE_REMOVAL?

  • Artikel

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

  • Anonymous
    February 22, 2006
    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?

  • Anonymous
    February 22, 2006
    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.

  • Anonymous
    February 23, 2006
    The quick answer answer that you must assume your hardware is present and at least probe the hardware...

  • Anonymous
    December 04, 2006
    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!!

  • Anonymous
    December 07, 2006
    The comment has been removed

  • Anonymous
    June 06, 2011
    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