Excluding a filter from the stack...

NTFSD
1

Hi everyone!

My FSD is having a “hard time” interoping with a 3-rd party filter
driver. And it seem that the only reasonable solution would be to
exclude that filter from my FSD’s device stack. Moving aside
“ideological” reasons can anybody find a flaw in the following
algorithm:

  1. In create dispatch of my FSD I check my DO->AttachedDevice for not
    being NULL.
  2. If it is not NULL I traverse the list of attached devices looking for
    a device that belongs to a driver with particular name.
  3. When I found that device I create a filter device attaching it to the
    same dev stack (i.e. my FSD’s stack)
  4. From this filter device I simply pass all the requests down to the
    device, which DO->AttachedDevice belongs to the “not that good” driver.

So, basically, I’m making a bypass around the “troubling” filter. The
only bad thing (that I can see) is that all other filters that were
attached after the “troubling” one are also excluded from the exec path.
Plus (of course) there could be a memory leak due to the first create
dispatch going through the filter while other IRPs are bypassing it.

Other than that, is there anything that looks suspicious? Any other ways
to exclude a particular filter device from the dev stack?

TIA,

Vladimir

2

You may patch dispatch table of the driver exluded filter device belongs to.
In your own routine check for device object and forward call to the lower DO
if needed. This proved to work.

-htfv

“Vladimir Chtchetkine” wrote in message
news:xxxxx@ntfsd…
Hi everyone!

My FSD is having a “hard time” interoping with a 3-rd party filter
driver. And it seem that the only reasonable solution would be to
exclude that filter from my FSD’s device stack. Moving aside
“ideological” reasons can anybody find a flaw in the following
algorithm:
1. In create dispatch of my FSD I check my DO->AttachedDevice for not
being NULL.
2. If it is not NULL I traverse the list of attached devices looking for
a device that belongs to a driver with particular name.
3. When I found that device I create a filter device attaching it to the
same dev stack (i.e. my FSD’s stack)
4. From this filter device I simply pass all the requests down to the
device, which DO->AttachedDevice belongs to the “not that good” driver.

So, basically, I’m making a bypass around the “troubling” filter. The
only bad thing (that I can see) is that all other filters that were
attached after the “troubling” one are also excluded from the exec path.
Plus (of course) there could be a memory leak due to the first create
dispatch going through the filter while other IRPs are bypassing it.

Other than that, is there anything that looks suspicious? Any other ways
to exclude a particular filter device from the dev stack?

TIA,

Vladimir

3

Vladimir,

As I am sure you are well aware this is a very bad idea for lots of
reasons.

The best solution would be to have the owners of the bad filter fix it.
Why don’t we talk about this privately and see if there is something we
can do to fix this besides bypassing them.

Neal Christiansen
Microsoft File System Filter Group Lead

This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Vladimir
Chtchetkine
Sent: Monday, February 02, 2004 3:26 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Excluding a filter from the stack…

Hi everyone!

My FSD is having a “hard time” interoping with a 3-rd party filter
driver. And it seem that the only reasonable solution would be to
exclude that filter from my FSD’s device stack. Moving aside
“ideological” reasons can anybody find a flaw in the following
algorithm:

  1. In create dispatch of my FSD I check my DO->AttachedDevice for not
    being NULL.
  2. If it is not NULL I traverse the list of attached devices looking for
    a device that belongs to a driver with particular name.
  3. When I found that device I create a filter device attaching it to the
    same dev stack (i.e. my FSD’s stack)
  4. From this filter device I simply pass all the requests down to the
    device, which DO->AttachedDevice belongs to the “not that good” driver.

So, basically, I’m making a bypass around the “troubling” filter. The
only bad thing (that I can see) is that all other filters that were
attached after the “troubling” one are also excluded from the exec path.
Plus (of course) there could be a memory leak due to the first create
dispatch going through the filter while other IRPs are bypassing it.

Other than that, is there anything that looks suspicious? Any other ways
to exclude a particular filter device from the dev stack?

TIA,

Vladimir

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

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

4

Neal:

Thanks for responding. The case is closed. Fortunately, it was my bug
that caused the other filter to blue screen. So, this time I got lucky
:slight_smile:

-----Original Message-----
From: Neal Christiansen [mailto:xxxxx@windows.microsoft.com]
Sent: Saturday, February 07, 2004 12:24 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Excluding a filter from the stack…

Vladimir,

As I am sure you are well aware this is a very bad idea for lots of
reasons.

The best solution would be to have the owners of the bad filter fix it.
Why don’t we talk about this privately and see if there is something we
can do to fix this besides bypassing them.

Neal Christiansen
Microsoft File System Filter Group Lead

This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Vladimir
Chtchetkine
Sent: Monday, February 02, 2004 3:26 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Excluding a filter from the stack…

Hi everyone!

My FSD is having a “hard time” interoping with a 3-rd party filter
driver. And it seem that the only reasonable solution would be to
exclude that filter from my FSD’s device stack. Moving aside
“ideological” reasons can anybody find a flaw in the following
algorithm:

  1. In create dispatch of my FSD I check my DO->AttachedDevice for not
    being NULL.
  2. If it is not NULL I traverse the list of attached devices looking for
    a device that belongs to a driver with particular name.
  3. When I found that device I create a filter device attaching it to the
    same dev stack (i.e. my FSD’s stack)
  4. From this filter device I simply pass all the requests down to the
    device, which DO->AttachedDevice belongs to the “not that good” driver.

So, basically, I’m making a bypass around the “troubling” filter. The
only bad thing (that I can see) is that all other filters that were
attached after the “troubling” one are also excluded from the exec path.
Plus (of course) there could be a memory leak due to the first create
dispatch going through the filter while other IRPs are bypassing it.

Other than that, is there anything that looks suspicious? Any other ways
to exclude a particular filter device from the dev stack?

TIA,

Vladimir

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

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
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@borland.com
To unsubscribe send a blank email to xxxxx@lists.osr.com