IRP cancel/stubborn customer question

NTDEV
1

Devs,

One of my customer is using a driver I wrote using the sample code provided
by Walter Oney in his “Programming the Windows Driver Model” book. I like
Walter’s libraries and I’m glad I went that route.

Walter’s code handles IRP cancels, so I did not implement my own. The
problem is that the hardware takes a long time to fill a IRPs input buffer,
and a buffer can be “active” for a long time. I think the cancel code does
kill off pending IRPs properly, but does not cause the IRP in progress to
complete, which I think is reasonable.

The problem is that the customer’s application is freeing the buffer he
passed to the driver while the driver is still filling it. This is by
definition a driver problem, since he did not write the driver, and his
application code is infallible.

Is there any way to handle this besides 1) shoot the customer to keep him
from reproducing, or 2) rewriting his application for him?

Thanks for any help…

-Evan

Evan Hillman
General Standards

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

2

Personally I like option 1. Remove him from the gene pool!!!

However, I do tend to side with him. Walter’s code sets the cancel routine
to null once it has removed an IRP from the start queue and then hangs it on
the device. The general thinking for doing that is that once the IRP has
been given to the device the IRP will be completed in very short order. Not
always the case. If an IRP is given to a device that is waiting for another
device at the other end of the line, it is possible for the local
application to terminate, and leave an orphaned IRP. Or if your receiving a
64K buffer at 60 baud, again things can go bump in the night and you have an
orphaned IRP.

I resolved that problem by setting the cancel routine to a function that
handles canceling in progress IRPs. It should do such things as telling the
device to shut up for crying out loud, and the cancel/complete and IRPs that
the device may have in progress.

Gary G. Little
Staff Engineer
Broadband Storage, Inc.
xxxxx@broadstor.com

-----Original Message-----
From: Evan Hillman [mailto:xxxxx@home.com]
Sent: Thursday, September 20, 2001 1:21 PM
To: NT Developers Interest List
Subject: [ntdev] IRP cancel/stubborn customer question

Devs,

One of my customer is using a driver I wrote using the sample code provided
by Walter Oney in his “Programming the Windows Driver Model” book. I like
Walter’s libraries and I’m glad I went that route.

Walter’s code handles IRP cancels, so I did not implement my own. The
problem is that the hardware takes a long time to fill a IRPs input buffer,
and a buffer can be “active” for a long time. I think the cancel code does
kill off pending IRPs properly, but does not cause the IRP in progress to
complete, which I think is reasonable.

The problem is that the customer’s application is freeing the buffer he
passed to the driver while the driver is still filling it. This is by
definition a driver problem, since he did not write the driver, and his
application code is infallible.

Is there any way to handle this besides 1) shoot the customer to keep him
from reproducing, or 2) rewriting his application for him?

Thanks for any help…

-Evan

Evan Hillman
General Standards

You are currently subscribed to ntdev as: xxxxx@broadstor.com
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

3

If you lock the pages before passing it on, then they won’t be freed until
your reference on them goes away.

Pete

Peter Scott
xxxxx@KernelDrivers.com
http://www.KernelDrivers.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Evan Hillman
Sent: Thursday, September 20, 2001 2:21 PM
To: NT Developers Interest List
Subject: [ntdev] IRP cancel/stubborn customer question

Devs,

One of my customer is using a driver I wrote using the sample code provided
by Walter Oney in his “Programming the Windows Driver Model” book. I like
Walter’s libraries and I’m glad I went that route.

Walter’s code handles IRP cancels, so I did not implement my own. The
problem is that the hardware takes a long time to fill a IRPs input buffer,
and a buffer can be “active” for a long time. I think the cancel code does
kill off pending IRPs properly, but does not cause the IRP in progress to
complete, which I think is reasonable.

The problem is that the customer’s application is freeing the buffer he
passed to the driver while the driver is still filling it. This is by
definition a driver problem, since he did not write the driver, and his
application code is infallible.

Is there any way to handle this besides 1) shoot the customer to keep him
from reproducing, or 2) rewriting his application for him?

Thanks for any help…

-Evan

Evan Hillman
General Standards

You are currently subscribed to ntdev as: xxxxx@home.com
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

4

Peter,

Any buffers the device may access should be locked down, but why wait for
the IRP to normally complete? Walter, Tony, and Peter follow the paradigm I
mentioned earlier, that once an IRP is given to the device it has no cancel
routine. Obviously they never had the joys of using an acoustically coupled
modem, or watching a paper tape being read by a TTY. :slight_smile:

Gary G. Little
Staff Engineer
Broadband Storage, Inc.
xxxxx@broadstor.com

-----Original Message-----
From: Pete Scott [mailto:xxxxx@home.com]
Sent: Thursday, September 20, 2001 3:22 PM
To: NT Developers Interest List
Subject: [ntdev] RE: IRP cancel/stubborn customer question

If you lock the pages before passing it on, then they won’t be freed until
your reference on them goes away.

Pete

Peter Scott
xxxxx@KernelDrivers.com
http://www.KernelDrivers.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Evan Hillman
Sent: Thursday, September 20, 2001 2:21 PM
To: NT Developers Interest List
Subject: [ntdev] IRP cancel/stubborn customer question

Devs,

One of my customer is using a driver I wrote using the sample code provided
by Walter Oney in his “Programming the Windows Driver Model” book. I like
Walter’s libraries and I’m glad I went that route.

Walter’s code handles IRP cancels, so I did not implement my own. The
problem is that the hardware takes a long time to fill a IRPs input buffer,
and a buffer can be “active” for a long time. I think the cancel code does
kill off pending IRPs properly, but does not cause the IRP in progress to
complete, which I think is reasonable.

The problem is that the customer’s application is freeing the buffer he
passed to the driver while the driver is still filling it. This is by
definition a driver problem, since he did not write the driver, and his
application code is infallible.

Is there any way to handle this besides 1) shoot the customer to keep him
from reproducing, or 2) rewriting his application for him?

Thanks for any help…

-Evan

Evan Hillman
General Standards

You are currently subscribed to ntdev as: xxxxx@home.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@broadstor.com
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

5

Ooops, loss of gray cells as one ages … I forgot to add …

From my experience, the problem could very well not be a BSOD, but an
inability to re-start the application if the device is set for exclusive
access, or to start IO if the device can only handle one request at a time.
The locked pages prevent the BSOD problem, but until the IRP completes the
device is locked out to other processes, which means that the customer can’t
start another task or start IO until that orphaned IRP completes. You can’t
even remove the process using Task Manager.

Gary G. Little
Staff Engineer
Broadband Storage, Inc.
xxxxx@broadstor.com

-----Original Message-----
From: Pete Scott [mailto:xxxxx@home.com]
Sent: Thursday, September 20, 2001 3:22 PM
To: NT Developers Interest List
Subject: [ntdev] RE: IRP cancel/stubborn customer question

If you lock the pages before passing it on, then they won’t be freed until
your reference on them goes away.

Pete

Peter Scott
xxxxx@KernelDrivers.com
http://www.KernelDrivers.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Evan Hillman
Sent: Thursday, September 20, 2001 2:21 PM
To: NT Developers Interest List
Subject: [ntdev] IRP cancel/stubborn customer question

Devs,

One of my customer is using a driver I wrote using the sample code provided
by Walter Oney in his “Programming the Windows Driver Model” book. I like
Walter’s libraries and I’m glad I went that route.

Walter’s code handles IRP cancels, so I did not implement my own. The
problem is that the hardware takes a long time to fill a IRPs input buffer,
and a buffer can be “active” for a long time. I think the cancel code does
kill off pending IRPs properly, but does not cause the IRP in progress to
complete, which I think is reasonable.

The problem is that the customer’s application is freeing the buffer he
passed to the driver while the driver is still filling it. This is by
definition a driver problem, since he did not write the driver, and his
application code is infallible.

Is there any way to handle this besides 1) shoot the customer to keep him
from reproducing, or 2) rewriting his application for him?

Thanks for any help…

-Evan

Evan Hillman
General Standards

You are currently subscribed to ntdev as: xxxxx@home.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@broadstor.com
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

6

The problem is that quite a lot of hardware has the mechanism for canceling
an in-progress IRP that is the same mechanism used to initialize the device:
soft reset. Now if your hardware is single threaded that is perhaps fine and
dandy. On the other hand, if your hardware has 30,000 requests in
progress…

For the single threaded case you should of course support in-progress
cancellation on ‘slow’ devices.

-----Original Message-----
From: Gary Little [mailto:xxxxx@Broadstor.com]
Sent: Thursday, September 20, 2001 6:41 PM
To: NT Developers Interest List
Subject: [ntdev] RE: IRP cancel/stubborn customer question

Peter,

Any buffers the device may access should be locked down, but why wait for
the IRP to normally complete? Walter, Tony, and Peter follow the paradigm I
mentioned earlier, that once an IRP is given to the device it has no cancel
routine. Obviously they never had the joys of using an acoustically coupled
modem, or watching a paper tape being read by a TTY. :slight_smile:

Gary G. Little
Staff Engineer
Broadband Storage, Inc.
xxxxx@broadstor.com

-----Original Message-----
From: Pete Scott [mailto:xxxxx@home.com]
Sent: Thursday, September 20, 2001 3:22 PM
To: NT Developers Interest List
Subject: [ntdev] RE: IRP cancel/stubborn customer question

If you lock the pages before passing it on, then they won’t be freed until
your reference on them goes away.

Pete

Peter Scott
xxxxx@KernelDrivers.com
http://www.KernelDrivers.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Evan Hillman
Sent: Thursday, September 20, 2001 2:21 PM
To: NT Developers Interest List
Subject: [ntdev] IRP cancel/stubborn customer question

Devs,

One of my customer is using a driver I wrote using the sample code provided
by Walter Oney in his “Programming the Windows Driver Model” book. I like
Walter’s libraries and I’m glad I went that route.

Walter’s code handles IRP cancels, so I did not implement my own. The
problem is that the hardware takes a long time to fill a IRPs input buffer,
and a buffer can be “active” for a long time. I think the cancel code does
kill off pending IRPs properly, but does not cause the IRP in progress to
complete, which I think is reasonable.

The problem is that the customer’s application is freeing the buffer he
passed to the driver while the driver is still filling it. This is by
definition a driver problem, since he did not write the driver, and his
application code is infallible.

Is there any way to handle this besides 1) shoot the customer to keep him
from reproducing, or 2) rewriting his application for him?

Thanks for any help…

-Evan

Evan Hillman
General Standards

You are currently subscribed to ntdev as: xxxxx@home.com To
unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@broadstor.com To
unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: xxxxx@stratus.com 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

7

> The problem is that the customer’s application is freeing the buffer he

passed to the driver while the driver is still filling it. This is by
definition a driver problem, since he did not write the driver, and his
application code is infallible.

What data transfer method is used by the driver? DO_BUFFERED_IO or
DO_DIRECT_IO?

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

8

Max,

The driver uses DO_DIRECT_IO.

The reason I was frustrated with the customer was because the driver
supports a timeout for reading and writing. I was trying to get him to set
the timeout to, say, two seconds. Then wait five seconds before killing off
the buffers.

Gary Little suggested continuing to use a cancel routine (albeit a different
one than for IRPs still on the queue) for active IRPs. I’m planning to
implement this.

Thanks,

-Evan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Sunday, September 23, 2001 6:08 AM
To: NT Developers Interest List
Subject: [ntdev] Re: IRP cancel/stubborn customer question

> The problem is that the customer’s application is freeing the buffer he
> passed to the driver while the driver is still filling it. This is by
> definition a driver problem, since he did not write the driver, and his
> application code is infallible.

What data transfer method is used by the driver? DO_BUFFERED_IO or
DO_DIRECT_IO?

Max

You are currently subscribed to ntdev as: xxxxx@home.com
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