Hi all,
I am seeing a crash in the filter manager in conjunction with my file
system, and the call stack is the same as the one shown in this thread:
http://www.osronline.com/showThread.cfm?link=74100
If I understand thread 74100 correctly, the problem seems to be with the
fltmgr.sys making assumptions about the devices it is filtering, and not
necessarily a problem with any file system. Is that correct? Can anyone
from Microsoft confirm Max's guess as to how the fltmgr.sys behaves wrt
named and unnamed devices?
My file system uses FSRTL_ADVANCED_FCB_HEADER, and calls
FsRtlSetupAdvancedHeader() when the FCB is created, and calls
FsRtlTeardownPerStreamContexts() in response to the final CLOSE IRP for this
FCB.
My situation is exactly the same as Anne's from thread 74100. I create one
named device object. I do not have VDOs or VPBs, as there are no physical
devices and no mounting relationships. I do not interact with the Mount
Manager. I create a symbolic link from a drive letter to my named CDO.
There seems to be three solutions I see from thread 74100:
-
Disabling fltmgr.sys makes the crash go away. Not a viable solution for
a shipping product. -
Implement a second, unnamed VDO that is identical to the named CDO, and
use it in the VPB. Since I don't have a VPB, I'm not sure how I would
implement such as solution in my case.
Any other things I should look into? Thanks.
More detailed info
More precisely about the call stack, it is exactly the same up to the
ntdll!RtlFreeHeap+0x20e call. This is my stack:
fltMgr!FltpPreFsFilterOperation+0x3b
nt!FsFilterPerformCallbacks+0xa5
nt!FsRtlAcquireFileExclusiveCommon+0x173
nt!FsRtlAcquireToCreateMappedSection+0x12
nt!MmCreateSection+0x265
nt!NtCreateSection+0x12f
nt!KiFastCallEntry+0xf8
ntdll!KiFastSystemCallRet
ntdll!ZwCreateSection+0xc
kernel32!CreateFileMappingW+0x10b <-- difference from 74100 starts
here
ole32!CFileStream::Init_MemoryMap+0x22e
ole32!CFileStream::InitWorker+0x1f8
ole32!DfFromName+0x83
ole32!DfOpenDocfile+0x1f1
ole32!StgOpenStorage+0x21
shimgvw!CDocFileThumb::Extract+0x42
SHELL32!CGetThumbnailTask::RunInitRT+0x14d
SHELL32!CRunnableTask::Run+0x54
BROWSEUI!CShellTaskScheduler_ThreadProc+0x111
Another difference is environment: I see the problem on xp sp2 machines,
whereas the posters on 74100 seem to say it works on xp sp2, but not on
other versions, like server 2003 sp1.
I create one named CDO called "\Pifs", and then create a symbolic link to
this device from "\GLOBAL??\P:" so that applications can access the file
system via a drive letter.
=================================================
Roger Tawa
http://tawacentral.net/
[One thing about paradigms: shift happens.]
[When you stop, you're done.]