Hi all,

is there a way to identify the originator of a kernel-mode initiated IRP.

Regards,
Andreas Winter.

Re: Originator of an IRP by Mark

Mark
Fri Feb 11 06:25:08 CST 2005

Andreas Winter wrote:
> Hi all,
>
> is there a way to identify the originator of a kernel-mode initiated IRP.
>
> Regards,
> Andreas Winter.
If the Thread field is non-null that is the originating thread.

--

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

Re: Originator of an IRP by Andreas

Andreas
Fri Feb 11 08:30:33 CST 2005

Where can I find information on the ETHREAD structure, and does it
include a reference to the driver object initiated the IRP?

Mark Roddy schrieb:
> Andreas Winter wrote:
>
>> Hi all,
>>
>> is there a way to identify the originator of a kernel-mode initiated IRP.
>>
>> Regards,
>> Andreas Winter.
>
> If the Thread field is non-null that is the originating thread.
>

Re: Originator of an IRP by Maxim

Maxim
Fri Feb 11 09:32:57 CST 2005

Walk the array of IO_STACK_LOCATIONs back and look at device objects in
them.

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

"Andreas Winter" <andreas_winter@sonydadc.com> wrote in message
news:uU8J6YEEFHA.1292@TK2MSFTNGP10.phx.gbl...
> Where can I find information on the ETHREAD structure, and does it
> include a reference to the driver object initiated the IRP?
>
> Mark Roddy schrieb:
> > Andreas Winter wrote:
> >
> >> Hi all,
> >>
> >> is there a way to identify the originator of a kernel-mode initiated IRP.
> >>
> >> Regards,
> >> Andreas Winter.
> >
> > If the Thread field is non-null that is the originating thread.
> >



Re: Originator of an IRP by Andreas

Andreas
Fri Feb 11 09:59:37 CST 2005

Does this mean that if a driver calls IoBuildDeviceIoControlRequest() or
IoAllocateIrp() and forwards this IRP with IoCallDriver(), that the
drivers object is always on top of the stack, and has it's own stack
location?

The documentation of IoAllocateIrp() says, the StackSize must be at
least equal to the StackSize of the next-lower driver's device object -
does this mean that the originator may also have no own stack location?

Maxim S. Shatskih schrieb:
> Walk the array of IO_STACK_LOCATIONs back and look at device objects in
> them.
>

Re: Originator of an IRP by Calvin

Calvin
Fri Feb 11 10:15:17 CST 2005

I don't have the answer for the OP but

> Walk the array of IO_STACK_LOCATIONs back and look at device objects
in
> them.

Well, you're going to get the top most device object at best. If the driver
skips stack location then you don't get it.

--
Calvin Guan Software Engineer/Radeon NT Drivers
ATI Technologies Inc. Markham ON, Canada www.ati.com



Re: Originator of an IRP by Maxim

Maxim
Fri Feb 11 14:16:41 CST 2005

No. This is only if the driver allocates an additional stack location for
DeviceObject use in its completion routine, this is not always the case.

You can, though, unwind the IRPs created by IO manager as a result of
user-mode syscalls, and trace all filters above you.

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

"Andreas Winter" <andreas_winter@sonydadc.com> wrote in message
news:%23SelrKFEFHA.3504@TK2MSFTNGP12.phx.gbl...
> Does this mean that if a driver calls IoBuildDeviceIoControlRequest() or
> IoAllocateIrp() and forwards this IRP with IoCallDriver(), that the
> drivers object is always on top of the stack, and has it's own stack
> location?
>
> The documentation of IoAllocateIrp() says, the StackSize must be at
> least equal to the StackSize of the next-lower driver's device object -
> does this mean that the originator may also have no own stack location?
>
> Maxim S. Shatskih schrieb:
> > Walk the array of IO_STACK_LOCATIONs back and look at device objects in
> > them.
> >



Re: Originator of an IRP by Peter

Peter
Fri Feb 11 15:44:12 CST 2005

surprisingly no one has asked this yet:

why would you want to do this?

-p

--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Andreas Winter" <andreas_winter@sonydadc.com> wrote in message
news:OBmNHpBEFHA.3596@TK2MSFTNGP12.phx.gbl...
> Hi all,
>
> is there a way to identify the originator of a kernel-mode initiated IRP.
>
> Regards,
> Andreas Winter.



Re: Originator of an IRP by Doron

Doron
Sat Feb 12 11:09:19 CST 2005

the kernel mode originator of the PIRP will not have a device object in the
IO_STACK_LOCATION array. As proof of this, the PDEVICE_OBJECT parameter in
your completion routine for an irp you allocate yourself is NULL.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:eWEas7EEFHA.3504@TK2MSFTNGP12.phx.gbl...
> Walk the array of IO_STACK_LOCATIONs back and look at device objects in
> them.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
> "Andreas Winter" <andreas_winter@sonydadc.com> wrote in message
> news:uU8J6YEEFHA.1292@TK2MSFTNGP10.phx.gbl...
>> Where can I find information on the ETHREAD structure, and does it
>> include a reference to the driver object initiated the IRP?
>>
>> Mark Roddy schrieb:
>> > Andreas Winter wrote:
>> >
>> >> Hi all,
>> >>
>> >> is there a way to identify the originator of a kernel-mode initiated
>> >> IRP.
>> >>
>> >> Regards,
>> >> Andreas Winter.
>> >
>> > If the Thread field is non-null that is the originating thread.
>> >
>
>



Re: Originator of an IRP by Doron

Doron
Sat Feb 12 11:10:07 CST 2005

no, there is no way to find the originator if the irp is from kernel mode.
there is a great underlying assumption that all kernel mode callers are to
be trusted completely.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Andreas Winter" <andreas_winter@sonydadc.com> wrote in message
news:%23SelrKFEFHA.3504@TK2MSFTNGP12.phx.gbl...
> Does this mean that if a driver calls IoBuildDeviceIoControlRequest() or
> IoAllocateIrp() and forwards this IRP with IoCallDriver(), that the
> drivers object is always on top of the stack, and has it's own stack
> location?
>
> The documentation of IoAllocateIrp() says, the StackSize must be at least
> equal to the StackSize of the next-lower driver's device object - does
> this mean that the originator may also have no own stack location?
>
> Maxim S. Shatskih schrieb:
>> Walk the array of IO_STACK_LOCATIONs back and look at device objects
>> in
>> them.
>>



Re: Originator of an IRP by Andreas

Andreas
Mon Feb 14 03:25:57 CST 2005

I'm still a beginner in driver programming and want to learn how things
are working in detail. This question about the originator came me when I
was analysing the driver stack and IRP flow down and up.

Generally, I think in kernel there should not be too/so much secrets or
undocumented things, because they misguide to do them anyway.

I think it is or should be an essential thing to know which user/kernel
mode modul wants me as a driver to do anything by sending me IRPs.

Andreas.

Peter Wieland [MSFT] schrieb:
> surprisingly no one has asked this yet:
>
> why would you want to do this?
>
> -p
>

Re: Originator of an IRP by Peter

Peter
Mon Feb 14 13:04:49 CST 2005

You can check the RequestorMode flag in the IRP to see the mode of the
request's initiator.

User-mode initiators will have UserMode set in this value. Kernel-mode
components can choose which mode they want set depending on the behavior
they want from the lower stack.

It is not an essential thing to know which module is asking you to do the
work - if you find that it is you should revisit your design. Drivers
shouldn't care what component is sending them I/O. They may need to know
attributes of the caller (e.g. its execution mode, whether it's a 32-bit or
64-bit process, its security context, etc...) and these are generally
documented and passed to the driver.

-p

--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Andreas Winter" <andreas_winter@sonydadc.com> wrote in message
news:ugc0xcnEFHA.392@TK2MSFTNGP14.phx.gbl...
> I'm still a beginner in driver programming and want to learn how things
> are working in detail. This question about the originator came me when I
> was analysing the driver stack and IRP flow down and up.
>
> Generally, I think in kernel there should not be too/so much secrets or
> undocumented things, because they misguide to do them anyway.
>
> I think it is or should be an essential thing to know which user/kernel
> mode modul wants me as a driver to do anything by sending me IRPs.
>
> Andreas.
>
> Peter Wieland [MSFT] schrieb:
>> surprisingly no one has asked this yet:
>>
>> why would you want to do this?
>>
>> -p
>>



Re: Originator of an IRP by Maxim

Maxim
Tue Feb 15 07:46:53 CST 2005

> Generally, I think in kernel there should not be too/so much secrets or
> undocumented things, because they misguide to do them anyway.

This is not secrets but the obvious notion of encapsulation.

The driver must not depend on what drivers are loaded above it.

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