I just wanted to post a followup on the resolution to the following thread which is now so old that no additional replies can be posted to it:
RE: Intermittent File System Driver Unload Failure on Windows 8.1
The key underlying issue here is a bug in the IopMountVolume code which Microsoft will be fixing in the next release of Windows beyond Windows 8.1. In that code they decremented devobj->ReferenceCount but did not see if the count went to zero and complete the driver unload process if it did. This is a unique unload condition for File Systems only, but could explain at least some of the issues others have mentioned here with regard to difficulties in getting File System drivers to unload. For us this only really occurs in a stress test environment, so we’re ok with this being fixed in later releases. In 6 or more years of our File System supporting unload in the field, we have not actually seen this condition occur in production.
This was also further confirmation in regards to the driver unload process and the relative use of the “generic” object reference count vs. use of the DEVICE_OBJECT-specific ReferenceCount field. The miniimum I can say here is that in the debugging traciing I referenced in the previous thread, the behavior I saw relative to the “generic” object reference count being high was not a gating factor to the driver unload process, it was the devobj->ReferenceCount was relevant to the driver unload procedure.
Just wanted to close the loop on this to clarify the conditions that were operative (at least in this case).