Surprise Eject with an Open File Handle

Is it possible to fully eject a device with an open file handle? I am assuming that the driver should never explicitly delete a WdfFileObject.

I have a driver which ejects (via EVT_WDF_DEVICE_SURPRISE_REMOVAL) and unloads correctly when not in use by a user process. i.e. there is no user WdfFileObject associated with the device. However, even after purging the queues and cancelling all outstanding I/O, the device cleanup is not called until the user program closes the open file handle to the device.

Am I missing something obvious?

Many thanks

Chris Read

An open handle will keep a surprise removed device (regardless of how it got to this surprise removed state: reported missing, eject, set failed) in the surprise removed state indefinitely. When the last handle is closed, the device will transition to the removed state. The device can reappear and be started while it’s previous surprise removed instance is still hanging around.

Doron

That explains everything. I can confirm that the device can be re-instantiated whilst the surprise removed instance is still present; but in the current driver WdfDeviceCreate fails with STATUS_OBJECT_NAME_COLLISION. Now I know what is going on, this is straightforward to fix.

I’ve been writing drivers since VAX/VMS days and obviously still have much to learn!

Many thanks

Chris Read

The name collision is one reason why the guidance is to use a device interface instead of a fixed name. while you can delete the symbolic link name on surprise remove, you can’t delete the surprise removed device’s name until it is in the removed state. Note that you can have N instances of the device in the surprise removed state, not just one.