RE: IRP cancel/stubborn customer question - Thanks!

NTDEV
1

Thanks to all who responded…Gary Little definitely “got it:” the device I
wrote the driver for is a four-channel serial card, and the customer is
using it to capture data from 2400-baud data feeds from radar stations.

I think the main thing I learned is this: there is danger in taking the
word of the DDK or a book as gospel. There is even more danger in not
taking the DDK and books as gospel. Walter’s book did not explain why it is
proper to set the cancel routine to NULL when starting to service an IRP, so
I blindly followed his lead. At the same time, I would not be comfortable
not following his lead, since there may be some magical/undocumented reason
why things would break if I left a cancel routine in place.

The world of device drivers has become way too complex. The devil is in the
details, and if you are doing something even slightly non-standard - all the
books, seminars and Microsoft documentation may not cover what you really
need.

Thus my gratitude for the list…

-Evan

-----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

2

What is not covered in the documentation and seminars is covered by
experience — and that means using this list and the kernel mode news
groups.

In my case, the setting of an in progress cancel routine was done out of
impatience. I got tired of waiting for the machine to reboot so I could
continue my debug, which I couldn’t continue since that orphaned IRP would
let my process start but until it got completed, IO wouldn’t kick off again.
It was the first in the queue and no one was around to do what it was
waiting on any more. In actuality, the applications using my driver would
normally NOT be coming down until the system shuts down.

Ahh well … expedience is also the mother of invention.

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

-----Original Message-----
From: Evan Hillman [mailto:xxxxx@home.com]
Sent: Friday, September 21, 2001 7:10 AM
To: NT Developers Interest List
Subject: [ntdev] RE: IRP cancel/stubborn customer question - Thanks!

Thanks to all who responded…Gary Little definitely “got it:” the device I
wrote the driver for is a four-channel serial card, and the customer is
using it to capture data from 2400-baud data feeds from radar stations.

I think the main thing I learned is this: there is danger in taking the
word of the DDK or a book as gospel. There is even more danger in not
taking the DDK and books as gospel. Walter’s book did not explain why it is
proper to set the cancel routine to NULL when starting to service an IRP, so
I blindly followed his lead. At the same time, I would not be comfortable
not following his lead, since there may be some magical/undocumented reason
why things would break if I left a cancel routine in place.

The world of device drivers has become way too complex. The devil is in the
details, and if you are doing something even slightly non-standard - all the
books, seminars and Microsoft documentation may not cover what you really
need.

Thus my gratitude for the list…

-Evan

-----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