STATUS_TIMEOUT returns no error to app

Mike_Kemp · September 28, 2006, 5:19am

Hi

When I want to return a STATUS_TIMEOUT (because IoCallDriver() didn’t
complete in a reasonable time) I notice that no error is returned to the
application from DeviceIoControl(), so the app doesn’t know it failed.

What is standard practice to return an error on a timeout?

Is IoCancelIrp() a safe way to tell the underlying driver that we’ve given
up waiting so it should give up too?

Thanks, Mike

OSR_Community_User · September 28, 2006, 9:18am

STATUS_TIMEOUT is a success code. Try STATUS_IO_TIMEOUT.

If you are holding a Irp, and have sent other Irps to a lower level driver
then you must cancel those Irps when the Irp you are holding is cancelled,
or you give up waiting for them. Otherwise, when those Irps complete,
you’ll attempt to complete the original Irp, which is already gone. Yes,
IoCancelIrp() is the correct DDI to use.

Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Thursday, September 28, 2006 3:19 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] STATUS_TIMEOUT returns no error to app

Hi

When I want to return a STATUS_TIMEOUT (because IoCallDriver() didn’t
complete in a reasonable time) I notice that no error is returned to the
application from DeviceIoControl(), so the app doesn’t know it failed.

What is standard practice to return an error on a timeout?

Is IoCancelIrp() a safe way to tell the underlying driver that we’ve given
up waiting so it should give up too?

Thanks, Mike

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Mike_Kemp · September 28, 2006, 11:49am

Thanks, I was looking at that. STATUS_DEVICE_BUSY may be another candidate I
suppose if its not responding, unless this has hidden meaning. I notice this
will fail NT_SUCCESS (but will show up as an NT_WARNING rather than an
NT_ERROR)

re IoCanceIrp() I was worried that if the lower driver woke up and decided
to process the IRP just as I was cancelling it there might be a problem.

Mike

----- Original Message -----
From: Dan Kyler
To: Windows System Software Devs Interest List
Sent: Thursday, September 28, 2006 2:16 PM
Subject: RE: [ntdev] STATUS_TIMEOUT returns no error to app

STATUS_TIMEOUT is a success code. Try STATUS_IO_TIMEOUT.

If you are holding a Irp, and have sent other Irps to a lower level driver
then you must cancel those Irps when the Irp you are holding is cancelled,
or you give up waiting for them. Otherwise, when those Irps complete,
you’ll attempt to complete the original Irp, which is already gone. Yes,
IoCancelIrp() is the correct DDI to use.

Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Thursday, September 28, 2006 3:19 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] STATUS_TIMEOUT returns no error to app

Hi

When I want to return a STATUS_TIMEOUT (because IoCallDriver() didn’t
complete in a reasonable time) I notice that no error is returned to the
application from DeviceIoControl(), so the app doesn’t know it failed.

What is standard practice to return an error on a timeout?

Is IoCancelIrp() a safe way to tell the underlying driver that we’ve given
up waiting so it should give up too?

Thanks, Mike

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Mark_Roddy · September 28, 2006, 12:27pm

> re IoCanceIrp() I was worried that if the lower driver woke

up and decided to process the IRP just as I was cancelling it
there might be a problem.

Mike

You have to handle the race condition. But you have to handle it anyway for
the case where the calling application is terminating its open handle to
your driver.

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

Mike_Kemp · September 28, 2006, 1:03pm

Hi Mark - thanks for the reminder - I see chapter 5 of Walter Oney’s book
covers this - I’ll check it out again. Mike

----- Original Message -----
From: Mark Roddy
To: Windows System Software Devs Interest List
Sent: Thursday, September 28, 2006 5:24 PM
Subject: RE: [ntdev] STATUS_TIMEOUT returns no error to app

re IoCanceIrp() I was worried that if the lower driver woke
up and decided to process the IRP just as I was cancelling it
there might be a problem.

Mike

You have to handle the race condition. But you have to handle it anyway for
the case where the calling application is terminating its open handle to
your driver.

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

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · September 28, 2006, 1:55pm

IF the underlying driver has set a cancel routine on the IRP, it is that
driver’s responsibility to handle the race condition between cancellation
and completion. (KMDF makes this easy…yay!)

It is possible that the underlying driver has not set a cancel routine, in
which case the cancel call will be ineffective. In this case, you can’t
really complete the original IRP, unless you can guarantee that if and when
the child IRPs complete, you do not attempt to access (re-complete) the
original.

Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Thursday, September 28, 2006 9:49 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] STATUS_TIMEOUT returns no error to app

Thanks, I was looking at that. STATUS_DEVICE_BUSY may be another candidate I

suppose if its not responding, unless this has hidden meaning. I notice this

will fail NT_SUCCESS (but will show up as an NT_WARNING rather than an
NT_ERROR)

re IoCanceIrp() I was worried that if the lower driver woke up and decided
to process the IRP just as I was cancelling it there might be a problem.

Mike

----- Original Message -----
From: Dan Kyler
To: Windows System Software Devs Interest List
Sent: Thursday, September 28, 2006 2:16 PM
Subject: RE: [ntdev] STATUS_TIMEOUT returns no error to app

STATUS_TIMEOUT is a success code. Try STATUS_IO_TIMEOUT.

If you are holding a Irp, and have sent other Irps to a lower level driver
then you must cancel those Irps when the Irp you are holding is cancelled,
or you give up waiting for them. Otherwise, when those Irps complete,
you’ll attempt to complete the original Irp, which is already gone. Yes,
IoCancelIrp() is the correct DDI to use.

Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Thursday, September 28, 2006 3:19 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] STATUS_TIMEOUT returns no error to app

Hi

When I want to return a STATUS_TIMEOUT (because IoCallDriver() didn’t
complete in a reasonable time) I notice that no error is returned to the
application from DeviceIoControl(), so the app doesn’t know it failed.

What is standard practice to return an error on a timeout?

Is IoCancelIrp() a safe way to tell the underlying driver that we’ve given
up waiting so it should give up too?

Thanks, Mike

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · September 28, 2006, 1:58pm

Huh? As I understand the OP’s situation, it is not his driver that owns the
IRP to be cancelled. What race condition exists in his driver?

Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Thursday, September 28, 2006 10:25 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] STATUS_TIMEOUT returns no error to app

re IoCanceIrp() I was worried that if the lower driver woke
up and decided to process the IRP just as I was cancelling it
there might be a problem.

Mike

You have to handle the race condition. But you have to handle it anyway for
the case where the calling application is terminating its open handle to
your driver.

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

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · September 28, 2006, 2:13pm

Huh? As I understand the OP’s situation, it is not his driver that owns the
IRP to be cancelled. What race condition exists in his driver?

Dan.

How about the one between his calling IoCancelIrp in arbitrary thread context, and his completion routine for that same IRP in another arbitrary context?

If he’s just timed out a wait at passive level, he could be swapped, the IRP completed on another thread, and a now-invalid PIRP gets passed to IoCancelIrp (just one example).

OSR_Community_User · September 28, 2006, 2:43pm

Ah. Gotcha. I was thinking in terms of the design of my driver which may
cancel IRPs sent to a lower level driver, which doesn’t really have this
issue. I guess I was thinking there was no race condition, when in fact I
am handling the race condition.

Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bob Kjelgaard
Sent: Thursday, September 28, 2006 12:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] STATUS_TIMEOUT returns no error to app

Huh? As I understand the OP’s situation, it is not his driver that owns the
IRP to be cancelled. What race condition exists in his driver?

Dan.

How about the one between his calling IoCancelIrp in arbitrary thread
context, and his completion routine for that same IRP in another arbitrary
context?

If he’s just timed out a wait at passive level, he could be swapped, the IRP
completed on another thread, and a now-invalid PIRP gets passed to
IoCancelIrp (just one example).

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Mark_Roddy · September 28, 2006, 4:56pm

Actually I just reread the OP’s post and it seems that he wants to cancel an
IRP that he does not own and does not have a safe reference to. Specifically
I think he has called IoCallDriver on an IRP he received from above, is
waiting (probably synchronously in his dispatch routine, which is another
problem) and has timed out waiting for completion and would like to call
IoCancelIrp on the IRP he doesn’t own as he has called IoCallDriver on it
and he did not create it.

This is the ‘can I call IoCancelIrp on an IRP I did not create’ problem. I
think that the answer is ‘not safely unless he can guarantee that the IRP in
question has not been completed’.

I hate this sort of design. The originator of the IO request ought to be the
agent responsible for deciding what ‘too long to wait is’. The OP can solve
this problem by having a completion handler for the IRP and a
synchronization mechanism between his completion handler and his dispatch
routine that allows him to safely call IoCancelIrp.

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Thursday, September 28, 2006 2:43 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] STATUS_TIMEOUT returns no error to app

Ah. Gotcha. I was thinking in terms of the design of my
driver which may cancel IRPs sent to a lower level driver,
which doesn’t really have this issue. I guess I was thinking
there was no race condition, when in fact I am handling the
race condition.

Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bob Kjelgaard
Sent: Thursday, September 28, 2006 12:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] STATUS_TIMEOUT returns no error to app

Huh? As I understand the OP’s situation, it is not his
driver that owns the IRP to be cancelled. What race
condition exists in his driver?

Dan.

How about the one between his calling IoCancelIrp in
arbitrary thread context, and his completion routine for that
same IRP in another arbitrary context?

If he’s just timed out a wait at passive level, he could be
swapped, the IRP completed on another thread, and a
now-invalid PIRP gets passed to IoCancelIrp (just one example).

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

To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer

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

To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · September 28, 2006, 5:35pm

That’s not how I interpreted the original question. Perhaps I read more
into it than was there, but I assumed he was holding the IRP from above and
had created his own IRP(s) to pass down to service that request.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Thursday, September 28, 2006 2:54 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] STATUS_TIMEOUT returns no error to app

Actually I just reread the OP’s post and it seems that he wants to cancel an
IRP that he does not own and does not have a safe reference to. Specifically
I think he has called IoCallDriver on an IRP he received from above, is
waiting (probably synchronously in his dispatch routine, which is another
problem) and has timed out waiting for completion and would like to call
IoCancelIrp on the IRP he doesn’t own as he has called IoCallDriver on it
and he did not create it.

This is the ‘can I call IoCancelIrp on an IRP I did not create’ problem. I
think that the answer is ‘not safely unless he can guarantee that the IRP in
question has not been completed’.

I hate this sort of design. The originator of the IO request ought to be the
agent responsible for deciding what ‘too long to wait is’. The OP can solve
this problem by having a completion handler for the IRP and a
synchronization mechanism between his completion handler and his dispatch
routine that allows him to safely call IoCancelIrp.

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Thursday, September 28, 2006 2:43 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] STATUS_TIMEOUT returns no error to app

Ah. Gotcha. I was thinking in terms of the design of my
driver which may cancel IRPs sent to a lower level driver,
which doesn’t really have this issue. I guess I was thinking
there was no race condition, when in fact I am handling the
race condition.

Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bob Kjelgaard
Sent: Thursday, September 28, 2006 12:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] STATUS_TIMEOUT returns no error to app

Huh? As I understand the OP’s situation, it is not his
driver that owns the IRP to be cancelled. What race
condition exists in his driver?

Dan.

How about the one between his calling IoCancelIrp in
arbitrary thread context, and his completion routine for that
same IRP in another arbitrary context?

If he’s just timed out a wait at passive level, he could be
swapped, the IRP completed on another thread, and a
now-invalid PIRP gets passed to IoCancelIrp (just one example).

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

To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer

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

To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Mike_Kemp · September 29, 2006, 4:26am

Yes, I create an IRP and pass it to the lower level (1394) driver. I wait
for the completion event. Some calls also have a completion routines that
trigger the completion event, some don’t. For unknown reasons sometimes the
lower level driver seems to hang forever. So to be kind to my app I am
timing out and returning an error to the app (all my calls from the app are
synchronous). I’m trying not to get too bogged down at this point with
excessively complex cancellation as I suspect that under most conditions the
lower level driver does not hang, probably only when an earlier action
(probably mine) has upset it. However I am concerned at the asynchronous
MJ_CLEANUP or surprise removal happening during any of these actions, so it
looks like I will have to implement a safer cancellation strategy anyway.
Thanks for the useful comments, Mike (PS what’s an OP?)

----- Original Message -----
From: Dan Kyler
To: Windows System Software Devs Interest List
Sent: Thursday, September 28, 2006 10:33 PM
Subject: RE: [ntdev] STATUS_TIMEOUT returns no error to app

That’s not how I interpreted the original question. Perhaps I read more
into it than was there, but I assumed he was holding the IRP from above and
had created his own IRP(s) to pass down to service that request.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Thursday, September 28, 2006 2:54 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] STATUS_TIMEOUT returns no error to app

Actually I just reread the OP’s post and it seems that he wants to cancel an
IRP that he does not own and does not have a safe reference to. Specifically
I think he has called IoCallDriver on an IRP he received from above, is
waiting (probably synchronously in his dispatch routine, which is another
problem) and has timed out waiting for completion and would like to call
IoCancelIrp on the IRP he doesn’t own as he has called IoCallDriver on it
and he did not create it.

This is the ‘can I call IoCancelIrp on an IRP I did not create’ problem. I
think that the answer is ‘not safely unless he can guarantee that the IRP in
question has not been completed’.

I hate this sort of design. The originator of the IO request ought to be the
agent responsible for deciding what ‘too long to wait is’. The OP can solve
this problem by having a completion handler for the IRP and a
synchronization mechanism between his completion handler and his dispatch
routine that allows him to safely call IoCancelIrp.

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Thursday, September 28, 2006 2:43 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] STATUS_TIMEOUT returns no error to app

Ah. Gotcha. I was thinking in terms of the design of my
driver which may cancel IRPs sent to a lower level driver,
which doesn’t really have this issue. I guess I was thinking
there was no race condition, when in fact I am handling the
race condition.

Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bob Kjelgaard
Sent: Thursday, September 28, 2006 12:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] STATUS_TIMEOUT returns no error to app

Huh? As I understand the OP’s situation, it is not his
driver that owns the IRP to be cancelled. What race
condition exists in his driver?

Dan.

How about the one between his calling IoCancelIrp in
arbitrary thread context, and his completion routine for that
same IRP in another arbitrary context?

If he’s just timed out a wait at passive level, he could be
swapped, the IRP completed on another thread, and a
now-invalid PIRP gets passed to IoCancelIrp (just one example).

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

To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer

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

To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · September 29, 2006, 9:43am

>(PS what’s an OP?)

That would be you: the Original Poster.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Friday, September 29, 2006 2:26 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] STATUS_TIMEOUT returns no error to app

Yes, I create an IRP and pass it to the lower level (1394) driver. I wait
for the completion event. Some calls also have a completion routines that
trigger the completion event, some don’t. For unknown reasons sometimes the
lower level driver seems to hang forever. So to be kind to my app I am
timing out and returning an error to the app (all my calls from the app are
synchronous). I’m trying not to get too bogged down at this point with
excessively complex cancellation as I suspect that under most conditions the

lower level driver does not hang, probably only when an earlier action
(probably mine) has upset it. However I am concerned at the asynchronous
MJ_CLEANUP or surprise removal happening during any of these actions, so it
looks like I will have to implement a safer cancellation strategy anyway.
Thanks for the useful comments, Mike (PS what’s an OP?)

----- Original Message -----
From: Dan Kyler
To: Windows System Software Devs Interest List
Sent: Thursday, September 28, 2006 10:33 PM
Subject: RE: [ntdev] STATUS_TIMEOUT returns no error to app

That’s not how I interpreted the original question. Perhaps I read more
into it than was there, but I assumed he was holding the IRP from above and
had created his own IRP(s) to pass down to service that request.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Thursday, September 28, 2006 2:54 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] STATUS_TIMEOUT returns no error to app

Actually I just reread the OP’s post and it seems that he wants to cancel an
IRP that he does not own and does not have a safe reference to. Specifically
I think he has called IoCallDriver on an IRP he received from above, is
waiting (probably synchronously in his dispatch routine, which is another
problem) and has timed out waiting for completion and would like to call
IoCancelIrp on the IRP he doesn’t own as he has called IoCallDriver on it
and he did not create it.

This is the ‘can I call IoCancelIrp on an IRP I did not create’ problem. I
think that the answer is ‘not safely unless he can guarantee that the IRP in
question has not been completed’.

I hate this sort of design. The originator of the IO request ought to be the
agent responsible for deciding what ‘too long to wait is’. The OP can solve
this problem by having a completion handler for the IRP and a
synchronization mechanism between his completion handler and his dispatch
routine that allows him to safely call IoCancelIrp.

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Thursday, September 28, 2006 2:43 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] STATUS_TIMEOUT returns no error to app

Ah. Gotcha. I was thinking in terms of the design of my driver which
may cancel IRPs sent to a lower level driver, which doesn’t really
have this issue. I guess I was thinking there was no race condition,
when in fact I am handling the race condition.

Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bob Kjelgaard
Sent: Thursday, September 28, 2006 12:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] STATUS_TIMEOUT returns no error to app

Huh? As I understand the OP’s situation, it is not his driver that
owns the IRP to be cancelled. What race condition exists in his
driver?

Dan.

How about the one between his calling IoCancelIrp in arbitrary thread
context, and his completion routine for that same IRP in another
arbitrary context?

If he’s just timed out a wait at passive level, he could be swapped,
the IRP completed on another thread, and a now-invalid PIRP gets
passed to IoCancelIrp (just one example).

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

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

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Mike_Kemp · September 29, 2006, 10:13am

That’s a relief, I thought it might be Orful Programmer… - Mike

----- Original Message -----
From: Dan Kyler
To: Windows System Software Devs Interest List
Sent: Friday, September 29, 2006 2:41 PM
Subject: RE: [ntdev] STATUS_TIMEOUT returns no error to app

(PS what’s an OP?)