question from sfilter

NTFSD
1

Hi all,

Suppose I have two file system filters(mostly copied from sfilter): A and B.
A calls IoRegisterFsRegistrationChange before B does. As a result, when a
file system driver C calls IoRegisterFileSystem, B will be notified before
A. Therefore, B will attach to C and A will attach to B.

C<-B<-A

When C calls IoUnregisterFileSystem, B will still be notified before A. B
will call SfDetachFromFileSystemDevice, the same as sfilter does:

VOID SfDetachFromFileSystemDevice(IN PDEVICE_OBJECT DeviceObject)
{
PDEVICE_OBJECT ourAttachedDevice = DeviceObject->AttachedDevice;

while (NULL != ourAttachedDevice) {

if (IS_MY_DEVICE_OBJECT( ourAttachedDevice ))
{
IoDetachDevice( DeviceObject );
IoDeleteDevice( ourAttachedDevice );
return;
}

DeviceObject = ourAttachedDevice;
ourAttachedDevice = ourAttachedDevice->AttachedDevice;
}
}

The problem is, when B calls IoDetachDevice and IoDeleteDevice, it’s still
attached by A. So when A get the notification, DeviceObject->AttachedDevice
will be empty and A’s filter device object will never have a chance to get
deleted.

Is there anything wrong in my understanding?

Thanks

2

When B calls IoDeleteDevice, the I/O Manager will call IoDetachDevice
for ‘A’, so this situation you describe should not arise.

Regards,

Tony

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Min Wang
Sent: Thursday, February 24, 2005 5:43 PM
To: ntfsd redirect
Subject: [ntfsd] question from sfilter

Hi all,

Suppose I have two file system filters(mostly copied from sfilter): A
and B.
A calls IoRegisterFsRegistrationChange before B does. As a result, when
a
file system driver C calls IoRegisterFileSystem, B will be notified
before
A. Therefore, B will attach to C and A will attach to B.

C<-B<-A

When C calls IoUnregisterFileSystem, B will still be notified before A.
B
will call SfDetachFromFileSystemDevice, the same as sfilter does:

VOID SfDetachFromFileSystemDevice(IN PDEVICE_OBJECT DeviceObject)
{
PDEVICE_OBJECT ourAttachedDevice = DeviceObject->AttachedDevice;

while (NULL != ourAttachedDevice) {

if (IS_MY_DEVICE_OBJECT( ourAttachedDevice ))
{
IoDetachDevice( DeviceObject );
IoDeleteDevice( ourAttachedDevice );
return;
}

DeviceObject = ourAttachedDevice;
ourAttachedDevice = ourAttachedDevice->AttachedDevice;
}
}

The problem is, when B calls IoDetachDevice and IoDeleteDevice, it’s
still
attached by A. So when A get the notification,
DeviceObject->AttachedDevice
will be empty and A’s filter device object will never have a chance to
get
deleted.

Is there anything wrong in my understanding?

Thanks

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

Thanks for the reply.

When A calls SfDetachFromFileSystemDevice, it will search from the file
system device object(ourAttachedDevice = DeviceObject->AttachedDevice).
After the file system device object is detached by B, its AttachedDevice is
NULL. So A will never enter the “while” loop and call IoDeleteDevice.

And I don’t think I/O manager would call IoDetachDevice for a driver.
Otherwise the driver itself doesn’t know its filter device is already
detached by I/O manager, it may call IoDetachDevice later, which could crash
the system.

Min

“Tony Mason” ???:xxxxx@ntfsd…
When B calls IoDeleteDevice, the I/O Manager will call IoDetachDevice
for ‘A’, so this situation you describe should not arise.

Regards,

Tony

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Min Wang
Sent: Thursday, February 24, 2005 5:43 PM
To: ntfsd redirect
Subject: [ntfsd] question from sfilter

Hi all,

Suppose I have two file system filters(mostly copied from sfilter): A
and B.
A calls IoRegisterFsRegistrationChange before B does. As a result, when
a
file system driver C calls IoRegisterFileSystem, B will be notified
before
A. Therefore, B will attach to C and A will attach to B.

C<-B<-A

When C calls IoUnregisterFileSystem, B will still be notified before A.
B
will call SfDetachFromFileSystemDevice, the same as sfilter does:

VOID SfDetachFromFileSystemDevice(IN PDEVICE_OBJECT DeviceObject)
{
PDEVICE_OBJECT ourAttachedDevice = DeviceObject->AttachedDevice;

while (NULL != ourAttachedDevice) {

if (IS_MY_DEVICE_OBJECT( ourAttachedDevice ))
{
IoDetachDevice( DeviceObject );
IoDeleteDevice( ourAttachedDevice );
return;
}

DeviceObject = ourAttachedDevice;
ourAttachedDevice = ourAttachedDevice->AttachedDevice;
}
}

The problem is, when B calls IoDetachDevice and IoDeleteDevice, it’s
still
attached by A. So when A get the notification,
DeviceObject->AttachedDevice
will be empty and A’s filter device object will never have a chance to
get
deleted.

Is there anything wrong in my understanding?

Thanks

—
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

FS filters detach only on FastIoDetachDevice, not on filesystem removal
notification.

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

----- Original Message -----
From: “Min Wang”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Friday, February 25, 2005 1:42 AM
Subject: [ntfsd] question from sfilter

> Hi all,
>
> Suppose I have two file system filters(mostly copied from sfilter): A and B.
> A calls IoRegisterFsRegistrationChange before B does. As a result, when a
> file system driver C calls IoRegisterFileSystem, B will be notified before
> A. Therefore, B will attach to C and A will attach to B.
>
> C<-B<-A
>
> When C calls IoUnregisterFileSystem, B will still be notified before A. B
> will call SfDetachFromFileSystemDevice, the same as sfilter does:
>
> VOID SfDetachFromFileSystemDevice(IN PDEVICE_OBJECT DeviceObject)
> {
> PDEVICE_OBJECT ourAttachedDevice = DeviceObject->AttachedDevice;
>
> while (NULL != ourAttachedDevice) {
>
> if (IS_MY_DEVICE_OBJECT( ourAttachedDevice ))
> {
> IoDetachDevice( DeviceObject );
> IoDeleteDevice( ourAttachedDevice );
> return;
> }
>
> DeviceObject = ourAttachedDevice;
> ourAttachedDevice = ourAttachedDevice->AttachedDevice;
> }
> }
>
> The problem is, when B calls IoDetachDevice and IoDeleteDevice, it’s still
> attached by A. So when A get the notification, DeviceObject->AttachedDevice
> will be empty and A’s filter device object will never have a chance to get
> deleted.
>
> Is there anything wrong in my understanding?
>
> Thanks
>
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

5

> And I don’t think I/O manager would call IoDetachDevice for a driver.

IoDeleteDevice on lower device causes FastIoDetachDevice to be called on all
upper attached devices. If some of them will fail - then IoDeleteDevice will
fail (if not bugcheck).

FastIoDetachDevice must detach your device from the bottom one and destroy
everything related to your filter device (including the filter device itself).

This is for FS stacks. PnP stacks are other.

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

6

I disagree with one thing Max says here: “… and destroy everything
related to your filter device (including the filter device itself).”

You DO need to arrange for proper cleanup, but it need not be done
during the FastIoDetachDevice call - we’ve discussed this issue before
because there are some nasty cases where you CANNOT tear it down in
FastIoDetachDevice (Neal assures me these are all found and fixed, but
given that we support downrev customers and older OS versions we don’t
always have the luxury of saying “use the latest hot fix from
Microsoft”.)

I DO agree with him otherwise. Last I checked, IoDeleteDevice bugchecks
if the layered filter does not detach; when that filter driver deletes
its device object, an attached filter (to it) will then be detached. In
many ways the model is similar to the way I/O completion unwinds things,
and it really is an elegant solution.

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 April
4, 2005 in Boston!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Friday, February 25, 2005 3:24 PM
To: ntfsd redirect
Subject: Re: Re:[ntfsd] question from sfilter

And I don’t think I/O manager would call IoDetachDevice for a driver.

IoDeleteDevice on lower device causes FastIoDetachDevice to be called on
all
upper attached devices. If some of them will fail - then IoDeleteDevice
will
fail (if not bugcheck).

FastIoDetachDevice must detach your device from the bottom one and
destroy
everything related to your filter device (including the filter device
itself).

This is for FS stacks. PnP stacks are other.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.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

7

Hi Max,

According to what you said, FS filter’s FastIoDetachDevice is triggered only
by lower driver’s IoDeleteDevice. If an FS driver doesn’t delete itself
after calling IoUnregisterFileSystem, FS filters will keep on attaching to
it even if they receive the NoActive file system notification. If this is
the case, the sfilter sample in 2003 IFSDDK is wrong, because it calls
IoDetachDevice in its notification routine SfFsNotification.

Min

“Maxim S. Shatskih” ???:xxxxx@ntfsd…
> FS filters detach only on FastIoDetachDevice, not on filesystem removal
> notification.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “Min Wang”
> Newsgroups: ntfsd
> To: “Windows File Systems Devs Interest List”
> Sent: Friday, February 25, 2005 1:42 AM
> Subject: [ntfsd] question from sfilter
>
>
>> Hi all,
>>
>> Suppose I have two file system filters(mostly copied from sfilter): A and
>> B.
>> A calls IoRegisterFsRegistrationChange before B does. As a result, when a
>> file system driver C calls IoRegisterFileSystem, B will be notified
>> before
>> A. Therefore, B will attach to C and A will attach to B.
>>
>> C<-B<-A
>>
>> When C calls IoUnregisterFileSystem, B will still be notified before A. B
>> will call SfDetachFromFileSystemDevice, the same as sfilter does:
>>
>> VOID SfDetachFromFileSystemDevice(IN PDEVICE_OBJECT DeviceObject)
>> {
>> PDEVICE_OBJECT ourAttachedDevice = DeviceObject->AttachedDevice;
>>
>> while (NULL != ourAttachedDevice) {
>>
>> if (IS_MY_DEVICE_OBJECT( ourAttachedDevice ))
>> {
>> IoDetachDevice( DeviceObject );
>> IoDeleteDevice( ourAttachedDevice );
>> return;
>> }
>>
>> DeviceObject = ourAttachedDevice;
>> ourAttachedDevice = ourAttachedDevice->AttachedDevice;
>> }
>> }
>>
>> The problem is, when B calls IoDetachDevice and IoDeleteDevice, it’s
>> still
>> attached by A. So when A get the notification,
>> DeviceObject->AttachedDevice
>> will be empty and A’s filter device object will never have a chance to
>> get
>> deleted.
>>
>> Is there anything wrong in my understanding?
>>
>> Thanks
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

8

> it even if they receive the NoActive file system notification. If this is

the case, the sfilter sample in 2003 IFSDDK is wrong, because it calls
IoDetachDevice in its notification routine SfFsNotification.

It detaches from control device object there, not from volume one.

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