Re: [ntdev] WdfRequestUnmarkCancelable results in BSOD

Cancel surely can fail; no? The UM API CancelIO(Ex) is certainly documented to be able to fail and anyway it provides no guarantee that the irp completes any faster

Sent from Surface Pro

From: Mark Roddy
Sent: ‎Tuesday‎, ‎February‎ ‎17‎, ‎2015 ‎3‎:‎09‎ ‎PM
To: Windows System Software Devs Interest List

On Tue, Feb 17, 2015 at 2:08 PM, wrote:

Well, no. There’s no “only way”… MY personal favorite way is to put pending Requests on a WDFQueue while they’re in progress. That pretty much eliminates the race problems. At least for me.

That works if you can always cancel a request, otherwise you are back to self managing the race condition.

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

As you say, it is up to the owner to 'notice’ a cancel and do something about it. By cancel fail I include the possibility that no such notice is taken. Either because the state of IRP processing is such that a cancel is impossible or because the owner never checks

Both API and DDI are documented with no guarantee that the driver will actually honour a cancel request.

Sent from Surface Pro

From: Tim Roberts
Sent: ‎Wednesday‎, ‎February‎ ‎18‎, ‎2015 ‎12‎:‎28‎ ‎AM
To: Windows System Software Devs Interest List

Marion Bond wrote:

Cancel surely can fail; no?

From kernel mode, no it can’t. IoCancelIrp always succeeds. But the
“cancel operation” in that case is merely the setting of a single bit
and the calling of a callback. It does nothing else. It’s up to the
current owner to notice the bit and take some action, but that’s
completely separate from the “cancel” request.

The UM API CancelIO(Ex) is certainly documented to be able to fail and
anyway it provides no guarantee that the irp completes any faster

That can fail because of a bad handle, for example.


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



Adding a context to the request and doing the accounting in that context seems to be the simplest and most correct way to do this.

It does - anytime such accounting is needed