Hi guys,
I’m developing some kind of a virtual layered FSD. Yesterday I caught a
BSOD with RESOURCE_NOT_OWNED on Windows Vista 5744 RC2 in NTFS.SYS
driver. During initialization of my driver I set six FsFilterCallbacks
on all PreAcquire and PreRelease operations using
FsRtlRegisterFileSystemFilterCallbacks(), then I attach my device
object to a particular file system driver stack and perform file system
request processing. Some of specific create requests are exclusively
processed by my FSD, so the resulting file objects are only processed
by my FS driver and not passed to lower drivers. All other FS requests
(not mine) are passed thru down the FS driver stack. In
FsFilterCallbacks I return STATUS_SUCCESS for all requests with file
objects which are not mine, for my own (private) file objects I return
STATUS_FSFILTER_OP_COMPLETED_SUCCESSFULLY which doesn’t cause these
requests to be passed to a next registered FsFilterCallback or to a
base file system driver or to a default FsRtl handler (I perfectly know
that this status code has no effect on Windows XP and Windows XP SP1,
but in this case I use different technique for processing these six
Fast I/O MM callbacks).
Everything worked fine till yesterday. I have never seen this BSOD, but
yesterday I changed error statuses in IRP_MJ_CREATE and
IRP_MJ_SET_INFORMATION handlers. In IRP_MJ_CREATE handler I replaced
STATUS_INVALID_PARAMETER with STATUS_ACCESS_DENIED for cases when
AllocationSize is specified. In IRP_MJ_SET_INFORMATION handler I
changed STATUS_INVALID_PARAMETER to STATUS_ACCESS_DENIED and
STATUS_CANNOT_DELETE for some file information class codes. It’s
significant to say that when I changed return status to
STATUS_ACCESS_DENIED in IRP_MJ_CREATE handler for requests with
non-zero AllocationSize, I started to receive this request six times in
a row while processing CopyFile() routine!!! When I was returning
STATUS_INVALID_PARAMETER, I received such request only two times in a
row. I have never thought that the error status in this particular case
may dramatically affect the I/O Manager in processing user mode
requests like this (CopyFile()).
But back to my BSOD case. The thing is that sometimes
PreAcquireForSectionSynchronization is called for some system file
object (for some of prefecthed files) and is not released while my
driver is processing file requests from a test user mode application, I
can see it clearly in my detailed debug output. When my driver detaches
itself from file system stack, everything is OK, but next the NTFS.SYS
driver is called via NtfsReleaseForCreateSection() with a resource
which is already released!!! And that’s it, BSOD is guaranteed… I
don’t really know where this resource might be released. I would
certainly observe it in my debug output but I didn’t. All other section
synchronization requests for system (not my private) file objects
always come in pairs, I can see it in debug output. I always pass these
requests to next registered FsFilterCallbacks or base FS driver Fast
I/O handlers and I never touch file objects and their associated
structures if these are not my private file objects.
I’m really stuck. I have no clue what could happen to this file object
and its resource on the way… If I can reproduce this BSOD I will of
course post one more request with a full stack trace.
And one more query. Can the return error status code affect I/O Manager
in post-processing IRP_MJ_CREATE and IRP_MJ_SET_INFORMATION requests?
Many thanks beforehand. Any suggestions and even clues will be highly
appreciated. Sorry for a little bit confused and chaotic explanation.
With best regards,
Konstantin Manurin
System Programmer
href=“mailto:xxxxx@gmail.com”>mailto:xxxxx@gmail.com