using IOCTL to cancel manual queue request?

OSR_Community_User · January 30, 2012, 6:22pm

Hello all,

My SDIO driver has a manual queue where some device reads are pending.
One or more application threads are blocked indefinitely with these
reads in a GetOverlappedResults().
I need to implement a graceful way to exit out of these reads when the
application decides to cycle power to the device. Here is what I have so
far.
The application issues a DeviceIoControl() with a certain control code.
In the driver’s EvtIoDeviceControl, retrieve all requests from the
manual queue and complete them with WdfRequestComplete(pendingRequest,
STATUS_CANCELLED);
This seems to be working, it makes GetOverlappedResults() return with
GetLastError() of ERROR_OPERATION_ABORTED.
Is this the best way? Also, how do I confirm that completing the request
with STATUS_CANCELLED caused ERROR_OPERATION_ABORTED and I am not
getting ERROR_OPERATION_ABORTED for some other reason? I could not find
any documentation on this translation.

Thanks
Rachel

Pavel_A1 · January 30, 2012, 6:29pm

You don’t have to use STATUS_CANCELLED.
Use any other error status that your app recognizes.
About the translation: read on RtlNtStatusToDosError().
– pa

On 31-Jan-2012 01:21, Michelson Rachel-CRK007 wrote:

Hello all,

My SDIO driver has a manual queue where some device reads are pending.
One or more application threads are blocked indefinitely with these
reads in a GetOverlappedResults().
I need to implement a graceful way to exit out of these reads when the
application decides to cycle power to the device. Here is what I have so
far.
The application issues a DeviceIoControl() with a certain control code.
In the driver’s EvtIoDeviceControl, retrieve all requests from the
manual queue and complete them with WdfRequestComplete(pendingRequest,
STATUS_CANCELLED);
This seems to be working, it makes GetOverlappedResults() return with
GetLastError() of ERROR_OPERATION_ABORTED.
Is this the best way? Also, how do I confirm that completing the request
with STATUS_CANCELLED caused ERROR_OPERATION_ABORTED and I am not
getting ERROR_OPERATION_ABORTED for some other reason? I could not find
any documentation on this translation.

Thanks
Rachel

Doron_Holan · January 30, 2012, 8:37pm

You could close the handle instead. Or call CancelIo(Ex). I reserve completing io requests with status_cancelled for when the sender cancels the io, not when some other event occurs.

d

debt from my phone

From: Michelson Rachel-CRK007
Sent: 1/30/2012 3:22 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] using IOCTL to cancel manual queue request?

Hello all,

My SDIO driver has a manual queue where some device reads are pending.
One or more application threads are blocked indefinitely with these
reads in a GetOverlappedResults().
I need to implement a graceful way to exit out of these reads when the
application decides to cycle power to the device. Here is what I have so
far.
The application issues a DeviceIoControl() with a certain control code.
In the driver’s EvtIoDeviceControl, retrieve all requests from the
manual queue and complete them with WdfRequestComplete(pendingRequest,
STATUS_CANCELLED);
This seems to be working, it makes GetOverlappedResults() return with
GetLastError() of ERROR_OPERATION_ABORTED.
Is this the best way? Also, how do I confirm that completing the request
with STATUS_CANCELLED caused ERROR_OPERATION_ABORTED and I am not
getting ERROR_OPERATION_ABORTED for some other reason? I could not find
any documentation on this translation.

Thanks
Rachel

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

Ken_Johnson · January 30, 2012, 9:15pm

Don?t close the handle until all requests are completed with it and all threads have arranged to be done with using the handle value, as otherwise that introduces a race where the handle value could be reused and cause the IOCTL to go to who knows where.

CancelIo(Ex) is the best way to handle this situation. Note that you must still wait for completion of all of the outstanding I/O?s before trying to close the handle after issuing a cancelation request. Otherwise you are subject to the race outlined above.

If simply checking for GetLastError returning ERROR_OPERATION_ABORTED makes you uncomfortable, set an internal flag in your program before calling CancelIo(Ex), and check it when GetOverlappedResult() returns. You may find such a flag useful for other reasons, for example to communicate to a thread that it should not try and start up a new I/O on the handle.

S (Msft)

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, January 30, 2012 5:37 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] using IOCTL to cancel manual queue request?

You could close the handle instead. Or call CancelIo(Ex). I reserve completing io requests with status_cancelled for when the sender cancels the io, not when some other event occurs.

d

debt from my phone

From: Michelson Rachel-CRK007
Sent: 1/30/2012 3:22 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] using IOCTL to cancel manual queue request?
Hello all,

My SDIO driver has a manual queue where some device reads are pending.
One or more application threads are blocked indefinitely with these
reads in a GetOverlappedResults().
I need to implement a graceful way to exit out of these reads when the
application decides to cycle power to the device. Here is what I have so
far.
The application issues a DeviceIoControl() with a certain control code.
In the driver’s EvtIoDeviceControl, retrieve all requests from the
manual queue and complete them with WdfRequestComplete(pendingRequest,
STATUS_CANCELLED);
This seems to be working, it makes GetOverlappedResults() return with
GetLastError() of ERROR_OPERATION_ABORTED.
Is this the best way? Also, how do I confirm that completing the request
with STATUS_CANCELLED caused ERROR_OPERATION_ABORTED and I am not
getting ERROR_OPERATION_ABORTED for some other reason? I could not find
any documentation on this translation.

Thanks
Rachel

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

OSR_Community_User · January 31, 2012, 1:49am

Does the I/O Manager issue cancels if the last-and-only handle is closed
by the app?

Generally, it is hard to cancel an I/O operation that has already notified
the device to do a transfer, but each device is a bit different in this
regard. However, when you get the completed IRP, even if it wasn’t
cancelable, you can still check the IRP->Cancelled flag, and if TRUE you
can feel free to complete it with STATUS_CANCELLED instead of
STATUS_SUCCESS. If you plan to have a device with unbounded response
time, it had better have a way to cancel an active I/O request.

Something I’ve wondered about, and maybe a USB expert can clarify: if I
have started an I/O on a USB device, and someone yanks the plug while that
transaction is active, and I get IRP_MJ_SURPRISE_REMOVAL, do I need to
have tracked the IRP(s) that are active so I can force them to complete,
and in that case, what is the recommended STATUS_ value?

joe

You could close the handle instead. Or call CancelIo(Ex). I reserve
completing io requests with status_cancelled for when the sender cancels
the io, not when some other event occurs.

d

debt from my phone

From: Michelson Rachel-CRK007
Sent: 1/30/2012 3:22 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] using IOCTL to cancel manual queue request?

Hello all,

My SDIO driver has a manual queue where some device reads are pending.
One or more application threads are blocked indefinitely with these
reads in a GetOverlappedResults().
I need to implement a graceful way to exit out of these reads when the
application decides to cycle power to the device. Here is what I have so
far.
The application issues a DeviceIoControl() with a certain control code.
In the driver’s EvtIoDeviceControl, retrieve all requests from the
manual queue and complete them with WdfRequestComplete(pendingRequest,
STATUS_CANCELLED);
This seems to be working, it makes GetOverlappedResults() return with
GetLastError() of ERROR_OPERATION_ABORTED.
Is this the best way? Also, how do I confirm that completing the request
with STATUS_CANCELLED caused ERROR_OPERATION_ABORTED and I am not
getting ERROR_OPERATION_ABORTED for some other reason? I could not find
any documentation on this translation.

Thanks
Rachel

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

Ken_Johnson · January 31, 2012, 11:50pm

Closing the handle while a request is in flight is bad because you have no idea how far the request in flight got. For example, if you close the handle while you are still trying to work your way through the initial call to DeviceIoControl, a new handle to a different file object could be opened with the same handle value and your IOCTL could go to some other device where it would have some completely different meaning (likely to disastrous results). Thus I don’t recommend closing the handle until you have confirmed that all outstanding I/O on the handle has quiesced.

It is worth noting that cancellation is strictly an advisory mechanism. It is best supported when a request involves a long wait until completion that the caller could not otherwise get out of.

You are not strictly *required* to complete an I/O with STATUS_CANCELLED even if you see that it was cancelled. For example, if you already completed the transfer, it’s ok to simply complete it with STATUS_SUCCESS.

S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@flounder.com
Sent: Monday, January 30, 2012 10:49 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] using IOCTL to cancel manual queue request?

Does the I/O Manager issue cancels if the last-and-only handle is closed by the app?

Generally, it is hard to cancel an I/O operation that has already notified the device to do a transfer, but each device is a bit different in this regard. However, when you get the completed IRP, even if it wasn’t cancelable, you can still check the IRP->Cancelled flag, and if TRUE you can feel free to complete it with STATUS_CANCELLED instead of STATUS_SUCCESS. If you plan to have a device with unbounded response time, it had better have a way to cancel an active I/O request.

Something I’ve wondered about, and maybe a USB expert can clarify: if I have started an I/O on a USB device, and someone yanks the plug while that transaction is active, and I get IRP_MJ_SURPRISE_REMOVAL, do I need to have tracked the IRP(s) that are active so I can force them to complete, and in that case, what is the recommended STATUS_ value?

joe

You could close the handle instead. Or call CancelIo(Ex). I reserve
completing io requests with status_cancelled for when the sender
cancels the io, not when some other event occurs.

d

debt from my phone

From: Michelson Rachel-CRK007
Sent: 1/30/2012 3:22 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] using IOCTL to cancel manual queue request?

Hello all,

My SDIO driver has a manual queue where some device reads are pending.
One or more application threads are blocked indefinitely with these
reads in a GetOverlappedResults().
I need to implement a graceful way to exit out of these reads when the
application decides to cycle power to the device. Here is what I have
so far.
The application issues a DeviceIoControl() with a certain control code.
In the driver’s EvtIoDeviceControl, retrieve all requests from the
manual queue and complete them with WdfRequestComplete(pendingRequest,
STATUS_CANCELLED);
This seems to be working, it makes GetOverlappedResults() return with
GetLastError() of ERROR_OPERATION_ABORTED.
Is this the best way? Also, how do I confirm that completing the
request with STATUS_CANCELLED caused ERROR_OPERATION_ABORTED and I am
not getting ERROR_OPERATION_ABORTED for some other reason? I could not
find any documentation on this translation.

Thanks
Rachel

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

MBond · February 1, 2012, 5:52pm

If the UM app allows the possibility of handle reuse, then there is a bug in
the app - one that correct use of synchronization will prevent. But it
should be obvious to all, that many effective designs require a call to
CloseHandle, CancelIoEx or shutdown in the shutdown path. For overlapped
IO, and especially IOCP based designs, good designs will always have
multiple IOPs in progress so that drivers can avoid unnecessary buffer
copies and queuing for received data and there is no way to shutdown that
program without cancelling IO.

“Skywing” wrote in message news:xxxxx@ntdev…

Closing the handle while a request is in flight is bad because you have no
idea how far the request in flight got. For example, if you close the
handle while you are still trying to work your way through the initial call
to DeviceIoControl, a new handle to a different file object could be opened
with the same handle value and your IOCTL could go to some other device
where it would have some completely different meaning (likely to disastrous
results). Thus I don’t recommend closing the handle until you have
confirmed that all outstanding I/O on the handle has quiesced.

It is worth noting that cancellation is strictly an advisory mechanism. It
is best supported when a request involves a long wait until completion that
the caller could not otherwise get out of.

You are not strictly *required* to complete an I/O with STATUS_CANCELLED
even if you see that it was cancelled. For example, if you already
completed the transfer, it’s ok to simply complete it with STATUS_SUCCESS.

S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@flounder.com
Sent: Monday, January 30, 2012 10:49 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] using IOCTL to cancel manual queue request?

Does the I/O Manager issue cancels if the last-and-only handle is closed by
the app?

Generally, it is hard to cancel an I/O operation that has already notified
the device to do a transfer, but each device is a bit different in this
regard. However, when you get the completed IRP, even if it wasn’t
cancelable, you can still check the IRP->Cancelled flag, and if TRUE you can
feel free to complete it with STATUS_CANCELLED instead of STATUS_SUCCESS.
If you plan to have a device with unbounded response time, it had better
have a way to cancel an active I/O request.

Something I’ve wondered about, and maybe a USB expert can clarify: if I have
started an I/O on a USB device, and someone yanks the plug while that
transaction is active, and I get IRP_MJ_SURPRISE_REMOVAL, do I need to have
tracked the IRP(s) that are active so I can force them to complete, and in
that case, what is the recommended STATUS_ value?

joe

You could close the handle instead. Or call CancelIo(Ex). I reserve
completing io requests with status_cancelled for when the sender
cancels the io, not when some other event occurs.

d

debt from my phone

From: Michelson Rachel-CRK007
Sent: 1/30/2012 3:22 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] using IOCTL to cancel manual queue request?

Hello all,

My SDIO driver has a manual queue where some device reads are pending.
One or more application threads are blocked indefinitely with these
reads in a GetOverlappedResults().
I need to implement a graceful way to exit out of these reads when the
application decides to cycle power to the device. Here is what I have
so far.
The application issues a DeviceIoControl() with a certain control code.
In the driver’s EvtIoDeviceControl, retrieve all requests from the
manual queue and complete them with WdfRequestComplete(pendingRequest,
STATUS_CANCELLED);
This seems to be working, it makes GetOverlappedResults() return with
GetLastError() of ERROR_OPERATION_ABORTED.
Is this the best way? Also, how do I confirm that completing the
request with STATUS_CANCELLED caused ERROR_OPERATION_ABORTED and I am
not getting ERROR_OPERATION_ABORTED for some other reason? I could not
find any documentation on this translation.

Thanks
Rachel

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

Ken_Johnson · February 1, 2012, 7:43pm

The app prevents the possibility of handle reuse by not closing the handle while it is trying to make a call to DeviceIoControl, ReadFile, etc. Once the app closes the handle it has no control over when a new handle will be opened with the same handle value.

S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of m
Sent: Wednesday, February 01, 2012 2:52 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] using IOCTL to cancel manual queue request?

If the UM app allows the possibility of handle reuse, then there is a bug in the app - one that correct use of synchronization will prevent. But it should be obvious to all, that many effective designs require a call to CloseHandle, CancelIoEx or shutdown in the shutdown path. For overlapped IO, and especially IOCP based designs, good designs will always have multiple IOPs in progress so that drivers can avoid unnecessary buffer copies and queuing for received data and there is no way to shutdown that program without cancelling IO.

“Skywing” wrote in message news:xxxxx@ntdev…

Closing the handle while a request is in flight is bad because you have no idea how far the request in flight got. For example, if you close the handle while you are still trying to work your way through the initial call to DeviceIoControl, a new handle to a different file object could be opened with the same handle value and your IOCTL could go to some other device where it would have some completely different meaning (likely to disastrous results). Thus I don’t recommend closing the handle until you have confirmed that all outstanding I/O on the handle has quiesced.

It is worth noting that cancellation is strictly an advisory mechanism. It is best supported when a request involves a long wait until completion that the caller could not otherwise get out of.

You are not strictly *required* to complete an I/O with STATUS_CANCELLED even if you see that it was cancelled. For example, if you already completed the transfer, it’s ok to simply complete it with STATUS_SUCCESS.

S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@flounder.com
Sent: Monday, January 30, 2012 10:49 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] using IOCTL to cancel manual queue request?

Does the I/O Manager issue cancels if the last-and-only handle is closed by the app?

Generally, it is hard to cancel an I/O operation that has already notified the device to do a transfer, but each device is a bit different in this regard. However, when you get the completed IRP, even if it wasn’t cancelable, you can still check the IRP->Cancelled flag, and if TRUE you can feel free to complete it with STATUS_CANCELLED instead of STATUS_SUCCESS.
If you plan to have a device with unbounded response time, it had better have a way to cancel an active I/O request.

Something I’ve wondered about, and maybe a USB expert can clarify: if I have started an I/O on a USB device, and someone yanks the plug while that transaction is active, and I get IRP_MJ_SURPRISE_REMOVAL, do I need to have tracked the IRP(s) that are active so I can force them to complete, and in that case, what is the recommended STATUS_ value?

joe

You could close the handle instead. Or call CancelIo(Ex). I reserve
completing io requests with status_cancelled for when the sender
cancels the io, not when some other event occurs.

d

debt from my phone

From: Michelson Rachel-CRK007
Sent: 1/30/2012 3:22 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] using IOCTL to cancel manual queue request?

Hello all,

My SDIO driver has a manual queue where some device reads are pending.
One or more application threads are blocked indefinitely with these
reads in a GetOverlappedResults().
I need to implement a graceful way to exit out of these reads when the
application decides to cycle power to the device. Here is what I have
so far.
The application issues a DeviceIoControl() with a certain control code.
In the driver’s EvtIoDeviceControl, retrieve all requests from the
manual queue and complete them with WdfRequestComplete(pendingRequest,
STATUS_CANCELLED);
This seems to be working, it makes GetOverlappedResults() return with
GetLastError() of ERROR_OPERATION_ABORTED.
Is this the best way? Also, how do I confirm that completing the
request with STATUS_CANCELLED caused ERROR_OPERATION_ABORTED and I am
not getting ERROR_OPERATION_ABORTED for some other reason? I could not
find any documentation on this translation.

Thanks
Rachel

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

Maxim_S_Shatskih · February 2, 2012, 7:14am

> Does the I/O Manager issue cancels if the last-and-only handle is closed

by the app?

I think no, it just issues CLEANUP and the driver can (and should) do cancels itself.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Mikae · February 2, 2012, 11:11am

The question is also interesting to me. Maxim, in this topic: http://online.osr.com/showthread.cfm?link=213965 Peter says (post #22) that drivers shouldn’t handle CLEANUP. You say something opposing to that. So where is the truth?

MBond · February 2, 2012, 2:56pm

And it is exactly the ‘trying to make’ part that needs sync. A handle can
only be closed by the program, and it need to ensure that once it does so,
no further calls using that handle value are possible. If it fails to, then
there is a bug in the app. What it does not need to do, is to ensure that
there is no overlapped in progress. Blocking calls are trickier, because
there is a period where the handle could be closed safely, but the first
requirement of never making a new call after a close will force a programmer
to prevent close during any call

I suspect that we are agreeing, but thinking about the problem in slightly
different ways

“Skywing” wrote in message news:xxxxx@ntdev…

The app prevents the possibility of handle reuse by not closing the handle
while it is trying to make a call to DeviceIoControl, ReadFile, etc. Once
the app closes the handle it has no control over when a new handle will be
opened with the same handle value.

S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of m
Sent: Wednesday, February 01, 2012 2:52 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] using IOCTL to cancel manual queue request?

If the UM app allows the possibility of handle reuse, then there is a bug in
the app - one that correct use of synchronization will prevent. But it
should be obvious to all, that many effective designs require a call to
CloseHandle, CancelIoEx or shutdown in the shutdown path. For overlapped
IO, and especially IOCP based designs, good designs will always have
multiple IOPs in progress so that drivers can avoid unnecessary buffer
copies and queuing for received data and there is no way to shutdown that
program without cancelling IO.

“Skywing” wrote in message news:xxxxx@ntdev…

Closing the handle while a request is in flight is bad because you have no
idea how far the request in flight got. For example, if you close the
handle while you are still trying to work your way through the initial call
to DeviceIoControl, a new handle to a different file object could be opened
with the same handle value and your IOCTL could go to some other device
where it would have some completely different meaning (likely to disastrous
results). Thus I don’t recommend closing the handle until you have
confirmed that all outstanding I/O on the handle has quiesced.

It is worth noting that cancellation is strictly an advisory mechanism. It
is best supported when a request involves a long wait until completion that
the caller could not otherwise get out of.

You are not strictly *required* to complete an I/O with STATUS_CANCELLED
even if you see that it was cancelled. For example, if you already
completed the transfer, it’s ok to simply complete it with STATUS_SUCCESS.

S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@flounder.com
Sent: Monday, January 30, 2012 10:49 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] using IOCTL to cancel manual queue request?

Does the I/O Manager issue cancels if the last-and-only handle is closed by
the app?

Generally, it is hard to cancel an I/O operation that has already notified
the device to do a transfer, but each device is a bit different in this
regard. However, when you get the completed IRP, even if it wasn’t
cancelable, you can still check the IRP->Cancelled flag, and if TRUE you can
feel free to complete it with STATUS_CANCELLED instead of STATUS_SUCCESS.
If you plan to have a device with unbounded response time, it had better
have a way to cancel an active I/O request.

Something I’ve wondered about, and maybe a USB expert can clarify: if I have
started an I/O on a USB device, and someone yanks the plug while that
transaction is active, and I get IRP_MJ_SURPRISE_REMOVAL, do I need to have
tracked the IRP(s) that are active so I can force them to complete, and in
that case, what is the recommended STATUS_ value?

joe

You could close the handle instead. Or call CancelIo(Ex). I reserve
completing io requests with status_cancelled for when the sender
cancels the io, not when some other event occurs.

d

debt from my phone

From: Michelson Rachel-CRK007
Sent: 1/30/2012 3:22 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] using IOCTL to cancel manual queue request?

Hello all,

My SDIO driver has a manual queue where some device reads are pending.
One or more application threads are blocked indefinitely with these
reads in a GetOverlappedResults().
I need to implement a graceful way to exit out of these reads when the
application decides to cycle power to the device. Here is what I have
so far.
The application issues a DeviceIoControl() with a certain control code.
In the driver’s EvtIoDeviceControl, retrieve all requests from the
manual queue and complete them with WdfRequestComplete(pendingRequest,
STATUS_CANCELLED);
This seems to be working, it makes GetOverlappedResults() return with
GetLastError() of ERROR_OPERATION_ABORTED.
Is this the best way? Also, how do I confirm that completing the
request with STATUS_CANCELLED caused ERROR_OPERATION_ABORTED and I am
not getting ERROR_OPERATION_ABORTED for some other reason? I could not
find any documentation on this translation.

Thanks
Rachel

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

Ken_Johnson · February 2, 2012, 3:12pm

How will you wait for the outstanding overlapped I/O to complete if you close the handle after it has started? Generally, overlapped I/O implies that the I/O request is holding on to a pointer somewhere that will be read from or written to during the progress of the operation. Should you close the handle while the operation is in progress, you have no way to know when the kernel-side processing for the request has finished and thus no way to know when it is safe to reuse the pointers passed in to the overlapped operation.

S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of m
Sent: Thursday, February 02, 2012 11:56 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] using IOCTL to cancel manual queue request?

And it is exactly the ‘trying to make’ part that needs sync. A handle can only be closed by the program, and it need to ensure that once it does so, no further calls using that handle value are possible. If it fails to, then there is a bug in the app. What it does not need to do, is to ensure that there is no overlapped in progress. Blocking calls are trickier, because there is a period where the handle could be closed safely, but the first requirement of never making a new call after a close will force a programmer to prevent close during any call

I suspect that we are agreeing, but thinking about the problem in slightly different ways

“Skywing” wrote in message news:xxxxx@ntdev…

The app prevents the possibility of handle reuse by not closing the handle while it is trying to make a call to DeviceIoControl, ReadFile, etc. Once the app closes the handle it has no control over when a new handle will be opened with the same handle value.

S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of m
Sent: Wednesday, February 01, 2012 2:52 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] using IOCTL to cancel manual queue request?

If the UM app allows the possibility of handle reuse, then there is a bug in the app - one that correct use of synchronization will prevent. But it should be obvious to all, that many effective designs require a call to CloseHandle, CancelIoEx or shutdown in the shutdown path. For overlapped IO, and especially IOCP based designs, good designs will always have multiple IOPs in progress so that drivers can avoid unnecessary buffer copies and queuing for received data and there is no way to shutdown that program without cancelling IO.

“Skywing” wrote in message news:xxxxx@ntdev…

Closing the handle while a request is in flight is bad because you have no idea how far the request in flight got. For example, if you close the handle while you are still trying to work your way through the initial call to DeviceIoControl, a new handle to a different file object could be opened with the same handle value and your IOCTL could go to some other device where it would have some completely different meaning (likely to disastrous results). Thus I don’t recommend closing the handle until you have confirmed that all outstanding I/O on the handle has quiesced.

It is worth noting that cancellation is strictly an advisory mechanism. It is best supported when a request involves a long wait until completion that the caller could not otherwise get out of.

You are not strictly *required* to complete an I/O with STATUS_CANCELLED even if you see that it was cancelled. For example, if you already completed the transfer, it’s ok to simply complete it with STATUS_SUCCESS.

S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@flounder.com
Sent: Monday, January 30, 2012 10:49 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] using IOCTL to cancel manual queue request?

Does the I/O Manager issue cancels if the last-and-only handle is closed by the app?

Generally, it is hard to cancel an I/O operation that has already notified the device to do a transfer, but each device is a bit different in this regard. However, when you get the completed IRP, even if it wasn’t cancelable, you can still check the IRP->Cancelled flag, and if TRUE you can feel free to complete it with STATUS_CANCELLED instead of STATUS_SUCCESS.
If you plan to have a device with unbounded response time, it had better have a way to cancel an active I/O request.

Something I’ve wondered about, and maybe a USB expert can clarify: if I have started an I/O on a USB device, and someone yanks the plug while that transaction is active, and I get IRP_MJ_SURPRISE_REMOVAL, do I need to have tracked the IRP(s) that are active so I can force them to complete, and in that case, what is the recommended STATUS_ value?

joe

You could close the handle instead. Or call CancelIo(Ex). I reserve
completing io requests with status_cancelled for when the sender
cancels the io, not when some other event occurs.

d

debt from my phone

From: Michelson Rachel-CRK007
Sent: 1/30/2012 3:22 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] using IOCTL to cancel manual queue request?

Hello all,

My SDIO driver has a manual queue where some device reads are pending.
One or more application threads are blocked indefinitely with these
reads in a GetOverlappedResults().
I need to implement a graceful way to exit out of these reads when the
application decides to cycle power to the device. Here is what I have
so far.
The application issues a DeviceIoControl() with a certain control code.
In the driver’s EvtIoDeviceControl, retrieve all requests from the
manual queue and complete them with WdfRequestComplete(pendingRequest,
STATUS_CANCELLED);
This seems to be working, it makes GetOverlappedResults() return with
GetLastError() of ERROR_OPERATION_ABORTED.
Is this the best way? Also, how do I confirm that completing the
request with STATUS_CANCELLED caused ERROR_OPERATION_ABORTED and I am
not getting ERROR_OPERATION_ABORTED for some other reason? I could not
find any documentation on this translation.

Thanks
Rachel

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

MBond · February 2, 2012, 5:52pm

Well, the OS tells you. If using an IOCP based design, you will get a
completion packet with a failure status (or success if that’s how it went)
and if using an event handle and GetOverlappedResult, the event becomes
signalled and you can read the return code from GetOverlappedResult. The
important point is that the handle that you are issuing IO on is never used
again. Other handles, like the one to your IOCP or wait object are, and the
buffers managed according to the memory management scheme you established,
but the file / socket / device handle never is. The handle reuse problem is
simply reuse of the handle value of closed handles; it does not mean that
windows has a problem with loosing pending IO. If you consider the example
of a well coded socket server, where the application will pend several
overlapped read requests as soon as the socket is opened to reduce KM memory
copies, it should seem obvious that the server cannot shutdown without
cancelling pending IO. Whether is does this by first cancelling pending IO
then closing the handle, or by closing the handle to kill everything, is an
implementation detail (do you want abortive or graceful close for clients
etc.), but empirical evidence suggests that the OS behaves correctly in
every case (I have tested it against every major version from NT4 up)

“Skywing” wrote in message news:xxxxx@ntdev…

How will you wait for the outstanding overlapped I/O to complete if you
close the handle after it has started? Generally, overlapped I/O implies
that the I/O request is holding on to a pointer somewhere that will be read
from or written to during the progress of the operation. Should you close
the handle while the operation is in progress, you have no way to know when
the kernel-side processing for the request has finished and thus no way to
know when it is safe to reuse the pointers passed in to the overlapped
operation.

S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of m
Sent: Thursday, February 02, 2012 11:56 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] using IOCTL to cancel manual queue request?

And it is exactly the ‘trying to make’ part that needs sync. A handle can
only be closed by the program, and it need to ensure that once it does so,
no further calls using that handle value are possible. If it fails to, then
there is a bug in the app. What it does not need to do, is to ensure that
there is no overlapped in progress. Blocking calls are trickier, because
there is a period where the handle could be closed safely, but the first
requirement of never making a new call after a close will force a programmer
to prevent close during any call

I suspect that we are agreeing, but thinking about the problem in slightly
different ways

“Skywing” wrote in message news:xxxxx@ntdev…

The app prevents the possibility of handle reuse by not closing the handle
while it is trying to make a call to DeviceIoControl, ReadFile, etc. Once
the app closes the handle it has no control over when a new handle will be
opened with the same handle value.

S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of m
Sent: Wednesday, February 01, 2012 2:52 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] using IOCTL to cancel manual queue request?

If the UM app allows the possibility of handle reuse, then there is a bug in
the app - one that correct use of synchronization will prevent. But it
should be obvious to all, that many effective designs require a call to
CloseHandle, CancelIoEx or shutdown in the shutdown path. For overlapped
IO, and especially IOCP based designs, good designs will always have
multiple IOPs in progress so that drivers can avoid unnecessary buffer
copies and queuing for received data and there is no way to shutdown that
program without cancelling IO.

“Skywing” wrote in message news:xxxxx@ntdev…

Closing the handle while a request is in flight is bad because you have no
idea how far the request in flight got. For example, if you close the
handle while you are still trying to work your way through the initial call
to DeviceIoControl, a new handle to a different file object could be opened
with the same handle value and your IOCTL could go to some other device
where it would have some completely different meaning (likely to disastrous
results). Thus I don’t recommend closing the handle until you have
confirmed that all outstanding I/O on the handle has quiesced.

It is worth noting that cancellation is strictly an advisory mechanism. It
is best supported when a request involves a long wait until completion that
the caller could not otherwise get out of.

You are not strictly *required* to complete an I/O with STATUS_CANCELLED
even if you see that it was cancelled. For example, if you already
completed the transfer, it’s ok to simply complete it with STATUS_SUCCESS.

S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@flounder.com
Sent: Monday, January 30, 2012 10:49 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] using IOCTL to cancel manual queue request?

Does the I/O Manager issue cancels if the last-and-only handle is closed by
the app?

Generally, it is hard to cancel an I/O operation that has already notified
the device to do a transfer, but each device is a bit different in this
regard. However, when you get the completed IRP, even if it wasn’t
cancelable, you can still check the IRP->Cancelled flag, and if TRUE you can
feel free to complete it with STATUS_CANCELLED instead of STATUS_SUCCESS.
If you plan to have a device with unbounded response time, it had better
have a way to cancel an active I/O request.

Something I’ve wondered about, and maybe a USB expert can clarify: if I have
started an I/O on a USB device, and someone yanks the plug while that
transaction is active, and I get IRP_MJ_SURPRISE_REMOVAL, do I need to have
tracked the IRP(s) that are active so I can force them to complete, and in
that case, what is the recommended STATUS_ value?

joe

You could close the handle instead. Or call CancelIo(Ex). I reserve
completing io requests with status_cancelled for when the sender
cancels the io, not when some other event occurs.

d

debt from my phone

From: Michelson Rachel-CRK007
Sent: 1/30/2012 3:22 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] using IOCTL to cancel manual queue request?

Hello all,

My SDIO driver has a manual queue where some device reads are pending.
One or more application threads are blocked indefinitely with these
reads in a GetOverlappedResults().
I need to implement a graceful way to exit out of these reads when the
application decides to cycle power to the device. Here is what I have
so far.
The application issues a DeviceIoControl() with a certain control code.
In the driver’s EvtIoDeviceControl, retrieve all requests from the
manual queue and complete them with WdfRequestComplete(pendingRequest,
STATUS_CANCELLED);
This seems to be working, it makes GetOverlappedResults() return with
GetLastError() of ERROR_OPERATION_ABORTED.
Is this the best way? Also, how do I confirm that completing the
request with STATUS_CANCELLED caused ERROR_OPERATION_ABORTED and I am
not getting ERROR_OPERATION_ABORTED for some other reason? I could not
find any documentation on this translation.

Thanks
Rachel

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

Maxim_S_Shatskih · February 3, 2012, 1:52am

> copies and queuing for received data and there is no way to shutdown that

program without cancelling IO.

Why? close the handle and wait on the IOCP will all requests will complete.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Maxim_S_Shatskih · February 3, 2012, 1:58am

I don’t know why Peter is against request cancellation on CLEANUP.

Omitting this will require the app to call cancel explicitly before closing the handle, which is a nuisance.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> The question is also interesting to me. Maxim, in this topic: http://online.osr.com/showthread.cfm?link=213965 Peter says (post #22) that drivers shouldn’t handle CLEANUP. You say something opposing to that. So where is the truth?
>

Doron_Holan · February 3, 2012, 2:03am

Kmdf will complete and purge all io in the file handle upon cleanup (and close for any io that escapes)

d

debt from my phone

From: Maxim S. Shatskih
Sent: 2/2/2012 10:58 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] using IOCTL to cancel manual queue request?

I don’t know why Peter is against request cancellation on CLEANUP.

Omitting this will require the app to call cancel explicitly before closing the handle, which is a nuisance.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> The question is also interesting to me. Maxim, in this topic: http://online.osr.com/showthread.cfm?link=213965 Peter says (post #22) that drivers shouldn’t handle CLEANUP. You say something opposing to that. So where is the truth?
>

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

MBond · February 3, 2012, 9:30am

Yes, all the requests will complete, but they will not all complete with
success. There is no way to for the other end to send data just so that you
can shutdown, and it would be ridiculous to try, so some or all of the
requests must be cancelled. Whether this is done separately before the
close (by calling CancelIo, shutdown, etc.) or in one step is an
implementation detail in UM. The point is that to kill the app, they need
to get completed with some status (complete, failed or cancelled) and you
can’t sit there waiting for them to complete on their own.

“Maxim S. Shatskih” wrote in message news:xxxxx@ntdev…

copies and queuing for received data and there is no way to shutdown that
program without cancelling IO.

Why? close the handle and wait on the IOCP will all requests will complete.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Maxim_S_Shatskih · February 5, 2012, 4:29pm

> Yes, all the requests will complete, but they will not all complete with

success.

If the service is shutting down - then who cares about success or failure of the requests?

close (by calling CancelIo, shutdown, etc.)

By calling CancelIo, shutdown() or CloseHandle

implementation detail in UM. The point is that to kill the app

I was thinking we are speaking about gentle shutdown, correct?

To support killing such apps, Windows cancels all IRPs associated with the thread when the process containing this thread is asked to die.

You do NOT need a CancelIo call to shut down the IOCP-based server, neither gentle way nor kill way.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com