Crash in Windows Vista because of unsupported FsDriverCallbacks

NTFSD
1

Hi, all

I have tried to install my filter driver (a layered file system actually)
under Windows Vista, and it crashed. When I analyzed the crash,
I have found this stack trace:

ChildEBP RetAddr Args to Child
82e07554 814386f2 82e075a0 00000000 82715020
Ntfs!NtfsFilterCallbackAcquireForCreateSection+0x21
82e0757c 81581fe9 00e075a0 00000001 00000001
nt!FsFilterPerformCallbacks+0xa2
82e076d4 81588814 8282e648 00000001 00000010
nt!FsRtlAcquireFileExclusiveCommon+0x181
82e076ec 8158722f 8282e648 00000010 00000001
nt!FsRtlAcquireToCreateMappedSection+0x15
82e077cc 81572b4b 82e07818 00000008 82e07928 nt!MmCreateSection+0x246
82e07834 8142ba71 82e0795c 00000008 82e07928 nt!NtCreateSection+0x13a
82e07834 81429701 82e0795c 00000008 82e07928 nt!KiFastCallEntry+0x11e
82e078c8 81531a16 82e0795c 00000008 82e07928 nt!ZwCreateSection+0x11
82e07980 81531c00 800000ec 00000000 814e1850 nt!MmCheckSystemImage+0x52
82e079c8 8153199f 82e07aac 00000002 82e079e8
nt!MiCreateSectionForDriver+0x9c
82e079ec 81531698 82e07a1c 82e07aac 00000002
nt!MiObtainSectionForDriver+0x8c
82e07a7c 814079f6 82e07aac 00000000 82141b00 nt!MmLoadSystemImage+0x18b
82e07abc 81407ab4 82e07c2b 82e07ae4 81511ede nt!IopLoadCrashdumpDriver+0x36
82e07ac8 81511ede 000000f0 0080007e 81511f04
nt!IoInitializeCrashDumpNew+0x21
82e07ae4 816c75b7 000000f0 852366e8 85236688 nt!IoInitializeCrashDump+0x89
82e07b20 815189cb 852366f0 00000001 000000f0
nt!IopInitCrashDumpRegCallback+0x8a
82e07b6c 81557ccb 82e07bf0 852366c0 82e07bcc
nt!RtlpCallQueryRegistryRoutine+0x222
82e07bd0 816c765d 00000000 00000092 00000002 nt!RtlQueryRegistryValues+0x2d2
82e07c2c 816c8f79 80823df0 00033000 00000000
nt!IopInitCrashDumpDuringSysInit+0x4a
82e07c94 816cc609 80823df0 00000000 82141b00 nt!IoInitSystem+0x68c

During a bit deeper digging, I looked at the code of
FsRtlAcquireFileExclusiveCommon,
I found something as:

FsRtlAcquireFileExclusiveCommon(PFILE_OBJECT FileObject, BOOLEAN Something)
{
PFAST_IO_DISPATCH FastIoDispatch;
PFS_FILTER_CALLBACKS FsFilterCallbacks;
PDRIVER_EXTENSION DriverExt;
PDEVICE_OBJECT RelDeviceObject;
PDEVICE_OBJECT FsDeviceObject;
PDRIVER_OBJECT FsDriverObject;

RelDeviceObject = IoGetRelatedDeviceObject(FileObject);
FsDeviceObject = IoGetBaseFileSystemDeviceObject(FileObject);
FsDriverObject = FsDeviceObject->DriverObject;
FastIoDispatch = FsDriverObject->FastIoDispatch;
DriverExt = FsDriverObject->DriverExtension;
FsFilterCallbacks = DriverExt->FsFilterCallbacks;

if(DriverExt != NULL && DriverExt->SizeOfFsFilterCallbacks < 0x0C)
// Jump somewhere

This was enough for me to know that the problem is caused by
missing implementation of FS_FILTER_CALLBACKS in my filter.
Unfortunately, I don’t have the latest IFS kit, so I know nothing
about these callbacks (except for what I’ve found in the type
information).
Before I’ll start dissassembling the kernel (again) for finding more info,
I would like to ask:

Is this feature Vista-specific ? Is some information available ?
Is this feature documented in the IFS kit for W2K3 SP1 ?

Regards,

L.

2

Ladislav,

If you have Vista, you should also have the WDK - which *is* now the
latest IFS Kit.

In addition, these callbacks were introduced into Windows XP, so you’d
have to have a VERY old version of the IFS Kit not to include them.

This is still an OS bug - the OS shouldn’t be crashing because you don’t
have the callbacks (they are supposed to be optional, last I checked).

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the next OSR File Systems class in Los
Angeles, CA October 24-27, 2005.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ladislav Zezula
Sent: Friday, September 23, 2005 8:30 AM
To: ntfsd redirect
Subject: [ntfsd] Crash in Windows Vista because of unsupported
FsDriverCallbacks

Hi, all

I have tried to install my filter driver (a layered file system
actually)
under Windows Vista, and it crashed. When I analyzed the crash,
I have found this stack trace:

ChildEBP RetAddr Args to Child
82e07554 814386f2 82e075a0 00000000 82715020
Ntfs!NtfsFilterCallbackAcquireForCreateSection+0x21
82e0757c 81581fe9 00e075a0 00000001 00000001
nt!FsFilterPerformCallbacks+0xa2
82e076d4 81588814 8282e648 00000001 00000010
nt!FsRtlAcquireFileExclusiveCommon+0x181
82e076ec 8158722f 8282e648 00000010 00000001
nt!FsRtlAcquireToCreateMappedSection+0x15
82e077cc 81572b4b 82e07818 00000008 82e07928 nt!MmCreateSection+0x246
82e07834 8142ba71 82e0795c 00000008 82e07928 nt!NtCreateSection+0x13a
82e07834 81429701 82e0795c 00000008 82e07928 nt!KiFastCallEntry+0x11e
82e078c8 81531a16 82e0795c 00000008 82e07928 nt!ZwCreateSection+0x11
82e07980 81531c00 800000ec 00000000 814e1850 nt!MmCheckSystemImage+0x52
82e079c8 8153199f 82e07aac 00000002 82e079e8
nt!MiCreateSectionForDriver+0x9c
82e079ec 81531698 82e07a1c 82e07aac 00000002
nt!MiObtainSectionForDriver+0x8c
82e07a7c 814079f6 82e07aac 00000000 82141b00 nt!MmLoadSystemImage+0x18b
82e07abc 81407ab4 82e07c2b 82e07ae4 81511ede
nt!IopLoadCrashdumpDriver+0x36
82e07ac8 81511ede 000000f0 0080007e 81511f04
nt!IoInitializeCrashDumpNew+0x21
82e07ae4 816c75b7 000000f0 852366e8 85236688
nt!IoInitializeCrashDump+0x89
82e07b20 815189cb 852366f0 00000001 000000f0
nt!IopInitCrashDumpRegCallback+0x8a
82e07b6c 81557ccb 82e07bf0 852366c0 82e07bcc
nt!RtlpCallQueryRegistryRoutine+0x222
82e07bd0 816c765d 00000000 00000092 00000002
nt!RtlQueryRegistryValues+0x2d2
82e07c2c 816c8f79 80823df0 00033000 00000000
nt!IopInitCrashDumpDuringSysInit+0x4a
82e07c94 816cc609 80823df0 00000000 82141b00 nt!IoInitSystem+0x68c

During a bit deeper digging, I looked at the code of
FsRtlAcquireFileExclusiveCommon,
I found something as:

FsRtlAcquireFileExclusiveCommon(PFILE_OBJECT FileObject, BOOLEAN
Something)
{
PFAST_IO_DISPATCH FastIoDispatch;
PFS_FILTER_CALLBACKS FsFilterCallbacks;
PDRIVER_EXTENSION DriverExt;
PDEVICE_OBJECT RelDeviceObject;
PDEVICE_OBJECT FsDeviceObject;
PDRIVER_OBJECT FsDriverObject;

RelDeviceObject = IoGetRelatedDeviceObject(FileObject);
FsDeviceObject = IoGetBaseFileSystemDeviceObject(FileObject);
FsDriverObject = FsDeviceObject->DriverObject;
FastIoDispatch = FsDriverObject->FastIoDispatch;
DriverExt = FsDriverObject->DriverExtension;
FsFilterCallbacks = DriverExt->FsFilterCallbacks;

if(DriverExt != NULL && DriverExt->SizeOfFsFilterCallbacks < 0x0C)
// Jump somewhere

This was enough for me to know that the problem is caused by
missing implementation of FS_FILTER_CALLBACKS in my filter.
Unfortunately, I don’t have the latest IFS kit, so I know nothing
about these callbacks (except for what I’ve found in the type
information).
Before I’ll start dissassembling the kernel (again) for finding more
info,
I would like to ask:

Is this feature Vista-specific ? Is some information available ?
Is this feature documented in the IFS kit for W2K3 SP1 ?

Regards,

L.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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

3

Tony,

thank you for the response.

In addition, these callbacks were introduced into Windows XP, so you’d
have to have a VERY old version of the IFS Kit not to include them.

Hm. Strange is that ntifs.h from 2003 IFS Kit does not include the
pointer to FS_DRIVER_CALLBACKS in the DRIVER_EXTENSION
structure. I found this structure by typing dt nt!_DRIVER_EXTENSION
while debugging live Windows Vista session.

This is still an OS bug - the OS shouldn’t be crashing because you don’t
have the callbacks (they are supposed to be optional, last I checked).

No, this is not the bug in the OS. The crash actually don’t occur
because of FsDriverCallbacks are NULL, but because
they MUST be implemented in my filter - we use our own FCBs,
that may not be passed down to the lower driver without
converting them to lower FS’s FCBs. This means that I need to
get informations about ALL callbacks in the structure, implement
them and then the filter will work (or at least will not crash at THIS
point :slight_smile:

L.

4

Ladislav,

The driver extension is an OS private structure, but when you call FsRtl
to register your callbacks, that is where it stores that information.
However, if you are a file system driver (not a filter) then those
callbacks aren’t required, so again I’m not sure why the OS is crashing.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the next OSR File Systems class in Los
Angeles, CA October 24-27, 2005.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ladislav Zezula
Sent: Friday, September 23, 2005 9:06 AM
To: ntfsd redirect
Subject: Re: [ntfsd] Crash in Windows Vista because of unsupported
FsDriverCallbacks

Tony,

thank you for the response.

In addition, these callbacks were introduced into Windows XP, so you’d
have to have a VERY old version of the IFS Kit not to include them.

Hm. Strange is that ntifs.h from 2003 IFS Kit does not include the
pointer to FS_DRIVER_CALLBACKS in the DRIVER_EXTENSION
structure. I found this structure by typing dt nt!_DRIVER_EXTENSION
while debugging live Windows Vista session.

This is still an OS bug - the OS shouldn’t be crashing because you
don’t
have the callbacks (they are supposed to be optional, last I checked).

No, this is not the bug in the OS. The crash actually don’t occur
because of FsDriverCallbacks are NULL, but because
they MUST be implemented in my filter - we use our own FCBs,
that may not be passed down to the lower driver without
converting them to lower FS’s FCBs. This means that I need to
get informations about ALL callbacks in the structure, implement
them and then the filter will work (or at least will not crash at THIS
point :slight_smile:

L.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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

5

> However, if you are a file system driver (not a filter) then those

callbacks aren’t required, so again I’m not sure why the OS is crashing.

Unfortunately I am. The OS is crashing because of my filter. All IRP calls
and FastIO calls going to our filter and being passed to lower driver must
be “translated” - the file object going from upper filters must be changed
into another file object, retrieved from lower FSD when IRP_MJ_CREATE
has completed. Well I can’t describe this process in detail, but
our FCBs that may just never be seen by lower FSD.

IIRC you have once wrote that OSR’s DMK uses the same approach -
because it acts as a file system, it also uses its own FCBs … ?
If you would pass your FCB to lower FSD, it will immediately
bugcheck in NtfsDecodeFileObject (in the case of Ntfs.sys as lower
FSD).

I must will go deeper after the problem…

L.