[wdmaudiodev] [Q] How does IoRemoveLock protect thread that does the final unlock?

I have an issue I don’t understand about using Plug and Play “remove locks”.

Assume the Configuration Manager, running on some thread (let’s call it
Thread A), has called into a driver for IRP_MN_REMOVE_DEVICE processing and
is currently blocked inside IoReleaseRemoveLockAndWait(), pending the final
release of the remove lock.

Futher assume there’s only one outstanding remove lock left due to some
other thread (let’s call it Thread B) having called into the driver for a
synchronously processed IRP for which the processing is not yet finished.

When processing of the synchronous IRP is complete (and if no additional
references occur in the meantime of course) and Thread B finally calls
IoReleaseRemoveLock() on its way out of the IRP dispatch routine, is there
not a chance that Thread A will wake up and unload driver before Thread B
can return all way out of the driver’s code?

Or, does the fact the Thread B has called the driver incur an additional
reference somwhere that I’m not aware of (that isn’t released until Thread B
has fully returned from the driver call)?

  • Matt