Fsfiltercallbacks on vista BSOD

NTFSD
1

Hello,

I have a legacy filter that worked on XP to filter NTFS. I’m getting a
sporadic blue screen on Vista, with the dump below. I noticed that Ladislav
Zezula had a very similar problem (almost identical, in fact) a while back:
http://www.osronline.com/showThread.cfm?link=81436

I have my own FCBs that I control. Can anyone tell me if I have to
implement the call FileSystemFilterCallbacks in Vista? What appears to be
happening is the resource for my FCB is being referenced, but it’s not where
it’s expected. Any help is appreciated.

Thanks,
Matt

kd> !analyze -v
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

CACHE_MANAGER (34)
See the comment for FAT_FILE_SYSTEM (0x23)
Arguments:
Arg1: 00050751
Arg2: 82aefa24
Arg3: 82aef720
Arg4: 81876fbf

Debugging Details:

EXCEPTION_RECORD: 82aefa24 – (.exr 0xffffffff82aefa24)
ExceptionAddress: 81876fbf (nt!ExIsResourceAcquiredExclusiveLite+0x0000000a)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 0000000e
Attempt to read from address 0000000e

CONTEXT: 82aef720 – (.cxr 0xffffffff82aef720)
eax=89532100 ebx=00000000 ecx=00000000 edx=00000000 esi=843ac008
edi=85136cb0
eip=81876fbf esp=82aefaec ebp=82aefaec iopl=0 nv up ei pl zr na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
nt!ExIsResourceAcquiredExclusiveLite+0xa:
81876fbf f6410e80 test byte ptr [ecx+0Eh],80h
ds:0023:0000000e=??
Resetting default scope

PROCESS_NAME: System

CURRENT_IRQL: 0

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx” referenced
memory at “0x%08lx”. The memory could not be “%s”.

READ_ADDRESS: 0000000e

BUGCHECK_STR: 0x34

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER: from 8218f1f1 to 81876fbf

STACK_TEXT:
82aefaec 8218f1f1 00000000 00000000 82aefb58
nt!ExIsResourceAcquiredExclusiveLite+0xa
82aefb10 818b9563 82aefb58 00000000 00000000
Ntfs!NtfsFilterCallbackAcquireForCreateSection+0x32
82aefb34 8197ac6a 00000000 00000000 82aefc8b
nt!FsFilterPerformCallbacks+0xa0
82aefc90 8197ab51 85136cb0 00000000 85136cb0
nt!FsRtlAcquireFileExclusiveCommon+0x10a
82aefca4 8182467a 85136cb0 85c631f0 00000000
nt!FsRtlAcquireFileExclusive+0x12
82aefcec 818bc2f3 895f4648 82aefd10 00000000 nt!CcWriteBehind+0x3bd
82aefd44 81878e18 83d7e190 00000000 83d81ad0 nt!CcWorkerThread+0x1bd
82aefd7c 81a254a8 83d7e190 82ae4680 00000000 nt!ExpWorkerThread+0xfd
82aefdc0 8189145e 81878d1b 00000000 00000000 nt!PspSystemThreadStartup+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
nt!ExIsResourceAcquiredExclusiveLite+a
81876fbf f6410e80 test byte ptr [ecx+0Eh],80h

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt!ExIsResourceAcquiredExclusiveLite+a

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrpamp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4549ae00

STACK_COMMAND: .cxr 0xffffffff82aef720 ; kb

FAILURE_BUCKET_ID: 0x34_nt!ExIsResourceAcquiredExclusiveLite+a

BUCKET_ID: 0x34_nt!ExIsResourceAcquiredExclusiveLite+a

Followup: MachineOwner

2

Also, this bugcheck only seems to occur *if* I have a minifilter running at
the time.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
Matthew N. White
Sent: Wednesday, March 26, 2008 7:26 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Fsfiltercallbacks on vista BSOD

Hello,

I have a legacy filter that worked on XP to filter NTFS. I’m
getting a
sporadic blue screen on Vista, with the dump below. I
noticed that Ladislav
Zezula had a very similar problem (almost identical, in fact)
a while back:
http://www.osronline.com/showThread.cfm?link=81436

I have my own FCBs that I control. Can anyone tell me if I have to
implement the call FileSystemFilterCallbacks in Vista? What
appears to be
happening is the resource for my FCB is being referenced, but
it’s not where
it’s expected. Any help is appreciated.

Thanks,
Matt

kd> !analyze -v
**************************************************************
**************
***
*
*
* Bugcheck Analysis
*
*
*
**************************************************************
**************
***

CACHE_MANAGER (34)
See the comment for FAT_FILE_SYSTEM (0x23)
Arguments:
Arg1: 00050751
Arg2: 82aefa24
Arg3: 82aef720
Arg4: 81876fbf

Debugging Details:

EXCEPTION_RECORD: 82aefa24 – (.exr 0xffffffff82aefa24)
ExceptionAddress: 81876fbf
(nt!ExIsResourceAcquiredExclusiveLite+0x0000000a)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 0000000e
Attempt to read from address 0000000e

CONTEXT: 82aef720 – (.cxr 0xffffffff82aef720)
eax=89532100 ebx=00000000 ecx=00000000 edx=00000000 esi=843ac008
edi=85136cb0
eip=81876fbf esp=82aefaec ebp=82aefaec iopl=0 nv up
ei pl zr na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
nt!ExIsResourceAcquiredExclusiveLite+0xa:
81876fbf f6410e80 test byte ptr [ecx+0Eh],80h
ds:0023:0000000e=??
Resetting default scope

PROCESS_NAME: System

CURRENT_IRQL: 0

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at
“0x%08lx” referenced
memory at “0x%08lx”. The memory could not be “%s”.

READ_ADDRESS: 0000000e

BUGCHECK_STR: 0x34

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER: from 8218f1f1 to 81876fbf

STACK_TEXT:
82aefaec 8218f1f1 00000000 00000000 82aefb58
nt!ExIsResourceAcquiredExclusiveLite+0xa
82aefb10 818b9563 82aefb58 00000000 00000000
Ntfs!NtfsFilterCallbackAcquireForCreateSection+0x32
82aefb34 8197ac6a 00000000 00000000 82aefc8b
nt!FsFilterPerformCallbacks+0xa0
82aefc90 8197ab51 85136cb0 00000000 85136cb0
nt!FsRtlAcquireFileExclusiveCommon+0x10a
82aefca4 8182467a 85136cb0 85c631f0 00000000
nt!FsRtlAcquireFileExclusive+0x12
82aefcec 818bc2f3 895f4648 82aefd10 00000000 nt!CcWriteBehind+0x3bd
82aefd44 81878e18 83d7e190 00000000 83d81ad0 nt!CcWorkerThread+0x1bd
82aefd7c 81a254a8 83d7e190 82ae4680 00000000 nt!ExpWorkerThread+0xfd
82aefdc0 8189145e 81878d1b 00000000 00000000
nt!PspSystemThreadStartup+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
nt!ExIsResourceAcquiredExclusiveLite+a
81876fbf f6410e80 test byte ptr [ecx+0Eh],80h

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt!ExIsResourceAcquiredExclusiveLite+a

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrpamp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4549ae00

STACK_COMMAND: .cxr 0xffffffff82aef720 ; kb

FAILURE_BUCKET_ID: 0x34_nt!ExIsResourceAcquiredExclusiveLite+a

BUCKET_ID: 0x34_nt!ExIsResourceAcquiredExclusiveLite+a

Followup: MachineOwner

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@bitarmor.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

You might try loading that minifilter then stopping it before you run your
test that fails. If it still fails, it is probably the filter manager that
is causing your driver to fail. Then you would have to determine where the
filter manager is hooking around your driver and what ‘rule’, documented or
not, that you are not following when you are processing IRPs and FastIOs.
If it works with the minifilter gone, then there is some conflict with that
minifilter and your driver and a similar search will be needed. As I am
sure you know, the minifilter manager is a legacy file system filter, but it
will hook before and after every other legacy filter so it can manage
elevations for the minifilters it controls. You might also consider having
the minifilter load at boot time to force the minifilter manager to load
before you load or the reverse if it currently loads before you do.

“Matthew N. White” wrote in message news:xxxxx@ntfsd…
> Also, this bugcheck only seems to occur if I have a minifilter running
> at
> the time.
>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of
>> Matthew N. White
>> Sent: Wednesday, March 26, 2008 7:26 PM
>> To: Windows File Systems Devs Interest List
>> Subject: [ntfsd] Fsfiltercallbacks on vista BSOD
>>
>> Hello,
>>
>> I have a legacy filter that worked on XP to filter NTFS. I’m
>> getting a
>> sporadic blue screen on Vista, with the dump below. I
>> noticed that Ladislav
>> Zezula had a very similar problem (almost identical, in fact)
>> a while back:
>> http://www.osronline.com/showThread.cfm?link=81436
>>
>> I have my own FCBs that I control. Can anyone tell me if I have to
>> implement the call FileSystemFilterCallbacks in Vista? What
>> appears to be
>> happening is the resource for my FCB is being referenced, but
>> it’s not where
>> it’s expected. Any help is appreciated.
>>
>> Thanks,
>> Matt
>>
>> kd> !analyze -v
>>
>>
>>
>>
>>
>> * Bugcheck Analysis
>>
>>
>>
>>******
>> ***********
>>
>>
>> CACHE_MANAGER (34)
>> See the comment for FAT_FILE_SYSTEM (0x23)
>> Arguments:
>> Arg1: 00050751
>> Arg2: 82aefa24
>> Arg3: 82aef720
>> Arg4: 81876fbf
>>
>> Debugging Details:
>> ------------------
>>
>>
>>
>>
>>
>>
>> EXCEPTION_RECORD: 82aefa24 – (.exr 0xffffffff82aefa24)
>> ExceptionAddress: 81876fbf
>> (nt!ExIsResourceAcquiredExclusiveLite+0x0000000a)
>> ExceptionCode: c0000005 (Access violation)
>> ExceptionFlags: 00000000
>> NumberParameters: 2
>> Parameter[0]: 00000000
>> Parameter[1]: 0000000e
>> Attempt to read from address 0000000e
>>
>> CONTEXT: 82aef720 – (.cxr 0xffffffff82aef720)
>> eax=89532100 ebx=00000000 ecx=00000000 edx=00000000 esi=843ac008
>> edi=85136cb0
>> eip=81876fbf esp=82aefaec ebp=82aefaec iopl=0 nv up
>> ei pl zr na pe
>> nc
>> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
>> efl=00010246
>> nt!ExIsResourceAcquiredExclusiveLite+0xa:
>> 81876fbf f6410e80 test byte ptr [ecx+0Eh],80h
>> ds:0023:0000000e=??
>> Resetting default scope
>>
>> PROCESS_NAME: System
>>
>> CURRENT_IRQL: 0
>>
>> ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at
>> “0x%08lx” referenced
>> memory at “0x%08lx”. The memory could not be “%s”.
>>
>> READ_ADDRESS: 0000000e
>>
>> BUGCHECK_STR: 0x34
>>
>> DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE
>>
>> LAST_CONTROL_TRANSFER: from 8218f1f1 to 81876fbf
>>
>> STACK_TEXT:
>> 82aefaec 8218f1f1 00000000 00000000 82aefb58
>> nt!ExIsResourceAcquiredExclusiveLite+0xa
>> 82aefb10 818b9563 82aefb58 00000000 00000000
>> Ntfs!NtfsFilterCallbackAcquireForCreateSection+0x32
>> 82aefb34 8197ac6a 00000000 00000000 82aefc8b
>> nt!FsFilterPerformCallbacks+0xa0
>> 82aefc90 8197ab51 85136cb0 00000000 85136cb0
>> nt!FsRtlAcquireFileExclusiveCommon+0x10a
>> 82aefca4 8182467a 85136cb0 85c631f0 00000000
>> nt!FsRtlAcquireFileExclusive+0x12
>> 82aefcec 818bc2f3 895f4648 82aefd10 00000000 nt!CcWriteBehind+0x3bd
>> 82aefd44 81878e18 83d7e190 00000000 83d81ad0 nt!CcWorkerThread+0x1bd
>> 82aefd7c 81a254a8 83d7e190 82ae4680 00000000 nt!ExpWorkerThread+0xfd
>> 82aefdc0 8189145e 81878d1b 00000000 00000000
>> nt!PspSystemThreadStartup+0x9d
>> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>>
>>
>> FOLLOWUP_IP:
>> nt!ExIsResourceAcquiredExclusiveLite+a
>> 81876fbf f6410e80 test byte ptr [ecx+0Eh],80h
>>
>> SYMBOL_STACK_INDEX: 0
>>
>> SYMBOL_NAME: nt!ExIsResourceAcquiredExclusiveLite+a
>>
>> FOLLOWUP_NAME: MachineOwner
>>
>> MODULE_NAME: nt
>>
>> IMAGE_NAME: ntkrpamp.exe
>>
>> DEBUG_FLR_IMAGE_TIMESTAMP: 4549ae00
>>
>> STACK_COMMAND: .cxr 0xffffffff82aef720 ; kb
>>
>> FAILURE_BUCKET_ID: 0x34_nt!ExIsResourceAcquiredExclusiveLite+a
>>
>> BUCKET_ID: 0x34_nt!ExIsResourceAcquiredExclusiveLite+a
>>
>> Followup: MachineOwner
>> ---------
>>
>>
>>
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule debugging and file system seminars
>> (including our new fs mini-filter seminar) visit:
>> http://www.osr.com/seminars
>>
>> You are currently subscribed to ntfsd as: xxxxx@bitarmor.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>
>
>

4

> I have my own FCBs that I control.

How it works? Do you in post-create replace FSD’s FCB by your own in FO? TBH I cannot imagine that it can work. For example CC callbacks are set in FSD by CcInitializeCacheMap() for given FO and you are not able to intercept these callbacks. Or do you use some trick with different FO?

-bg

5

> How it works? Do you in post-create replace FSD’s FCB by your own in FO?

TBH I cannot imagine that it can work. For example CC callbacks are set in FSD
by CcInitializeCacheMap() for given FO and you are not able to intercept these
callbacks. Or do you use some trick with different FO?

Usualy, the MJ_CREATE path of such layered FSD calls another ZwCreateFile to
create one more file object.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

6

Yup, there are 2 FILE_OBJECTs.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim
S. Shatskih
Sent: Thursday, March 27, 2008 1:35 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Fsfiltercallbacks on vista BSOD

> How it works? Do you in post-create replace FSD’s FCB by
your own in FO?
>TBH I cannot imagine that it can work. For example CC
callbacks are set
>in FSD by CcInitializeCacheMap() for given FO and you are
not able to
>intercept these callbacks. Or do you use some trick with
different FO?

Usualy, the MJ_CREATE path of such layered FSD calls another
ZwCreateFile to create one more file object.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@bitarmor.com
To unsubscribe send a blank email to xxxxx@lists.osr.com