dismount file system 与 handle的问题

小弟在维护一个年代久远的file system driver
在win7下会发生以下的问题:

在dismount file system后, 内核所有跟该file system相关的物件都已经delete掉
若dismount前有开启explorer, 该AP仍会保有root directory的handle.
之后该AP尝试close handle, 因handle对应于内核层的kernel object早已不存在, 所以BSOD就会发生

小弟想请问的是
内核层中, 是否有办法可以通知应用层持有handle的AP在dismount file system后自动的将handle放掉
我曾经试过FSRTL_VOLUME_DISMOUNT, 但效果不彰
小弟还很菜, 请大家指点，谢谢了!!

Sorry, it's a typo.
Thanks! michaelgz. The "dismount volume" is correct.

I'm sorry that I didn't save the crash dump.
But according the log I saved from Windbg, the crash point was at FsRtlLookupPerStreamContextInternal.
Here is the stack backtrace when BSOD occurred.

ChildEBP RetAddr  
9278bae8 86897f3b nt!FsRtlLookupPerStreamContextInternal+0x9a
9278bb2c 86890a9d fltmgr!FltpGetStreamListCtrl+0x5b
9278bb9c 868939f0 fltmgr!FltpPerformPreCallbacks+0x2ff
9278bbb4 86893f01 fltmgr!FltpPassThroughInternal+0x40
9278bbd8 868943ba fltmgr!FltpPassThrough+0x203
9278bc08 828904bc fltmgr!FltpDispatch+0xb4
9278bc20 82a95dc7 nt!IofCallDriver+0x63
9278bc64 82a756f4 nt!IopDeleteFile+0x10c
9278bc7c 828bcf60 nt!ObpRemoveObjectRoutine+0x59
9278bc90 828bced0 nt!ObfDereferenceObjectWithTag+0x88
9278bc98 82a9978c nt!ObfDereferenceObject+0xd
9278bcdc 82a9af72 nt!ObpCloseHandleTableEntry+0x21d
9278bd0c 82a9b0ea nt!ObpCloseHandle+0x7f
9278bd28 8289742a nt!NtClose+0x4e
9278bd28 773a64f4 nt!KiFastCallEntry+0x12a
0012f294 76c105df 0x773a64f4
0012f2a4 02945e76 kernel32!CloseHandleImplementation+0x3f

As I know, when CloseHandle() been called in AP layer, it will trigger IRP_MJ_CLEANUP & IRP_MJ_CLOSE to send to kernel layer.
According my observe, this BSOD was occured after IRP_MJ_CLEANUP and IRP_MJ_CLOSE was not sent yet.

I'm very grateful for your help, thank you very much!

Thank you, michaelgz!
I used to print FCB header's content for each IRP received.
During IRP_MJ_CLEANUP(passed due to CloseHandle() been called, just before BSOD), the contents of FCB header has been a mess.
I think it's because the content of iNode had been destroied during dismout volume but AP still own the handle which point to this invalid address .

So I'm very curious why AP still use this invalid handle and try to close it.
Is there a way to inform AP the handle is already illegal?

Thanks for your help!