Hi
I would like to pass an IRP that comes from user mode, let’s say an IRP_MJ_READ, down to the next lower driver, e.g. as an IRP_MJ_INTERNAL_DEVICE_CONTROL. The problem is that the lower driver(s) check the value of Irp->RequestorMode and will reject the IRP if it is UserMode. The lower drivers are the WXP 1394 driver stack in this case.
While this topic was discussed in the comp.os.ms-windows.programmer.nt.kernel-mode group in June 2001 the thread did not come to a conclusion regarding the following question:
Is it possible to set the Irp->RequestorMode value to KernelMode before I pass down the IRP with IoCallDriver and to restore it later on, in the IRP completion routine for example? Is this legal or is it a bad idea?
Thanks in advance for any contributions.
Udo Eberhardt
Thesycon GmbH, Germany
xxxxx@thesycon.de
www.thesycon.de
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>Is it possible to set the Irp->RequestorMode value to KernelMode before I pass down the
It is much better to create the second IRP. Otherwise, you will possibly corrupt the original IRP, which will BSOD in
IopCompleteRequest.
Also - 1394 stack does not use Irp->MdlAddress, it uses MDLs from IRB stack locations.
Max
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Sure, I could create another IRP and pass it down to the 1394 drivers. But, IMHO this does not make any difference from the lower drivers point of view. They got an IRP stack location that is prepared by my driver (it contains an IRB which has the MDL etc.).
The only difference is the RequestorMode value. So, one could save a lot of coding effort and run-time overhead by patching this value. Note that I plan to restore the original RequestorMode value in my completion routine, as I mentioned in the original posting.
The question is: May the patching and restoring of Irp->RequestorMode have a negative impact (BSOD for example)?
Note that the original RequestorMode will be restored *before* the IRP gets finally completed by I/O Manager. Of course, the patched IRP will also be touched by IO Manager, at least when it is passed down (IoCallDriver) and when it is completed by the lower driver (IoCompleteRequest).
Udo Eberhardt
Thesycon GmbH, Germany
xxxxx@thesycon.de
www.thesycon.de
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Tuesday, January 29, 2002 4:08 PM
To: NT Developers Interest List
Subject: [ntdev] Re: IRP RequestorMode
>Is it possible to set the Irp->RequestorMode value to KernelMode
before I pass down the
It is much better to create the second IRP. Otherwise, you will
possibly corrupt the original IRP, which will BSOD in
IopCompleteRequest.
Also - 1394 stack does not use Irp->MdlAddress, it uses MDLs from
IRB stack locations.
Max
You are currently subscribed to ntdev as: xxxxx@thesycon.de
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>Note that the original RequestorMode will be restored *before* the IRP gets finally
completed by I/O Manager.
In this situation, all is probably fine.
Max
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
This really isn’t kosher. We were doing the same thing and got bit by this
same bug when we moved one of our samples over to XP. In fact it may have
been my post on comp.os… that you saw. In the end you shouldn’t be
sending an IRP generated from a user mode request down for an Internal
IOCTL, and you shouldn’t be sending down an IRP that you received with
major type IRP_MJ_READ or whatever and converting it to major type of
IRP_MJ_INTERNAL_DEVICE_CONTROL. Creating the new IRP is the way to go.
That said, I can confirm it does indeed work to change the requestor mode,
send the IRP down, and then change the requestor mode back. I did it
without a problem. I am not sure if I tried this with DriverVerifier
however, but it probably wouldn’t know or care about this either.
–
Bill McKenzie
Software Engineer
BSquare Corporation
**Try out our driver tools free for 30-days**
www.bsquare.com/offer/download
On 01/30/02, ““Maxim S. Shatskih” ” wrote:
> >Note that the original RequestorMode will be restored before the IRP gets finally
> >completed by I/O Manager.
>
> In this situation, all is probably fine.
>
> Max
>
>
>
> —
> You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Thanks for this clarification. You are right, changing and restoring the RequestorMode works without problems. I tried it in the meantime.
However, as you say it isn’t really kosher. Maybe it will cause problems in future systems, service packs, etc. So I will implement the other way now.
PS:
If billy_driverhound is your alias name then it was your posting in comp.os… that I found.
–
Udo Eberhardt
Thesycon GmbH, Germany
xxxxx@thesycon.de
www.thesycon.de
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@bsquare.com
Sent: Thursday, January 31, 2002 2:23 AM
To: NT Developers Interest List
Subject: [ntdev] Re: IRP RequestorMode
This really isn’t kosher. We were doing the same thing and got
bit by this
same bug when we moved one of our samples over to XP. In fact it
may have
been my post on comp.os… that you saw. In the end you shouldn’t be
sending an IRP generated from a user mode request down for an Internal
IOCTL, and you shouldn’t be sending down an IRP that you received with
major type IRP_MJ_READ or whatever and converting it to major type of
IRP_MJ_INTERNAL_DEVICE_CONTROL. Creating the new IRP is the way to go.
That said, I can confirm it does indeed work to change the
requestor mode,
send the IRP down, and then change the requestor mode back. I did it
without a problem. I am not sure if I tried this with DriverVerifier
however, but it probably wouldn’t know or care about this either.
–
Bill McKenzie
Software Engineer
BSquare Corporation
**Try out our driver tools free for 30-days**
www.bsquare.com/offer/download
On 01/30/02, ““Maxim S. Shatskih” ” wrote:
> > >Note that the original RequestorMode will be restored before
> the IRP gets finally
> > >completed by I/O Manager.
> >
> > In this situation, all is probably fine.
> >
> > Max
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@thesycon.de
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntdev as: xxxxx@thesycon.de
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com