Crash in fltmgr.sys on 2003SP1

NTFSD
1

I have a file system driver that also acts as a filter driver. It
makes use of FsRtlRegisterFileSystemFilterCallbacks() as well as
implementing the lock routines in the FAST_IO_DISPATCH
(AcquireFileForNtCreateSection, etc.).

This works just fine on Windows XP SP2 and Windows 2003 with no
service pack. On Windows 2003 SP1, one of my unit tests, which opens
a memory-mapped file on the file system driver-- using a symbolic link
from \DosDevices\Z: to \Device\ElectricFS, not using any of the
filtering functionality) to test writing to it-- crashes with an access
violation. Disabling the FltMgr service is fine as a workaround, but
I’d rather not ship with that. :slight_smile:

My driver receives IRP_MJ_CREATE, FastIoQueryStandardInfo,
and IRP_MJ_QUERY_INFORMATION before this crash occurs.

The call stack:

fltmgr!FltpPreFsFilterOperation+0x3b
nt!FsFilterPerformCallbacks+0xa5
nt!FsRtlAcquireFileExclusiveCommon+0x16f
nt!FsRtlAcquireToCreateMappedSection+0x12
nt!MmCreateSection+0x270
nt!NtCreateSection+0x12f
nt!KiFastCallEntry+0xf8
ntdll!KiFastSystemCallRet
ntdll!ZwCreateSection+0xc
ntdll!RtlFreeHeap+0x20e

Relevant instructions leading up to the crash, with my notes from
stepping through the code:

mov eax,[esi+0x8] # eax = FltMgr device object
mov eax,[eax+0x28] # eax = devobj->DeviceExtension
mov eax,[eax+0x2c] # read past the end of the device

extension

…
lea eax,[eax+ecx*8+0x90] # ecx is 0x15 at this point
…
cmp [eax],eax

At the time of the crash, ebx is the FltMgr device object
and edx is the FILE_OBJECT opened in my driver.

Upon inspection with WinDbg, the device extension for FltMgr looks
something like this:

struct FltMgrDevExt {
CSHORT type; /* always 0xf106 */
USHORT size; /* always 0x28 */
DEVICE_OBJECT *target; /* device being filtered */
ULONG something; /* always 815ce000 */
LIST_ENTRY chain; /* links to other extensions */
DEVICE_OBJECT *owner; /* fltmgr filter */
UNICODE_STRING deviceName;
UNICODE_STRING fsName;
} sFltMgrDevExt;

with the buffers for the strings tacked on to the end. When
FltpPreFsFilterOperation() reads past the end of the device extension,
it picks up a couple of unicode characters and eventually winds up
using them as a basis for an address.

I tried turning off the call to
FsRtlRegisterFileSystemFilterCallbacks() in my DriverEntry, but that
didn’t make a difference, so I don’t think the filter functionality
is interfering here.

Is there a way to persuade fltmgr.sys not to filter my device here?
Is there some way my driver could be causing fltmgr.sys to create a
malformed device extension? (It looks internally consistent–
deviceName.Buffer points just after the end of fsName.)

Thanks,
Max

2

Hi,
I also have a similar problem with a virtual file system driver. On 2003
SP1 it bluescreens with bug check 0x8E (0xC0000005,…)
The driver shown is fltmgr.sys, and disabling this is the work around.
Any help will be appreciated.
Thank you,
Anne

Max Kaehn
Sent by: xxxxx@lists.osr.com
14/04/2005 20:22
Please respond to “Windows File Systems Devs Interest List”

To: “Windows File Systems Devs Interest List”
cc:
Subject: [ntfsd] Crash in fltmgr.sys on 2003SP1

I have a file system driver that also acts as a filter driver. It
makes use of FsRtlRegisterFileSystemFilterCallbacks() as well as
implementing the lock routines in the FAST_IO_DISPATCH
(AcquireFileForNtCreateSection, etc.).

This works just fine on Windows XP SP2 and Windows 2003 with no
service pack. On Windows 2003 SP1, one of my unit tests, which opens
a memory-mapped file on the file system driver-- using a symbolic link
from \DosDevices\Z: to \Device\ElectricFS, not using any of the
filtering functionality) to test writing to it-- crashes with an access
violation. Disabling the FltMgr service is fine as a workaround, but
I’d rather not ship with that. :slight_smile:

My driver receives IRP_MJ_CREATE, FastIoQueryStandardInfo,
and IRP_MJ_QUERY_INFORMATION before this crash occurs.

The call stack:

fltmgr!FltpPreFsFilterOperation+0x3b
nt!FsFilterPerformCallbacks+0xa5
nt!FsRtlAcquireFileExclusiveCommon+0x16f
nt!FsRtlAcquireToCreateMappedSection+0x12
nt!MmCreateSection+0x270
nt!NtCreateSection+0x12f
nt!KiFastCallEntry+0xf8
ntdll!KiFastSystemCallRet
ntdll!ZwCreateSection+0xc
ntdll!RtlFreeHeap+0x20e

Relevant instructions leading up to the crash, with my notes from
stepping through the code:

mov eax,[esi+0x8] # eax = FltMgr device object
mov eax,[eax+0x28] # eax = devobj->DeviceExtension
mov eax,[eax+0x2c] # read past the end of the device
# extension
…
lea eax,[eax+ecx8+0x90] # ecx is 0x15 at this point
…
cmp [eax],eax

At the time of the crash, ebx is the FltMgr device object
and edx is the FILE_OBJECT opened in my driver.

Upon inspection with WinDbg, the device extension for FltMgr looks
something like this:

struct FltMgrDevExt {
CSHORT type; / always 0xf106 /
USHORT size; / always 0x28 */
DEVICE_OBJECT target; / device being filtered /
ULONG something; / always 815ce000 /
LIST_ENTRY chain; / links to other extensions */
DEVICE_OBJECT owner; / fltmgr filter */
UNICODE_STRING deviceName;
UNICODE_STRING fsName;
} sFltMgrDevExt;

with the buffers for the strings tacked on to the end. When
FltpPreFsFilterOperation() reads past the end of the device extension,
it picks up a couple of unicode characters and eventually winds up
using them as a basis for an address.

I tried turning off the call to
FsRtlRegisterFileSystemFilterCallbacks() in my DriverEntry, but that
didn’t make a difference, so I don’t think the filter functionality
is interfering here.

Is there a way to persuade fltmgr.sys not to filter my device here?
Is there some way my driver could be causing fltmgr.sys to create a
malformed device extension? (It looks internally consistent–
deviceName.Buffer points just after the end of fsName.)

Thanks,
Max

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

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

3

Is your FSD using the FSRTL_ADVANCED_FCB_HEADER? Are you initializing
stream context supports? That’s a case the filter manager is unlikely
to be heavily tested against and may cause problems of this type.

You didn’t say so, but I assume you used “!pool” to confirm that this
access was beyond the buffer containing the device object (and device
extension)?

Not much help, I’m afraid. Oh, one other thing to try: use a CHECKED
version of filter manager, that will give you better diagnostic
information if you aren’t doing something that filter manager expects
you to do. Obviously, disabling filter manager is nothing more than a
short-term work around.

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@plasmon.co.uk
Sent: Thursday, April 21, 2005 10:29 AM
To: ntfsd redirect
Subject: Re: [ntfsd] Crash in fltmgr.sys on 2003SP1

Hi,
I also have a similar problem with a virtual file system driver. On 2003
SP1 it bluescreens with bug check 0x8E (0xC0000005,…)
The driver shown is fltmgr.sys, and disabling this is the work around.
Any help will be appreciated.
Thank you,
Anne

Max Kaehn
Sent by: xxxxx@lists.osr.com

14/04/2005 20:22
Please respond to “Windows File Systems Devs Interest List”

To: “Windows File Systems Devs Interest List”

cc:
Subject: [ntfsd] Crash in fltmgr.sys on 2003SP1

I have a file system driver that also acts as a filter driver. It
makes use of FsRtlRegisterFileSystemFilterCallbacks() as well as
implementing the lock routines in the FAST_IO_DISPATCH
(AcquireFileForNtCreateSection, etc.).

This works just fine on Windows XP SP2 and Windows 2003 with no
service pack. On Windows 2003 SP1, one of my unit tests, which opens
a memory-mapped file on the file system driver-- using a symbolic link
from \DosDevices\Z: to \Device\ElectricFS, not using any of the
filtering functionality) to test writing to it-- crashes with an access
violation. Disabling the FltMgr service is fine as a workaround, but
I’d rather not ship with that. :slight_smile:

My driver receives IRP_MJ_CREATE, FastIoQueryStandardInfo,
and IRP_MJ_QUERY_INFORMATION before this crash occurs.

The call stack:

fltmgr!FltpPreFsFilterOperation+0x3b
nt!FsFilterPerformCallbacks+0xa5
nt!FsRtlAcquireFileExclusiveCommon+0x16f
nt!FsRtlAcquireToCreateMappedSection+0x12
nt!MmCreateSection+0x270
nt!NtCreateSection+0x12f
nt!KiFastCallEntry+0xf8
ntdll!KiFastSystemCallRet
ntdll!ZwCreateSection+0xc
ntdll!RtlFreeHeap+0x20e

Relevant instructions leading up to the crash, with my notes from
stepping through the code:

mov eax,[esi+0x8] # eax = FltMgr device object
mov eax,[eax+0x28] # eax = devobj->DeviceExtension
mov eax,[eax+0x2c] # read past the end of the device
# extension
…
lea eax,[eax+ecx8+0x90] # ecx is 0x15 at this point
…
cmp [eax],eax

At the time of the crash, ebx is the FltMgr device object
and edx is the FILE_OBJECT opened in my driver.

Upon inspection with WinDbg, the device extension for FltMgr looks
something like this:

struct FltMgrDevExt {
CSHORT type; / always 0xf106 /
USHORT size; / always 0x28 */
DEVICE_OBJECT target; / device being filtered /
ULONG something; / always 815ce000 /
LIST_ENTRY chain; / links to other extensions */
DEVICE_OBJECT owner; / fltmgr filter */
UNICODE_STRING deviceName;
UNICODE_STRING fsName;
} sFltMgrDevExt;

with the buffers for the strings tacked on to the end. When
FltpPreFsFilterOperation() reads past the end of the device extension,
it picks up a couple of unicode characters and eventually winds up
using them as a basis for an address.

I tried turning off the call to
FsRtlRegisterFileSystemFilterCallbacks() in my DriverEntry, but that
didn’t make a difference, so I don’t think the filter functionality
is interfering here.

Is there a way to persuade fltmgr.sys not to filter my device here?
Is there some way my driver could be causing fltmgr.sys to create a
malformed device extension? (It looks internally consistent–
deviceName.Buffer points just after the end of fsName.)

Thanks,
Max

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

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

— 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

4

On Thu, 2005-04-21 at 08:30, Tony Mason wrote:

Is your FSD using the FSRTL_ADVANCED_FCB_HEADER? Are you initializing
stream context supports? That’s a case the filter manager is unlikely
to be heavily tested against and may cause problems of this type.

That was the first thing I added to my driver when that
problem came up. :slight_smile: (The only thing necessary is
initializing the mutex and calling FsRtlSetupAdvancedHeader()
when you create the FCB and calling FsRtlTeardownPerStreamContexts()
when you clean it up, right?) Didn’t make a different in the
crash I was getting; mine looks like a problem with the device
extension for the filter device object created by fltmgr.sys.

Not much help, I’m afraid. Oh, one other thing to try: use a CHECKED
version of filter manager, that will give you better diagnostic
information if you aren’t doing something that filter manager expects
you to do.

I’ll give that a try. Thanks.

5

On Thu, 2005-04-21 at 08:30, Tony Mason wrote:

Not much help, I’m afraid. Oh, one other thing to try: use a CHECKED
version of filter manager, that will give you better diagnostic
information if you aren’t doing something that filter manager expects
you to do. Obviously, disabling filter manager is nothing more than a
short-term work around.

There was an assertion failure in there that was fairly informative:

*** Assertion failed:
(((PVOLUME_DEVICE_EXTENSION)((DeviceObject)->DeviceExtension))->Type.Signature) == FLT_TYPE_VOLUME_DEVICE_EXT
*** Source File: .\mainfilter.h, line 3800

Looking at the device extension on the filter manager device, it
looks like its “type” field was 0xf106, and there was a line of
assembly code:

cmp word ptr [ecx],0xf107

visible near the assertion failure. So it looks like fltmgr.sys
was assuming that my device was of a type that never received
filter callbacks. A filter callback comes in, the DeviceExtension
isn’t of the format it expects, and BOOM!

My driver was “mounting” a file system by creating a symbolic link
to the control device object, and the VPB supplied the CDO as
both DeviceObject and RealDevice. (This works just fine on
Windows 2000 SP3-4, Windows XP SP2, and vanilla Windows Server 2003.)
I added a second, nameless FILE_DEVICE_DISK_FILE_SYSTEM driver
object and pointed my vpb->DeviceObject at it, and the problem
evaporated nicely.

So it looks like the principle here is “always create a volume
device object”, even if you’re hooking your filesystem up to
DosDevices directly without involving the Mount Manager.

6

Hi Max,
I am getting the same error message as you specified with a checked
version of fltmgr.sys,
Do you need the new IFS kit installed?
Our driver is a legacy driver and we are essentially creating a single
named device object of type FILE_DEVICE_DISK_FILE_SYSTEM, and a symbolic
link that associates a drive letter with it. I don’t know whether this
would be classed as a “CDO” or a “VDO”, since there is no physical device
that corresponds to the device object, and no VPB that creates any form of
“mounting” relationship between our device object and another. Our code
does not actively interact with the Mount Manager or any other Windows
subsystems - it simply receives IRPs and processes them by sending IOCTLs
to another of our own drivers.

As far as I am aware, the Filter Manager is deciding to filter our device
object IRPs, and later having a problem with something. We do not send
anything to the Filter Manager by choice, and the type of our device
object does not change while it exists.
I also tried creating another device of type FILE_DEVICE_DISK and
initialise a vpb but it still did not work.
Any pointers?
Thanks,
Anne

Max Kaehn
Sent by: xxxxx@lists.osr.com
28/04/2005 18:29
Please respond to “Windows File Systems Devs Interest List”

To: “Windows File Systems Devs Interest List”
cc:
Subject: RE: [ntfsd] Crash in fltmgr.sys on 2003SP1

On Thu, 2005-04-21 at 08:30, Tony Mason wrote:
> Not much help, I’m afraid. Oh, one other thing to try: use a CHECKED
> version of filter manager, that will give you better diagnostic
> information if you aren’t doing something that filter manager expects
> you to do. Obviously, disabling filter manager is nothing more than a
> short-term work around.

There was an assertion failure in there that was fairly informative:

Assertion failed:
(((PVOLUME_DEVICE_EXTENSION)((DeviceObject)->DeviceExtension))->Type.Signature)
== FLT_TYPE_VOLUME_DEVICE_EXT
 Source File: .\mainfilter.h, line 3800

Looking at the device extension on the filter manager device, it
looks like its “type” field was 0xf106, and there was a line of
assembly code:

cmp word ptr [ecx],0xf107

visible near the assertion failure. So it looks like fltmgr.sys
was assuming that my device was of a type that never received
filter callbacks. A filter callback comes in, the DeviceExtension
isn’t of the format it expects, and BOOM!

My driver was “mounting” a file system by creating a symbolic link
to the control device object, and the VPB supplied the CDO as
both DeviceObject and RealDevice. (This works just fine on
Windows 2000 SP3-4, Windows XP SP2, and vanilla Windows Server 2003.)
I added a second, nameless FILE_DEVICE_DISK_FILE_SYSTEM driver
object and pointed my vpb->DeviceObject at it, and the problem
evaporated nicely.

So it looks like the principle here is “always create a volume
device object”, even if you’re hooking your filesystem up to
DosDevices directly without involving the Mount Manager.

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

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

7

On Fri, 2005-05-06 at 05:02, xxxxx@plasmon.co.uk wrote:

Hi Max,
I am getting the same error message as you specified with a checked
version of fltmgr.sys,
Do you need the new IFS kit installed?

Shouldn’t make a difference.

Our driver is a legacy driver and we are essentially creating a single
named device object of type FILE_DEVICE_DISK_FILE_SYSTEM, and a
symbolic link that associates a drive letter with it. I don’t know
whether this would be classed as a “CDO” or a “VDO”, since there is no
physical device that corresponds to the device object, and no VPB that
creates any form of “mounting” relationship between our device object
and another. Our code does not actively interact with the Mount
Manager or any other Windows subsystems - it simply receives IRPs and
processes them by sending IOCTLs to another of our own drivers.

I don’t know how fltmgr.sys detects what kind of device object
you’ve got. What I had was a setup where my VPB had the CDO
(which was named) as both RealDevice and DeviceObject. When
I created a second device object, identical to my CDO but
without a name, and specified that as the DeviceObject in my
VPB, the problem went away. My guess is that fltmgr.sys
looks at a device object, checks for a name, and if a name
is present, it creates one type of device extension in its
filter device, and if it doesn’t have a name, it creates
a different one. So when you create your named device object,
also create a duplicate unnamed one (same type, same extension),
and that should take care of the problem.