Problem in calling cancel routine that is marked wdfrequest using WdfRequestMarkCancelableEx

Hi,
Current driver(usb emulated driver), creating child device which will be loading usbserial driver, on top application will be communicating.
current driver recieved bulkin request from usbser.sys, current driver holding the wdfrequest and marked using WdfRequestMarkCancelableEx.
current driver holds the request in indefinetly(while loop runs with 2mS timeout) until it recieves data from device due to some issues device not sending data.
OS triggered power irp to usbser.sys, which inturn it tried to stop its already posted requests.
wdf framwork cancelled using its cancelrepeater.
current driver cancel routine is not called and still its present in current driver.
which lead to BSOD power irp holding usbser for too long, ideally bulk in request is pending in current driver which ever usbser pospted previously.

usbser call stack to cancel its previously posted requests:
[0x5] Wdf01000!_FX_DRIVER_GLOBALS::WaitForSignal + 0x5f
[0x6] Wdf01000!FxUsbPipeContinuousReader::CancelRepeaters + 0x76
[0x7] Wdf01000!FxUsbPipe::WaitForSentIoToComplete + 0xf0
[0x8] Wdf01000!FxIoTarget::Stop + 0x61
[0x9] Wdf01000!imp_WdfIoTargetStop + 0x62
[0xa] usbser!UsbSerStopUSBRead + 0xdb
[0xb] usbser!UsbSerEvtDeviceD0Exit + 0x82
[0xc] Wdf01000!FxPnpDeviceD0Exit::InvokeClient + 0x2f

current driver that hold wdf request which usbser tried to cancel:
[0x3] nt!KeWaitForSingleObject + 0x233
[0x4] current!current_timeout + 0x7b
[0x5] current!current_read + 0x11d
[0x6] current!current_read + 0x3ad
[0x7] current!current_read_cb + 0x52
[0x8] current!currentBulkInRequestHandler + 0x60
[0x9] current!currentEvtBulkInRequest + 0x3a0
[0xa] Wdf01000!VfEvtIoInternalDeviceControl + 0x154

How can i verify the cancel wdf framwork initiated called current driver cancel routine? or why it is not called?
raw format of irp shows cancel routine is NULL, cancel bit is set to 1.
WdfRequestMarkCancelableEx will set irp cancel routine or wdf request structure variable ?
from windbg cmds it is confirmed cancelrepeater tried to cancel IRP and wdf request associated irp with current driver is same.
there is no driver logs for us to extract to see what exactly happening.

0: kd> dx -id 0,0,ffffa982eae9e180 -r1 ((Wdf01000!_IRP )0xffffa982ff4e1560)
((Wdf01000!_IRP )0xffffa982ff4e1560) : 0xffffa982ff4e1560 [Type: _IRP ]
[] [Type: _IRP]
IoStack : Size = 14, Current IRP_MJ_INTERNAL_DEVICE_CONTROL / 0x0 for Device for “\Driver\UDE”
0: kd> dx -id 0,0,ffffa982eae9e180 -r1 -nv (
((Wdf01000!_IRP )0xffffa982ff4e1560))
(
((Wdf01000!_IRP )0xffffa982ff4e1560)) [Type: _IRP]
[+0x000] Type : 6 [Type: short]
[+0x002] Size : 0x508 [Type: unsigned short]
[+0x008] MdlAddress : 0x0 [Type: _MDL ]
[+0x010] Flags : 0x0 [Type: unsigned long]
[+0x018] AssociatedIrp [Type: _IRP::]
[+0x020] ThreadListEntry [Type: _LIST_ENTRY]
[+0x030] IoStatus [Type: _IO_STATUS_BLOCK]
[+0x040] RequestorMode : 0 [Type: char]
[+0x041] PendingReturned : 0x0 [Type: unsigned char]
[+0x042] StackCount : 14 [Type: char]
** [+0x043] CurrentLocation : 10 ‘\n’ [Type: char]

** [+0x044] Cancel : 0x1 [Type: unsigned char]

[+0x045] CancelIrql : 0x0 [Type: unsigned char]
[+0x046] ApcEnvironment : 0 [Type: char]
[+0x047] AllocationFlags : 0x44 [Type: unsigned char]
[+0x048] UserIosb : 0x0 [Type: _IO_STATUS_BLOCK *]
[+0x050] UserEvent : 0x0 [Type: _KEVENT ]
[+0x058] Overlay [Type: _IRP::]
** [+0x068] CancelRoutine : 0x0 : 0x0 [Type: void (__cdecl
)(_DEVICE_OBJECT ,_IRP )]
[+0x070] UserBuffer : 0x0 [Type: void *]
[+0x078] Tail [Type: _IRP::]

I’m not sure I understand your issue. However, I can tell you that “cancel repeaters” is the routine that cancels the Requests that the Framework internally sends to the USB Host Controller Driver as part of supporting “Continuous Readers” – So, if there’s a separate Request that you have in progress, that’s not going to be affected by this particular callback.

Your description is more than a little confusing: The Request that you expect to be cancelled… is this waiting on data from your Continuous Reader or from something else?

You said “there is no driver logs for us to extract” – this means that you have exactly one instance of this problem, and you can’t reproduce it? If that’s the case, I would suggest that there’s very close to zero percent chance that you can fix this.

Peter

Thanks peter for your reply, the current driver I am talking is nothing but udecx based virtual USB host controller which emulates USB interface, which loads usbserial as child driver. stack from cancelrepeater I tried to extract m_readers structure current array index irp address matches with usb emulated driver holding wdfrequest associated irp, this wdfrequest is associated with canncel routine. kindly check below two stacks one cancel repeater trying to cancel and other is udecx based driver holding wdf request. my concern, from below two stack extraction of structures RequestIRP is mactching from m_readers structure that cancelrepeater is trying to cancel to the udecx based driver holding wdfrequest IRP. udecx based driver assigned cancel routine why it not able call? Request is waiting to get data from the device, once data is availble Bulk IN wdf request is completed. we can reproduce the issue exact scenario not defined, mostly when logs disabled issue happening thats the reason unable to extract. some random time. **cancel repeater extraction:** 0: kd> .frame 0n6;dv /t /v 06 ffffa70599a3edf0 fffff8031840df70 Wdf01000!FxUsbPipeContinuousReader::CancelRepeaters+0x76 [minkernel\wdf\framework\shared\targets\usb\fxusbpipe.cpp @ 778] @rbx struct FxUsbPipeContinuousReader * this = 0xffffa982f5ddee20 @edi long i = 0n0 0: kd\> dx -id 0,0,ffffa982eae9e180 -r1 ((Wdf01000!FxUsbPipeContinuousReader *)0xffffa982f5ddee20) ((Wdf01000!FxUsbPipeContinuousReader *)0xffffa982f5ddee20) : 0xffffa982f5ddee20 [Type: FxUsbPipeContinuousReader *] [+0x000] m_ReadCompleteCallback : 0xfffff8032e7563d0 : usbser!UsbSerEvtReadPipeComplete+0x0 [Type: void (__cdecl*)(WDFUSBPIPE__ *,WDFMEMORY __*,unsigned__ int64,void *)] [+0x008] m_ReadCompleteContext : 0xffffa982ff4e2860 [Type: void *] [+0x010] m_ReadersFailedCallback : 0x0 : 0x0 [Type: unsigned char (__cdecl*)(WDFUSBPIPE__ *,long,long)] [+0x018] m_Pipe : 0xffffa982ff8d1810 [Type: FxUsbPipe *] [+0x020] m_Lookaside : 0xffffa982fc2113c0 [Type: FxLookasideList *] [+0x028] m_TargetDevice : 0xffffa982ffced810 : Device for "\Driver\usbccgp" [Type: _DEVICE_OBJECT *] [+0x030] m_Offsets [Type: _WDFMEMORY_OFFSET] [+0x040] m_WorkItem : 0xffffa982f5dde820 [Type: FxSystemWorkItem *] [+0x048] m_WorkItemRerunContext : 0x0 [Type: void *] [+0x050] m_WorkItemThread : 0x0 [Type: _KTHREAD *] [+0x058] m_WorkItemFlags : 0x0 [Type: unsigned long] [+0x05c] m_NumFailedReaders : 0x0 [Type: unsigned char] [+0x05d] m_NumReaders : 0x1 [Type: unsigned char] [+0x05e] m_WorkItemQueued : 0x0 [Type: unsigned char] [+0x05f] m_ReadersSubmitted : 0x0 [Type: unsigned char] [+0x060] m_Readers [Type: FxUsbPipeRepeatReader [1]] 0: kd\> dx -id 0,0,ffffa982eae9e180 -r1 (*((Wdf01000!FxUsbPipeRepeatReader (*)[1])0xffffa982f5ddee80)) (*((Wdf01000!FxUsbPipeRepeatReader (*)[1])0xffffa982f5ddee80)) [Type: FxUsbPipeRepeatReader [1]] [0] [Type: FxUsbPipeRepeatReader] 0: kd\> dx -id 0,0,ffffa982eae9e180 -r1 (*((Wdf01000!FxUsbPipeRepeatReader *)0xffffa982f5ddee80)) (*((Wdf01000!FxUsbPipeRepeatReader *)0xffffa982f5ddee80)) [Type: FxUsbPipeRepeatReader] [+0x000] Request : 0xffffa982f6591560 [Type: FxRequest *] [+0x008] RequestIrp : **0xffffa982ff4e1560** [Type: _IRP *] [+0x010] Parent : 0xffffa982f5ddee20 [Type: FxUsbPipeContinuousReader *] [+0x018] Dpc [Type: _KDPC] [+0x058] ReadCompletedEvent [Type: MxEvent] **current driver(udecx based driver) stack holding request:** 0: kd\> .frame 0n6;dv /t /v 06 ffffa7059a476d30 fffff8032e1b2d12 current!read+0x3ad @r14 struct WDFREQUEST__ * Request = 0x0000567d02d5c228 0: kd> !wdfkd.wdfrequest 0x0000567d`02d5c228 Treating handle as a KMDF handle! **!irp 0xffffa982ff4e1560** !wdfqueue 0x0000567cfff0afd8 State: Pending, Allocated by WDF for incoming IRP System Buffer 0xffffa982f5ddeca0, Length 0x0, !wdfmemory 0x0000567d02d5c151 Cancel Routine: current!cancel(fffff8032e1b2470)

my issue looks similar to https://community.osr.com/discussion/254373/wdfiotargetstop-cant-return.

So… your issue is the Request from the emulated child driver’s continuous reader isn’t getting cancelled when it gets down to your UDECx Client? You’re not seeing the cancel routine getting called, even though you’ve call WdfRequestMarkCancelableEx?

Do you check the return status to see if the Request is cancelled when you call WdfRequestMarkCancelableEx?

You’ve run this under WDF Verifier?

You see nothing from !wdflogdump? I find that hard to believe.

Peter

Irp->Cancel is true so the irp was canceled. One thing you can also do is break into a normally running system and validate all of the state is as you expect, there are no intermediate irps created between the continuous reader and your driver, the cancel routine is set, etc. The snippet of how you handle a read is a little suspect. It looks like you are handling it synchronously and handling timeout (and cancelation?) via a wait. While simple, it makes it difficult to handle out of the ordinary stage changes and you might be better served by moving to a completely async handling of the read.

@“Peter_Viscarola_(OSR)” yes correct from understanding, WdfRequestMarkCancelableEx yes under check it is there.

!wdflogdump our driverc → mostly seeing power related some transition, below is the IRP match for wdfrequest and cancelrepeater RequestedIrp

83: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x0000247D05F34338 !devobj 0xFFFFDB8303045AB0 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpEnableInterfaces
84: FxPkgPnp::Dispatch - WDFDEVICE 0x0000247D05F34338 !devobj 0xFFFFDB8303045AB0, IRP_MJ_PNP, 0x00000014(IRP_MN_QUERY_PNP_DEVICE_STATE) IRP 0xFFFFDB8300E1BA60
85: FxPkgPdo::_PnpQueryPnpDeviceState - WDFDEVICE 0x0000247D05F34338 !devobj 0xFFFFDB8303045AB0 returning PNP_DEVICE_STATE 0x0 IRP 0xFFFFDB8300E1BA60
86: FxPkgPnp::Dispatch - WDFDEVICE 0x0000247D05F34338 !devobj 0xFFFFDB8303045AB0, IRP_MJ_PNP, 0x00000007(IRP_MN_QUERY_DEVICE_RELATIONS) type BusRelations IRP 0xFFFFDB8300E1BA60
87: FxPkgPnp::Dispatch - WDFDEVICE 0x0000247D05B6C588 !devobj 0xFFFFDB82FAEA8A70, IRP_MJ_PNP, 0x00000007(IRP_MN_QUERY_DEVICE_RELATIONS) type BusRelations IRP 0xFFFFDB8303DBFDE0
88: FxPkgPnp::HandleQueryBusRelations - WDFDEVICE 0000247D05B6C588 returning 1 devices in relations FFFF960BEC277450

@Doron_Holan thanks for reply, does WdfRequestMarkCancelableEx will set cancel routine in irp->cancelroutine ? as soon as bulk request is recived in udecx client via ioctl, implementation is like that synchronously waiting with timeout but running in while loop, either some data received from device or wdfrequest is cancelled.

does WdfRequestMarkCancelableEx will set cancel routine in irp->cancelroutine ?

The answer to this question seems obvious. Other than some validation, that’s ALL this function does.

Sources: https://github.com/microsoft/Windows-Driver-Frameworks/blob/main/src/framework/shared/core/fxrequestapi.cpp#L3468

Peter

2 Likes

@“Peter_Viscarola_(OSR)” and @Doron_Holan thanks for reference, I have already mapped source with memory.dmp. During WdfRequestMarkCancelableEx once it is success I called WdfRequestWdmGetIrp and verified the Irp->cancelroutine is also set.

        irp = WdfRequestWdmGetIrp(Request);
        if (irp)
        {
            TraceEvents(TRACE_LEVEL_INFO, 
                        "WdfRequest: %p IRP CancelRoutine: %p IRP cancel:%d",
                        Request, (void*)irp->CancelRoutine, irp->Cancel);

            ReqCtx->irp = irp;
        }

but from our stack which tell wdf request is pending irp is matching but irp cancel routine is null and irp->cancel set to true but still pending with our driver, I got logs before BSOD, from the logs it is observed that almost ~4 minutes we are holding this wdfrequest by marking cancel.

how can i make use of queue configs EvtIoStop?

Irp->Cancel = TRUE and CancelRoutine=NULL means the cancel routine was invoked. If I were to guess, WDF processed the underlying cancel request, invoked your WDF request cancel routine and your driver lost the state/didn’t handle the cancel properly (perhaps because you don’t have sufficient locking around setting and checking the state of the request). You need to properly handle cancelation independent of the queue stopping, so you need to fix the cancelation processing logic. If it were me reviewing your code, first think I would insist on is moving away from synchronous processing of sending IO and move everything to async and create the propert state machine to handle the transitions without blocking. EvtIoStop is related to cancelation in that you need to track a request’s state and potentially cancel underlying requests/wait for completion, so you may be able to reuse logic, but EvtIoStop and cancelation are two different functional areas you need to implement that are not strongly tied together.

Irp->Cancel = TRUE and CancelRoutine=NULL means the cancel routine was invoked

OR that no cancel routine was ever set in the IRP.

how can i make use of queue configs EvtIoStop

https://www.osr.com/nt-insider/2014-issue2/understanding-evtiostop-bugcheck-9f-related-sdv-errors/

Peter

Thanks Peter and Doron, I will check and let you know

@“Peter_Viscarola_(OSR)” cancel routine is set for wdfrequest. Issue been reprodcued once again. cancel routine debug print not came is logs. assuming cancel routine is not invoked. In this case can WdfRequestIsCanceled be called on request and complete with status_cancelled ?

Cancel routine associated with WDF request:

4: kd> !wdfkd.wdfrequest 000042FE9FF23228
Treating handle as a KMDF handle!
    !irp **0xffffbd01614e2010**

!wdfqueue 0x000042feaf6a0908
   State:  Pending, Allocated by WDF for incoming IRP
   System Buffer 0xffffbd01748bcfa0, Length 0x0, !wdfmemory 0x000042fe9ff23151

   Cancel Routine: **cancel_read**(fffff8000e4b2480)

Dumping WDFQUEUE 0x000042feaf6a0908:

Sequential, Power-managed, PowerOn, Can accept, Can dispatch, Dispatching, ExecutionLevelDispatch, SynchronizationScopeNone
    Number of driver owned requests: 1
    !wdfrequest 0x000042fe9ff23228  !irp **0xffffbd01614e2010**
    Number of waiting requests: 0

    Number of driver owned **cancelled **requests: 1
    !wdfrequest 0x000042fe9ff23228  !irp **0xffffbd01614e2010**

    EvtIoInternalDeviceControl: (0xfffff8000e4a2c90) EvtBulkInRequest
    EvtIoStop: (0xfffff8000e4a3130) EvtBulkInRequestStop

IRP Dump:

4: kd> dx -r1 -nv (*((Wdf01000!_IRP *)**0xffffbd01614e2010**))
(*((Wdf01000!_IRP *)0xffffbd01614e2010))                 [Type: _IRP]
    [+0x000] Type             : 6 [Type: short]
    [+0x002] Size             : 0x508 [Type: unsigned short]
    [+0x008] MdlAddress       : 0x0 [Type: _MDL *]
    [+0x010] Flags            : 0x0 [Type: unsigned long]
    [+0x018] AssociatedIrp    [Type: _IRP::<unnamed-type-AssociatedIrp>]
    [+0x020] ThreadListEntry  [Type: _LIST_ENTRY]
    [+0x030] IoStatus         [Type: _IO_STATUS_BLOCK]
    [+0x040] RequestorMode    : 0 [Type: char]
    [+0x041] PendingReturned  : 0x0 [Type: unsigned char]
    [+0x042] StackCount       : 14 [Type: char]
    [+0x043] CurrentLocation  : 10 '\n' [Type: char]
    [+0x044] **Cancel**           : 0x1 [Type: unsigned char]
    [+0x045] CancelIrql       : 0x0 [Type: unsigned char]
    [+0x046] ApcEnvironment   : 0 [Type: char]
    [+0x047] AllocationFlags  : 0x0 [Type: unsigned char]
    [+0x048] UserIosb         : 0x0 [Type: _IO_STATUS_BLOCK *]
    [+0x050] UserEvent        : 0x0 [Type: _KEVENT *]
    [+0x058] Overlay          [Type: _IRP::<unnamed-type-Overlay>]
    [+0x068] **CancelRoutine**    : 0x0 : 0x0 [Type: void (__cdecl*)(_DEVICE_OBJECT *,_IRP *)]
    [+0x070] UserBuffer       : 0x0 [Type: void *]
[+0x078] Tail             [Type: _IRP::<unnamed-type-Tail>]

You’re necroposting. The fact that it’s your own thread doesn’t matter. This thread is six months old.

To remind us all what’s going on…. You’re claiming this Request, that your driver owns and that has a Cancel callback registered, is being externally cancelled… but your registers cancel is not being called? Is that the issue here?

Peter

1 Like

@“Peter_Viscarola_(OSR)” sorry for reposting in old thread. yes peter your understanding on my query is correct.

Below what cancel repeater trying to cancel IRP address is matching with our driver holding request IRP.

4: kd> dx -r1 (*((Wdf01000!FxUsbPipeRepeatReader *)0xffffbd01748bd080))
(*((Wdf01000!FxUsbPipeRepeatReader *)0xffffbd01748bd080))                 [Type: FxUsbPipeRepeatReader]
    [+0x000] Request          : 0xffffbd015c1e63e0 [Type: FxRequest *]
    [+0x008] RequestIrp       : **0xffffbd01614e2010** [Type: _IRP *]
    [+0x010] Parent           : 0xffffbd01748bd020 [Type: FxUsbPipeContinuousReader *]
    [+0x018] Dpc              [Type: _KDPC]
    [+0x058] ReadCompletedEvent [Type: MxEvent]

Cancel Request flow stack due to Idleness

00 fffff800`04a0c800     : fffff800`00712180 00000000`ffffffff 00000000`00000000 00000000`00000000 : nt!KiSwapContext+0x76
01 fffff800`04a0bd2f     : 20008001`00000000 00000035`00000007 fffffe02`00217330 fffffe02`00000000 : nt!KiSwapThread+0x500
02 fffff800`04a0b5d3     : ffffbd01`000000cd fffffe02`00000000 ffffc09b`dc322b00 ffffbd01`45480540 : nt!KiCommitThreadWait+0x14f
03 fffff800`081b7993     : ffffbd01`748bd0d8 ffffbd01`00000000 fffff800`0823be00 000042fe`a98b5500 : nt!KeWaitForSingleObject+0x233
04 (Inline Function)     : --------`-------- --------`-------- --------`-------- --------`-------- : Wdf01000!MxEvent::WaitFor+0x2a [minkernel\wdf\framework\shared\inc\primitives\km\MxEventKm.h @ 122] 
05 fffff800`0820c1de     : fffff800`0367d5a8 ffffffff`dc3cba00 ffffbd01`748bd080 00000000`00000000 : Wdf01000!_FX_DRIVER_GLOBALS::WaitForSignal+0x5f [minkernel\wdf\framework\shared\object\globals.cpp @ 1954] 
06 fffff800`0820d690     : ffffbd01`748bd120 fffff800`0367f000 ffffbd01`5c1e6300 fffffe02`00217400 : Wdf01000!FxUsbPipeContinuousReader::CancelRepeaters+0x76 [minkernel\wdf\framework\shared\targets\usb\fxusbpipe.cpp @ 778] 
07 fffff800`08205361     : ffffbd01`5674aa30 ffffbd01`61424800 fffff800`0367f000 fffff800`04a80001 : Wdf01000!FxUsbPipe::WaitForSentIoToComplete+0xf0 [minkernel\wdf\framework\shared\targets\usb\fxusbpipe.cpp @ 1463] 
08 fffff800`08203692     : 00000000`00000001 fffff800`0367f000 fffffe02`00217600 00000000`00000000 : Wdf01000!FxIoTarget::Stop+0x61 [minkernel\wdf\framework\shared\targets\general\fxiotarget.cpp @ 781] 
09 fffff800`03673143     : ffffbd01`5674aa30 ffffbd01`5a248680 fffff800`0367f000 fffff800`0367d5a8 : Wdf01000!imp_WdfIoTargetStop+0x62 [minkernel\wdf\framework\shared\targets\general\fxiotargetapi.cpp @ 125] 
0a fffff800`036845a2     : ffffbd01`61424800 fffff800`0367d4a8 fffff800`0367f000 70cbfa15`e3e3cc28 : usbser!UsbSerStopUSBRead+0xdb
0b fffff800`081b8abf     : ffffbd01`5a083e28 fffffe02`00217700 00000000`00000003 fffff800`04da1498 : usbser!UsbSerEvtDeviceD0Exit+0x82
0c fffff800`081b0c21     : ffffbd01`5a083e28 fffffe02`002176a0 00000000`00000000 00000000`00000001 : Wdf01000!FxPnpDeviceD0Exit::InvokeClient+0x2f [minkernel\wdf\framework\shared\irphandlers\pnp\pnpcallbacks.cpp @ 285] 
0d fffff800`081bc1c5     : 00000000`00000000 00000000`00000000 00000000`00000003 ffffbd01`5a0838b0 : Wdf01000!FxPrePostCallback::InvokeStateless+0x2d [minkernel\wdf\framework\shared\irphandlers\pnp\cxpnppowercallbacks.cpp @ 408] 
0e (Inline Function)     : --------`-------- --------`-------- --------`-------- --------`-------- : Wdf01000!FxPnpDeviceD0Exit::Invoke+0xf [minkernel\wdf\framework\shared\irphandlers\pnp\pnpcallbacks.cpp @ 261] 

@“Peter_Viscarola_(OSR)” give me sometime in code I am checking some state machine regarding cancel routine. By adding some more debug logs. I am sensing some issue.

@“Peter_Viscarola_(OSR)” one of the failure case cancel routine is called, I tried to force create BSOD. Please find below stacks. one flow stack cancel routine is calling. other flow stack cancel routine is not called. Both flow indicates D0Exit flow where framwork tries to cancel pending request. Only difference I am seeing the flow FxIoTarget::Stop difference.

Failed to call Cancel routine stack BSOD-1:

nt!KeWaitForSingleObject+0x233
Wdf01000!MxEvent::WaitFor+0x2a [minkernel\wdf\framework\shared\inc\primitives\km\MxEventKm.h @ 122] 
Wdf01000!_FX_DRIVER_GLOBALS::WaitForSignal+0x5f [minkernel\wdf\framework\shared\object\globals.cpp @ 1954] 
Wdf01000!FxUsbPipeContinuousReader::CancelRepeaters+0x76 [minkernel\wdf\framework\shared\targets\usb\fxusbpipe.cpp @ 778] 
Wdf01000!FxUsbPipe::WaitForSentIoToComplete+0xf0 [minkernel\wdf\framework\shared\targets\usb\fxusbpipe.cpp @ 1463] 
Wdf01000!FxIoTarget::Stop+0x61 [minkernel\wdf\framework\shared\targets\general\fxiotarget.cpp @ 781] 
Wdf01000!imp_WdfIoTargetStop+0x62 [minkernel\wdf\framework\shared\targets\general\fxiotargetapi.cpp @ 125] 
usbser!UsbSerStopUSBRead+0xdb
usbser!UsbSerEvtDeviceD0Exit+0x82
Wdf01000!FxPnpDeviceD0Exit::InvokeClient+0x2f [minkernel\wdf\framework\shared\irphandlers\pnp\pnpcallbacks.cpp @ 285] 

Cancel Routine is calling stack force BSOD-2:

nt!KiPageFault+0x443
xxx!xxx_cancel_read+0x186  
Wdf01000!FxRequestCancelCallback::InvokeCancel+0x2b [minkernel\wdf\framework\shared\inc\private\common\FxRequestCallbacks.hpp @ 72] 
Wdf01000!FxIoQueue::ProcessCancelledRequests+0x103 [minkernel\wdf\framework\shared\irphandlers\io\fxioqueue.cpp @ 4922] 
Wdf01000!FxIoQueue::DispatchEvents+0x90b [minkernel\wdf\framework\shared\irphandlers\io\fxioqueue.cpp @ 2889] 
Wdf01000!FxIoQueue::DispatchInternalEvents+0x16 [minkernel\wdf\framework\shared\inc\private\common\FxIoQueue.hpp @ 1038] 
Wdf01000!FxIoQueue::CancelForDriver+0x70 [minkernel\wdf\framework\shared\irphandlers\io\fxioqueue.cpp @ 4635] 
Wdf01000!FxIoQueue::_IrpCancelForDriver+0x57 [minkernel\wdf\framework\shared\irphandlers\io\fxioqueue.cpp @ 4688] 
Wdf01000!FxIrpQueue::_WdmCancelRoutineInternal+0x88 [minkernel\wdf\framework\shared\core\fxirpqueue.cpp @ 928] 
nt!IoCancelIrp+0x6f
Wdf01000!FxIrp::Cancel+0x13 [minkernel\wdf\framework\shared\inc\private\km\FxIrpKm.hpp @ 433] 
Wdf01000!FxRequestBase::Cancel+0x6b [minkernel\wdf\framework\shared\core\fxrequestbase.cpp @ 588] 
Wdf01000!FxIoTarget::_CancelSentRequest+0xc [minkernel\wdf\framework\shared\targets\general\fxiotarget.cpp @ 543] 
Wdf01000!FxIoTarget::_CancelSentRequests+0x2b [minkernel\wdf\framework\shared\targets\general\fxiotarget.cpp @ 579] 
Wdf01000!FxIoTarget::Stop+0x42 [minkernel\wdf\framework\shared\targets\general\fxiotarget.cpp @ 766] 
Wdf01000!imp_WdfIoTargetStop+0x62 [minkernel\wdf\framework\shared\targets\general\fxiotargetapi.cpp @ 125] 
usbser!UsbSerStopUSBRead+0xdb
usbser!UsbSerEvtDeviceD0Exit+0x82
Wdf01000!FxPnpDeviceD0Exit::InvokeClient+0x2f [minkernel\wdf\framework\shared\irphandlers\pnp\pnpcallbacks.cpp @ 285] 

FxStop:

VOID
FxIoTarget::Stop(
    __in WDF_IO_TARGET_SENT_IO_ACTION Action
    )
{
    SINGLE_LIST_ENTRY head;
    BOOLEAN wait;

    head.Next = NULL;
    wait = FALSE;

    GotoStopState(Action, &head, &wait, TRUE);

    if (head.Next != NULL) {
        _CancelSentRequests(&head);  **_BSOD-2_**
    }

    if (wait) {
        KIRQL irql;

        //
        // Under the lock, if wait is set, m_WaitingForSentIo is true, but once
        // we drop the lock, all pended i/o could have already been canceled
        // and m_WaitingForSentIo is FALSE at this point.
        //
        // ASSERT(m_WaitingForSentIo);

        WaitForSentIoToComplete(); **_BSOD-1_**

        //
        // Mark that we are no longer stopping and waiting for i/o to complete.
        //
        Lock(&irql);
        m_WaitingForSentIo = FALSE;
        Unlock(irql);
    }

    DoTraceLevelMessage(
        GetDriverGlobals(), TRACE_LEVEL_VERBOSE, TRACINGIOTARGET,
        "WDFIOTARGET %p stopped ",GetHandle());
}

Yeah… I don’t really understand what you’re showing me here, nor do I understand what you’re asking me about, or what behavior you’re seeing.

Sorry… I’d like to help, but… I just haven’t followed your question since your original post.

P

1 Like