|
阅读：2282回复：5
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, 但效果不彰 小弟还很菜, 请大家指点，谢谢了!! |
|
|
沙发#
发布于：2010-12-07 01:18
What is "dismount file system"? A volume can be dismounted not FS.
It seems the volume dismount has some problems. You'd better post your crash dump here. I'm particular interested in the content of FileObject->VPB. |
|
|
板凳#
发布于：2010-12-07 17:10
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! |
|
|
地板#
发布于：2010-12-08 01:26
Cannot see anything wrong with this simple call stack.
If I remember correctly, the first parameter of function FsRtlLookupPerStreamContextInternal is FCB. The FCB must be created by your FS. You can start your debugging by analyzing it. |
|
|
地下室#
发布于：2010-12-08 10:47
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! |
|
|
5楼#
发布于：2010-12-09 00:26
In Windows world, we don't have iNode but FileObject.
Handle is managed by object manager. It's not AP's responsibility to invalidate a handle. Though there's event mechanism to tell voluntarily registered APs about volume changes, object manager and file system must deal with handle closure and FCB tear down. When a volume is dismounted, all volume related meta information can be released but not file related such as FCB. I suggest you read through FastFat's source code, especially FatDismountVolume function in fsctrl.c. Microsoft even puts interesting comments there. |
|