Type3InputBuffer

NTDEV
1

Hi,
I’m experiencing some weird behavior when sending
IRP_MJ_INTERNAL_DEVICE_CONTROL Irp with NEITHER_IO,
The driver that is sending the Irp and the driver that is servicing the Irp
are both mine.
When sending the Irp I’m setting Type3InputBuffer to some buffer, and if
IoCallDriver() resturns with STATUS_PENDING, I know that he will not need
the buffer anymore and I realease it.

Releasing the buffer before the other driver completes the Irp causes a bug
check (IRQL_NOT_LESS_OR_EQUAL).
If I wait on an event until the Irp is completed and only then release the
buffer, everything is fine.

Is there something I’m missing? Why is this happening?

Thanks,
Shahar

2

Shahar Talmi wrote:

Hi,
I’m experiencing some weird behavior when sending
IRP_MJ_INTERNAL_DEVICE_CONTROL Irp with NEITHER_IO,
The driver that is sending the Irp and the driver that is servicing the Irp
are both mine.
When sending the Irp I’m setting Type3InputBuffer to some buffer, and if
IoCallDriver() resturns with STATUS_PENDING, I know that he will not need
the buffer anymore and I realease it.

Why would you do that? It’s against the rules. Not to mention that this
driver might be modified by someone else,
and he will have a hard time digging through your sources for things
like these.

Releasing the buffer before the other driver completes the Irp causes a bug
check (IRQL_NOT_LESS_OR_EQUAL).
If I wait on an event until the Irp is completed and only then release the
buffer, everything is fine.

You have to wait for the IRP to complete anyway. Free the buffer at the
same time with the IRP.

Is there something I’m missing? Why is this happening?

You should analyze the crash dump in windbg. It will show you exactly
where the buffer is accessed.

Thanks,
Shahar

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

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

–
Ignorance more frequently begets confidence than does knowledge.
— Charles Darwin

–
This message was scanned for spam and viruses by BitDefender.
For more information please visit http://linux.bitdefender.com/

3

Thanks, I already nailed that one down last night :slight_smile:
The problem was totally unrelated to Type3InputBuffer.

Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Andrei Zlate-Podani
Sent: Monday, March 21, 2005 11:27 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Type3InputBuffer

Shahar Talmi wrote:

Hi,
I’m experiencing some weird behavior when sending
IRP_MJ_INTERNAL_DEVICE_CONTROL Irp with NEITHER_IO, The driver that is
sending the Irp and the driver that is servicing the Irp are both mine.
When sending the Irp I’m setting Type3InputBuffer to some buffer, and
if
IoCallDriver() resturns with STATUS_PENDING, I know that he will not
need the buffer anymore and I realease it.

Why would you do that? It’s against the rules. Not to mention that this
driver might be modified by someone else, and he will have a hard time
digging through your sources for things like these.

Releasing the buffer before the other driver completes the Irp causes a
bug check (IRQL_NOT_LESS_OR_EQUAL).
If I wait on an event until the Irp is completed and only then release
the buffer, everything is fine.

You have to wait for the IRP to complete anyway. Free the buffer at the same
time with the IRP.

Is there something I’m missing? Why is this happening?

You should analyze the crash dump in windbg. It will show you exactly where
the buffer is accessed.

Thanks,
Shahar

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

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

–
Ignorance more frequently begets confidence than does knowledge.
— Charles Darwin

–
This message was scanned for spam and viruses by BitDefender.
For more information please visit http://linux.bitdefender.com/

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

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

4

Shahar Talmi wrote:

Hi,
I’m experiencing some weird behavior when sending
IRP_MJ_INTERNAL_DEVICE_CONTROL Irp with NEITHER_IO,

The I/O type (direct, neither, etc.) is irrelevant in an
IRP_MJ_INTERNAL_DEVICE_CONTROL. It has meaning only for a
IRP_MJ_DEVICE_CONTROL from user mode.

The driver that is sending the Irp and the driver that is servicing the Irp
are both mine.
When sending the Irp I’m setting Type3InputBuffer to some buffer, and if
IoCallDriver() resturns with STATUS_PENDING, I know that he will not need
the buffer anymore and I realease it.

How do you know that? Typically, when you get STATUS_PENDING, it means
that there WILL be action taken at a later time. When your lower-level
driver pends the IRP, what is it going to do when it finally takes
action? Are you sure it no longer needs to access the buffer?

Releasing the buffer before the other driver completes the Irp causes a bug
check (IRQL_NOT_LESS_OR_EQUAL).

Where does the error occur? Is it in the lower-level driver? That
suggests it IS touching the buffer after it pends it. Is it in one of
the heap routines? Is it possible you’re freeing the buffer twice?

If I wait on an event until the Irp is completed and only then release the
buffer, everything is fine.

Is there something I’m missing? Why is this happening?

You have to handle the IRP completion in the upper driver anyway, since
you have to stop the IRP completion process by returning
STATUS_MORE_PROCESSING_REQUIRED. You can’t allow the IRP to complete
beyond your driver, since you created the IRP. You might as well just
free the buffer there.

–

5

> The I/O type (direct, neither, etc.) is irrelevant in an

IRP_MJ_INTERNAL_DEVICE_CONTROL. It has meaning only for a
IRP_MJ_DEVICE_CONTROL from user mode.

That is only true in very very rare cases. When you call
IoBuildDeviceIoControlRequest, it takes the io type into consideration
when formatting the request. For your statement to be true, the irp
must be hand formatting by the caller and then, and only then, would the
recipient be able get a irp where the i/o type does not follow the std
formatting practices.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Monday, March 21, 2005 10:11 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Type3InputBuffer

Shahar Talmi wrote:

Hi,
I’m experiencing some weird behavior when sending
IRP_MJ_INTERNAL_DEVICE_CONTROL Irp with NEITHER_IO,

The I/O type (direct, neither, etc.) is irrelevant in an
IRP_MJ_INTERNAL_DEVICE_CONTROL. It has meaning only for a
IRP_MJ_DEVICE_CONTROL from user mode.

The driver that is sending the Irp and the driver that is servicing the
Irp
are both mine.
When sending the Irp I’m setting Type3InputBuffer to some buffer, and
if
IoCallDriver() resturns with STATUS_PENDING, I know that he will not
need
the buffer anymore and I realease it.

How do you know that? Typically, when you get STATUS_PENDING, it means
that there WILL be action taken at a later time. When your lower-level
driver pends the IRP, what is it going to do when it finally takes
action? Are you sure it no longer needs to access the buffer?

Releasing the buffer before the other driver completes the Irp causes a
bug
check (IRQL_NOT_LESS_OR_EQUAL).

Where does the error occur? Is it in the lower-level driver? That
suggests it IS touching the buffer after it pends it. Is it in one of
the heap routines? Is it possible you’re freeing the buffer twice?

If I wait on an event until the Irp is completed and only then release
the
buffer, everything is fine.

Is there something I’m missing? Why is this happening?

You have to handle the IRP completion in the upper driver anyway, since
you have to stop the IRP completion process by returning
STATUS_MORE_PROCESSING_REQUIRED. You can’t allow the IRP to complete
beyond your driver, since you created the IRP. You might as well just
free the buffer there.

–

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

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