Removing a non-removable device

A surprise indeed

From time to time, miniport authors ask us whether they really have to support surprise removal.  After all, they explain, their device is embedded in the system — it’s not physically possible to remove it without a soldering iron and/or crowbar.

Here's our answer: yes, you should support surprise removal.  You should support it even if your hardware can’t be physically removed from the system.  (After all, that only makes the removal more surprising!)

The reason you should support surprise removal is because Windows uses surprise removal to handle other situations besides physically detaching a device from the system.  Surprise removal is invoked whenever a device is unexpectedly no longer enumerated on the bus.  This can happen if your hardware fails.  But even if you are confident that your hardware is always perfect, surprise removal can also occur if the bus itself fails.

This isn’t just an NDIS convention.  The rules in WDM are the same.

Ok, now that I’ve convinced you that you should handle surprise removal, the next question is how do you handle surprise removal?  Implement NdisDevicePnPEventSurpriseRemoved in your MiniportDevicePnPEventNotify handler.  Set a flag to reject new I/O, and cancel any pending I/O.  And of course, refer to the MSDN topic.

Since you've made it this far, I've got a bonus trick for you: you can initiate surprise removal yourself.  As always, if your MiniportCheckForHang[Ex] handler detects that the hardware has hiccupped, return TRUE to give your MiniportReset[Ex] handler an opportunity to recover the hardware.  But for the really bad problems that you know your reset handler wouldn't fix anyway, you can trigger immediate surprise removal by invoking NdisMRemoveMiniport.  Even though the network will go down, you may be able to salvage the system from, say, a storm of interrupts.  In either case, make sure to log an error in the event log, so the unlucky user can figure out why the network just went down.