Re: WdfRequestUnmarkCancelable always returns STATUS_CANCELLED

Thanks Tim,

As I stated, I cannot use WDF Queues due to lookup speed limitation. The
hardware has extremely deep queues and is capable of handling up to 64K
entries at once. WdfIoQueueFindRequest does not guarantee anything
regarding lookup time.

Setting the breakpoint does not show any news. In fact, even after the
failure of WdfRequestUnmarkCancelable, the cancellation flag is still 0…

On Mon, Jan 19, 2015 at 8:49 PM, Tim Roberts wrote:

> xxxxx@gmail.com wrote:
> > In my KMDF Driver, I store all I/O WDFREQUESTs in a map, making it easy
> for me to retrieve a specific request when the H/W completes it’s
> associated command.
> > I’m trying to implement an Abort Mechanism, and I found that using the
> build in Cancellation should work.
>
> Surely it would be easier to put your requests in a manual queue, then
> use a WdfIoQueueFindRequest loop to find the matching request in your
> DPC. That way, KMDF handles all the ugliness of cancellation handling
> for you.
>
> > So, every request received by the driver is immediately set to a
> cancellation routine using WdfRequestMarkCancelableEx() , and the DPC that
> handles the H/W events call WdfRequestUnmarkCancelable().
> > However, it seems that the DPC always finds that the status of
> WdfRequestUnmarkCancelable() is STATUS_CANCELLED. The cancellation routine
> has not been called (and there should be no reason for it to be called -
> the user application is still running).
>
> Not clear why that should be the case. I suppose you could put a write
> breakpoint on the cancellation flag in the IRP to see who is writing
> that bit.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>

Run !wdfkd.wdflogdump and see if it tells you what is going on with the request

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Menachem Shapira
Sent: Monday, January 19, 2015 11:45 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] WdfRequestUnmarkCancelable always returns STATUS_CANCELLED

Thanks Tim,

As I stated, I cannot use WDF Queues due to lookup speed limitation. The hardware has extremely deep queues and is capable of handling up to 64K entries at once. WdfIoQueueFindRequest does not guarantee anything regarding lookup time.

Setting the breakpoint does not show any news. In fact, even after the failure of WdfRequestUnmarkCancelable, the cancellation flag is still 0…

On Mon, Jan 19, 2015 at 8:49 PM, Tim Roberts > wrote:
xxxxx@gmail.commailto:xxxxx wrote:
> In my KMDF Driver, I store all I/O WDFREQUESTs in a map, making it easy for me to retrieve a specific request when the H/W completes it’s associated command.
> I’m trying to implement an Abort Mechanism, and I found that using the build in Cancellation should work.

Surely it would be easier to put your requests in a manual queue, then
use a WdfIoQueueFindRequest loop to find the matching request in your
DPC. That way, KMDF handles all the ugliness of cancellation handling
for you.

> So, every request received by the driver is immediately set to a cancellation routine using WdfRequestMarkCancelableEx() , and the DPC that handles the H/W events call WdfRequestUnmarkCancelable().
> However, it seems that the DPC always finds that the status of WdfRequestUnmarkCancelable() is STATUS_CANCELLED. The cancellation routine has not been called (and there should be no reason for it to be called - the user application is still running).

Not clear why that should be the case. I suppose you could put a write
breakpoint on the cancellation flag in the IRP to see who is writing
that bit.


Tim Roberts, xxxxx@probo.commailto:xxxxx
Providenza & Boekelheide, Inc.


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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 Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers 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</mailto:xxxxx></mailto:xxxxx>

Menachem Shapira wrote:

As I stated, I cannot use WDF Queues due to lookup speed limitation.
The hardware has extremely deep queues and is capable of handling up
to 64K entries at once. WdfIoQueueFindRequest does not guarantee
anything regarding lookup time.

Balderdash. It’s traversing a linked list. Even with 1,000 entries,
the lookup is only going to take a few microseconds. You could even
create 64 manual queues and use a hashing scheme based on some inner
bits of the handle to choose a queue.

However, this doesn’t address your original mystery. If the IRP is not
canceled, then UnmarkCancelable should not return STATUS_CANCELED.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

On 19-Jan-2015 21:44, Menachem Shapira wrote:

I cannot use WDF Queues due to lookup speed limitation. The
hardware has extremely deep queues and is capable of handling up to 64K
entries at once.

/* as my former boss used to say… Bug in design - zain in debug! */

After enabling all various object tracking, i found the issue.
A previous request (uisng the same recycled IRP) was completed
successfully. However, I had not called WdfRequestUnmarkCancelable before
the completion.
So when the new request (same IRP) came in, and was ready to be completed,
the framework would not let me call WdfRequestUnmarkCancelable, do to a
previous mistake (on a different IRP!) somewhat strange behavior, but
whatever.
Thanks for everyones’ help

,

On Tue, Jan 20, 2015 at 1:02 AM, Pavel A. wrote:

> On 19-Jan-2015 21:44, Menachem Shapira wrote:
>
> I cannot use WDF Queues due to lookup speed limitation. The
>> hardware has extremely deep queues and is capable of handling up to 64K
>> entries at once.
>>
>
> /* as my former boss used to say… Bug in design - zain in debug! */
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>

On Tue, Jan 20, 2015 at 3:10 AM, Menachem Shapira
wrote:

> WdfRequestUnmarkCancela

While on the subject of WdfRequestUnmaekCancelable you need to pay close
attention to the race condition documented here:

However, the driver must not call WdfRequestUnmarkCancelable after
EvtRequestCancel
http:
calls WdfRequestComplete
http:.
In the following Example section, the example stores a local copy of the
request handle and then clears it when the EvtRequestCancel callback
function calls WdfRequestComplete. The driver does not call
WdfRequestUnmarkCancelable if the local copy of the request handle has
been cleared. This example uses the framework’s automatic synchronization
http:
to synchronize the callback functions.

Note that calling WdfObjectReference
http:
to add an additional reference to the request object does not enable your
driver to call WdfRequestUnmarkCancelable after the driver’s
EvtRequestCancel
http:
callback function calls WdfRequestComplete
http:.

http://msdn.microsoft.com/en-us/library/windows/hardware/ff550035(v=vs.85).aspx

Ultimately the solution seems to be (if you cannot use automatic
serialization) to have your own referenced context associated with the
request, that you control the validity of that records the state of the
WdfRequest itself.

Mark Roddy</http:></http:></http:></http:></http:></http:>

If you turned on wdf verifier you would have bugchecked when completing a request with a cancel routine set.

d

Bent from my phone


From: Menachem Shapiramailto:xxxxx
Sent: ?1/?20/?2015 12:10 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: Re: [ntdev] WdfRequestUnmarkCancelable always returns STATUS_CANCELLED

After enabling all various object tracking, i found the issue.
A previous request (uisng the same recycled IRP) was completed successfully. However, I had not called WdfRequestUnmarkCancelable before the completion.
So when the new request (same IRP) came in, and was ready to be completed, the framework would not let me call WdfRequestUnmarkCancelable, do to a previous mistake (on a different IRP!) somewhat strange behavior, but whatever.
Thanks for everyones’ help

,

On Tue, Jan 20, 2015 at 1:02 AM, Pavel A. > wrote:
On 19-Jan-2015 21:44, Menachem Shapira wrote:

I cannot use WDF Queues due to lookup speed limitation. The
hardware has extremely deep queues and is capable of handling up to 64K
entries at once.

/* as my former boss used to say… Bug in design - zain in debug! */


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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 Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers 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</mailto:xxxxx></mailto:xxxxx>

Thanks Mark.

Regarding the synchronization method (to solve the race condition), I was
think of syncing using a flag in the Request Object’s Context Space
http:
.
However, it may not be valid if the request has allready been completed.

So, i’m was wondering if using WdfObjectReference
http:

will keep the context alive until I dereference it, allowing me to check
the flag. Would it?

On Tue, Jan 20, 2015 at 4:31 PM, Mark Roddy wrote:

>
> On Tue, Jan 20, 2015 at 3:10 AM, Menachem Shapira
> wrote:
>
>> WdfRequestUnmarkCancela
>
>
> While on the subject of WdfRequestUnmaekCancelable you need to pay close
> attention to the race condition documented here:
>
> However, the driver must not call WdfRequestUnmarkCancelable after
> EvtRequestCancel
> http:
> calls WdfRequestComplete
> http:.
> In the following Example section, the example stores a local copy of the
> request handle and then clears it when the EvtRequestCancel callback
> function calls WdfRequestComplete. The driver does not call
> WdfRequestUnmarkCancelable if the local copy of the request handle has
> been cleared. This example uses the framework’s automatic synchronization
> http:
> to synchronize the callback functions.
>
> Note that calling WdfObjectReference
> http:
> to add an additional reference to the request object does not enable
> your driver to call WdfRequestUnmarkCancelable after the driver’s
> EvtRequestCancel
> http:
> callback function calls WdfRequestComplete
> http:.
>
>
>
> http://msdn.microsoft.com/en-us/library/windows/hardware/ff550035(v=vs.85).aspx
>
> Ultimately the solution seems to be (if you cannot use automatic
> serialization) to have your own referenced context associated with the
> request, that you control the validity of that records the state of the
> WdfRequest itself.
>
> Mark Roddy
> — NTDEV is sponsored by OSR Visit the list at:
> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> http://www.osr.com/careers 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
></http:></http:></http:></http:></http:></http:></http:></http:>

Yes, it would keep the context valid. A reference will not block state changes (for instance, completion)

d

Bent from my phone


From: Menachem Shapiramailto:xxxxx
Sent: ?1/?20/?2015 10:28 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: Re: [ntdev] WdfRequestUnmarkCancelable always returns STATUS_CANCELLED

Thanks Mark.

Regarding the synchronization method (to solve the race condition), I was think of syncing using a flag in the Request Object’s Context Spacehttp: . However, it may not be valid if the request has allready been completed.

So, i’m was wondering if using WdfObjectReferencehttp: will keep the context alive until I dereference it, allowing me to check the flag. Would it?

On Tue, Jan 20, 2015 at 4:31 PM, Mark Roddy > wrote:

On Tue, Jan 20, 2015 at 3:10 AM, Menachem Shapira > wrote:
WdfRequestUnmarkCancela

While on the subject of WdfRequestUnmaekCancelable you need to pay close attention to the race condition documented here:

However, the driver must not call WdfRequestUnmarkCancelable after EvtRequestCancelhttp: calls WdfRequestCompletehttp:. In the following Example section, the example stores a local copy of the request handle and then clears it when the EvtRequestCancel callback function calls WdfRequestComplete. The driver does not call WdfRequestUnmarkCancelable if the local copy of the request handle has been cleared. This example uses the framework’s automatic synchronizationhttp: to synchronize the callback functions.

Note that calling WdfObjectReferencehttp: to add an additional reference to the request object does not enable your driver to call WdfRequestUnmarkCancelable after the driver’s EvtRequestCancelhttp: callback function calls WdfRequestCompletehttp:.

http://msdn.microsoft.com/en-us/library/windows/hardware/ff550035(v=vs.85).aspx

Ultimately the solution seems to be (if you cannot use automatic serialization) to have your own referenced context associated with the request, that you control the validity of that records the state of the WdfRequest itself.

Mark Roddy
— NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers 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 Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers 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</http:></http:></http:></http:></http:></http:></http:></http:></mailto:xxxxx></mailto:xxxxx>

WdfObjectReference will keep the context alive even while the request
itself cannot be used in apis such as WdfRequestUnmarkCancelable. The
request object still exists, but its associate Irp is invalid. So you have
to track the state in the context.

Mark Roddy

On Tue, Jan 20, 2015 at 1:27 PM, Menachem Shapira
wrote:

> Thanks Mark.
>
> Regarding the synchronization method (to solve the race condition), I was
> think of syncing using a flag in the Request Object’s Context Space
> http: .
> However, it may not be valid if the request has allready been completed.
>
> So, i’m was wondering if using WdfObjectReference
> http:

> will keep the context alive until I dereference it, allowing me to check
> the flag. Would it?
>
>
>
> On Tue, Jan 20, 2015 at 4:31 PM, Mark Roddy wrote:
>
>>
>> On Tue, Jan 20, 2015 at 3:10 AM, Menachem Shapira
>> wrote:
>>
>>> WdfRequestUnmarkCancela
>>
>>
>> While on the subject of WdfRequestUnmaekCancelable you need to pay close
>> attention to the race condition documented here:
>>
>> However, the driver must not call WdfRequestUnmarkCancelable after
>> EvtRequestCancel
>> http:
>> calls WdfRequestComplete
>> http:.
>> In the following Example section, the example stores a local copy of the
>> request handle and then clears it when the EvtRequestCancel callback
>> function calls WdfRequestComplete. The driver does not call
>> WdfRequestUnmarkCancelable if the local copy of the request handle has
>> been cleared. This example uses the framework’s automatic synchronization
>> http:
>> to synchronize the callback functions.
>>
>> Note that calling WdfObjectReference
>> http:
>> to add an additional reference to the request object does not enable
>> your driver to call WdfRequestUnmarkCancelable after the driver’s
>> EvtRequestCancel
>> http:
>> callback function calls WdfRequestComplete
>> http:.
>>
>>
>>
>> http://msdn.microsoft.com/en-us/library/windows/hardware/ff550035(v=vs.85).aspx
>>
>> Ultimately the solution seems to be (if you cannot use automatic
>> serialization) to have your own referenced context associated with the
>> request, that you control the validity of that records the state of the
>> WdfRequest itself.
>>
>> Mark Roddy
>> — NTDEV is sponsored by OSR Visit the list at:
>> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
>> http://www.osr.com/careers 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 Visit the list at:
> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> http://www.osr.com/careers 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
></http:></http:></http:></http:></http:></http:></http:></http:>