Major functions and filtering of a device ...

NTDEV
1

Hi,

is it legit, that before I attach to a certain device, I get its pointer and
ultimately the pointer of the driver object and then I just copy its major
function pointers into my own major function array?

This is to spare some efforts when it comes to handle the IRPs of major
function codes I am not even interested in. So instead of passing them down
manually I just take the function pointers of the driver that has set up the
device and only replace the function pointers for those IRP_MJ_* codes I am
interested in. These would still have to be passed down manually, but I
spare the fuss for those I am not interested in.

Is it legit or am I not allowed to do this (“morally”)? :wink:

Cheers,

Oliver

2

You should not do this. what if the driver you are filtering has more
then one device? what if those devices are in different roles like PDOs
and FDOs? It is not hard for your driver to do an
IoSkipCurrentIrpStackLocation/IoCallDriver in the dispatch routines that
you don’t care about.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Oliver Schneider
Sent: Thursday, February 02, 2006 9:40 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Major functions and filtering of a device …

Hi,

is it legit, that before I attach to a certain device, I get its pointer
and
ultimately the pointer of the driver object and then I just copy its
major
function pointers into my own major function array?

This is to spare some efforts when it comes to handle the IRPs of major
function codes I am not even interested in. So instead of passing them
down
manually I just take the function pointers of the driver that has set up
the
device and only replace the function pointers for those IRP_MJ_* codes I
am
interested in. These would still have to be passed down manually, but I
spare the fuss for those I am not interested in.

Is it legit or am I not allowed to do this (“morally”)? :wink:

Cheers,

Oliver

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

3

Doron,

thanks. That makes sense.

Oliver

You should not do this. what if the driver you are filtering has more
then one device? what if those devices are in different roles like PDOs
and FDOs? It is not hard for your driver to do an
IoSkipCurrentIrpStackLocation/IoCallDriver in the dispatch routines that
you don't care about.

--

May the source be with you, stranger :wink:

ICQ: #281645
URL: http://assarbad.net

4

Oliver Schneider wrote:

Hi,

is it legit, that before I attach to a certain device, I get its pointer and
ultimately the pointer of the driver object and then I just copy its major
function pointers into my own major function array?

This is to spare some efforts when it comes to handle the IRPs of major
function codes I am not even interested in. So instead of passing them down
manually I just take the function pointers of the driver that has set up the
device and only replace the function pointers for those IRP_MJ_* codes I am
interested in. These would still have to be passed down manually, but I
spare the fuss for those I am not interested in.

Is it legit or am I not allowed to do this (“morally”)? :wink:

What if that driver unloads before yours?

The forwarding is so trivial to do, that it isn’t worth the trouble.
Look at toaster\filter\filter.c. It takes 3 lines of code to do a “for”
loop in your DriverEntry to set all of the entry points to a single
“passthrough” function, and that function only has to be 10 lines of code.

It would take MORE code for you to snaggle the entry points of the lower
driver.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

5

> What if that driver unloads before yours?
Why would it? I am attached to it, right? So everything just needs to be set
up before I attach and start filtering ...
Since I reference the device object (probably even the driver object) the
other one cannot just go away.

But anyhow Doron made the point quite clear already.

So thanks to both of you.

Cheers,

Oliver

--

May the source be with you, stranger :wink:

ICQ: #281645
URL: http://assarbad.net

6

An Ob reference will not prevent the filtered driver's Unload routine
from occurring or deletion of the device object, all the Ob reference
will do is ensure that the filtered driver's image remains in memory
(yes, it will remain in memory after DriverUnload if there is an
outstanding ref). What it boils down to is that an Ob reference does
not guard against a state change, it just guards against an object
completely disappearing.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Oliver Schneider
Sent: Thursday, February 02, 2006 10:30 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Major functions and filtering of a device ...

What if that driver unloads before yours?
Why would it? I am attached to it, right? So everything just needs to be
set
up before I attach and start filtering ...
Since I reference the device object (probably even the driver object)
the
other one cannot just go away.

But anyhow Doron made the point quite clear already.

So thanks to both of you.

Cheers,

Oliver

--

May the source be with you, stranger :wink:

ICQ: #281645
URL: http://assarbad.net

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

7

> What it boils down to is that an Ob reference does

not guard against a state change, it just guards against an object
completely disappearing.
Yap, but that *would* be nothing to worry about in case I used it as I
described in my question.
And if the device itself went away there wouldn't be a problem either,
because no IRPs can be targeted to it then, anymore. The IO manager would
simply not know whom to deliver the IRP.

But my question was a little silly though ...

Sorry for the silly question, should have thought more thoroughly before
asking the list,

Oliver

--

May the source be with you, stranger :wink:

ICQ: #281645
URL: http://assarbad.net