Is it wrong to depend on IO_STACK_LOCATION for DeviceObject?

NTDEV
1

Inside dispatch routine, I assume I have two ways to fetch the device
object.

  1. Pick it from the argument
  2. Pick it from ioStack->DeviceObject

I was using option two. In one of the calls I see that the device object in
argument and the one in ioStack->DeviceObject are different (I got the
ioStack using IoGetCurrentIrpStackLocation). Upon closer examination, I see
that the device object in ioStack->DeviceObject is the device object of the
driver above me and not mine. I also see that the driver above me has
directly called me and didn’t call through IofCallDriver.

I would like to know if I am doing something wrong by depending on
IO_STACK_LOCATION for device object or is the driver above me doing
something wrong by passing to me an IO_STACK_LOCATION with incorrect device
object set.

Thanks

2

Not sure that calling driver below directly is correct. IopfCallDriver normally fills next IO_STACK_LOCATION::DeviceObject with argument it takes, and calls IRP_MJ handler of the target driver accordingly to IO_STACK_LOCATION::MajorFunction. What stack is it? Which driver is above you?

3

It is TDI stack and the driver above me is a third party firewall driver
for which I don’t have source code.

On Thu, Jan 5, 2012 at 5:28 PM, wrote:

> Not sure that calling driver below directly is correct. IopfCallDriver
> normally fills next IO_STACK_LOCATION::DeviceObject with argument it takes,
> and calls IRP_MJ handler of the target driver accordingly to
> IO_STACK_LOCATION::MajorFunction. What stack is it? Which driver is above
> you?
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

4

The OS guarantees these will be the same, for all correctly implemented drivers. IoCallDriver ensures this is the case (as you seem to know from your analysis).

That’s a bug in the driver above you. A serious bug, in fact.

Clearly you could work around this by using the DEVICE_OBJECT passed in as the parameter (this is what probably 99% of drivers do)… but that driver above you is seriously broken.

Peter
OSR

5

You know what bad will happen? If you set a completion routine in your IO_STACK_LOCATION, and call a driver below you (if any), the completion routine will be called with wrong DeviceObject argument.

6

Mr. Grig is correct.

Not to mention, who KNOWS what the driver above is doing in terms of setting-up the I/O Stack or setting up the current IRP stack location pointer.

The driver above you is broken, clear and simple.

Peter
OSR

7

Maybe I can avoid completion routine getting called with wrong device
object by correcting the device object set in my stack location as the
first step before doing anything else? Ofcourse it all depends on what the
driver above is doing exactly, but I tried it and it seems to work.
However, I’ll report the issue to the developers of the driver above me.

Thanks to you and Peter for your inputs. It was very helpful.

On Thu, Jan 5, 2012 at 9:18 PM, wrote:

> You know what bad will happen? If you set a completion routine in your
> IO_STACK_LOCATION, and call a driver below you (if any), the completion
> routine will be called with wrong DeviceObject argument.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>