Hello,
I am getting a WDF_VIOLATION (10d) bug check when calling WdfDmaTransactionRelease during a cancellation routine for a Bulk-In request in an xhci controller driver I'm working on. The cancellation routine is very straightforward; we basically just stop the bulk in endpoint, and then call WdfDmaTransactionRelease and then WdfObjectDelete on the WDFDMATRANSACTION object associated with the request being cancelled, then WdfRequestCompleteWithInformation on the request. The problem is that things never get this far when the cancellation routine fires; The WdfDmaTransactionRelease call BSODs with WDF_VIOLATION (10d) and reports that "An operation occurred on a DMA transaction object while it was not in the correct state."
The MSDN documentation only says "A bug check occurs if the driver supplies an invalid object handle.". What does this blue screen represent, and what do I need to do to get the DMA transaction object in a state where it is safe to cancel?
Here is the !analyze -v output:
7: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
WDF_VIOLATION (10d)
The Kernel-Mode Driver Framework was notified that Windows detected an error
in a framework-based driver. In general, the dump file will yield additional
information about the driver that caused this bug check.
Arguments:
Arg1: 00000008, An operation occurred on a DMA transaction object while it
was not in the correct state.
Arg2: 7b00f510, Reserved.
Arg3: 00000004, Reserved.
Arg4: 8767ebb0, Reserved.
Debugging Details:
The version of SOS does not match the version of CLR you are debugging. Please
load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.0.30319.32559
SOS Version: 4.0.30319.18213
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
2) the file mscordacwks.dll that matches your version of clr.dll is
in the version directory or on the symbol path
3) or, if you are debugging a dump file, verify that the file
mscordacwks_.dll is on your symbol path.
4) you are debugging on supported cross platform architecture as
the dump file. For example, an ARM dump file must be debugged
on an X86 or an ARM machine; an AMD64 dump file must be
debugged on an AMD64 machine.
You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll. .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.
If you are debugging a minidump, you need to make sure that your executable
path is pointing to clr.dll as well.
The version of SOS does not match the version of CLR you are debugging. Please
load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.0.30319.32559
SOS Version: 4.0.30319.18213
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
2) the file mscordacwks.dll that matches your version of clr.dll is
in the version directory or on the symbol path
3) or, if you are debugging a dump file, verify that the file
mscordacwks_.dll is on your symbol path.
4) you are debugging on supported cross platform architecture as
the dump file. For example, an ARM dump file must be debugged
on an X86 or an ARM machine; an AMD64 dump file must be
debugged on an AMD64 machine.
You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll. .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.
If you are debugging a minidump, you need to make sure that your executable
path is pointing to clr.dll as well.
OVERLAPPED_MODULE: Address regions for 'BusDriver' and 'BusDriver.sys' overlap
BUGCHECK_STR: 0x10D_8
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
PROCESS_NAME: (Application name)
CURRENT_IRQL: 0
ANALYSIS_VERSION: 6.3.9431.0 (debuggers(dbg).130615-1214) x86fre
DEVICE_OBJECT: 878fcb30
DRIVER_OBJECT: 00000000
MANAGED_STACK: !dumpstack -EE
The version of SOS does not match the version of CLR you are debugging. Please
load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.0.30319.32559
SOS Version: 4.0.30319.18213
Failed to load data access DLL, 0x80004005
Some functionality may be impaired
OS Thread Id: 0x0 (7)
TEB information is not available so a stack size of 0xFFFF is assumed
Current frame:
ChildEBP RetAddr Caller, Callee
LAST_CONTROL_TRANSFER: from 80f7b3a9 to 80efe084
STACK_TEXT:
c4439424 80f7b3a9 00000003 faf3628c 00000065 nt!RtlpBreakWithStatusInstruction
c4439478 80f7aec3 8b31d340 c4439878 c44398ac nt!KiBugCheckDebugBreak+0x1f
c443984c 80efcc46 0000010d 00000008 7b00f510 nt!KeBugCheck2+0x676
c4439870 80efcb7d 0000010d 00000008 7b00f510 nt!KiBugCheck2+0xc6
c4439890 8b061762 0000010d 00000008 7b00f510 nt!KeBugCheckEx+0x19
c44398ac 8b0502c5 7b00f510 00000004 7b00f510 Wdf01000!FxVerifierBugCheck+0x1f
c44398cc 8b04e1ae 00000000 8500b7d8 00000000 Wdf01000!FxDmaTransactionBase::ReleaseForReuse+0xa2
c44398ec 9044082e 00000000 84ff0ae8 c4439910 Wdf01000!imp_WdfDmaTransactionRelease+0x96
c44398fc 904417ba 7b00f510 7aff4880 84ff0b90 BusDriver!WdfDmaTransactionRelease+0x1e [c:\program files\windows kits\8.1\include\wdf\kmdf\1.11\wdfdmatransaction.h @ 344]
c4439910 90447df0 7b00f510 c0000120 00000000 BusDriver!IOCTLRequestComplete+0x4a [c:\path\vs2013-BusDriver\dma.c @ 51]
c4439944 8b01833f 7aff4880 84e63ae8 8500b778 BusDriver!EvtRequestBulkInCancel+0xf0 [c:\path\vs2013-BusDriver\ioctl.c @ 208]
c443995c 8b0182cf 00000000 7aff4880 00000009 Wdf01000!FxRequestCancelCallback::InvokeCancel+0x24
c4439984 8b00e65d c44399c0 8500b778 84e63ae8 Wdf01000!FxIoQueue::ProcessCancelledRequests+0xe3
c44399b8 8b017f6b 8500b700 00000000 8500b778 Wdf01000!FxIoQueue::DispatchEvents+0x5e9
c44399d0 8b0184c4 8500b700 84e63b70 878a1f00 Wdf01000!FxIoQueue::CancelForDriver+0x60
c44399e8 8b016c13 84e63b70 878a1f00 8500b7b8 Wdf01000!FxIoQueue::_IrpCancelForDriver+0x57
c4439a10 80e74a28 84e63ef0 878a1f00 8501f25c Wdf01000!FxIrpQueue::_WdmCancelRoutineInternal+0x5b
c4439a2c 8b018ccd 878a1f00 7afe0e08 8501f1f0 nt!IoCancelIrp+0x50
c4439a40 8b0181de 85009648 83f6fcc8 7aff69b0 Wdf01000!FxRequestBase::Cancel+0x4a
c4439a5c 81fb3f86 00000000 8501f1f0 c4439a80 Wdf01000!imp_WdfRequestCancelSentRequest+0x4e
c4439a6c 81fb3e2a 7afe0e08 00000000 7afe0e08 ClientDriver!WdfRequestCancelSentRequest+0x16 [c:\winddk\7600.16385.0\inc\wdf\kmdf\1.9\wdfrequest.h @ 827]
c4439a80 81fbcac3 8500d758 7aff69b0 00222100 ClientDriver!closeGrabbing+0x8a [c:\path\ClientDriver\ioctl.c @ 2048]
c4439bb8 8b00ec05 7aff69b0 7c090330 00000008 ClientDriver!OsrFxEvtIoDeviceControl+0x903 [c:\path\ClientDriver\ioctl.c @ 873]
c4439c0c 8b00e301 7c090330 850096bc 83f6fcc8 Wdf01000!FxIoQueue::DispatchRequestToDriver+0x175
c4439c40 8b00de59 83f6fc00 00000000 8500d5d0 Wdf01000!FxIoQueue::DispatchEvents+0x289
c4439c84 8b00c44a 0100d5d0 83f6fc00 7c090330 Wdf01000!FxPkgIo::EnqueueRequest+0x209
c4439cac 81fb437a 83f6fcc8 8500d5d0 7c090330 Wdf01000!imp_WdfDeviceEnqueueRequest+0x9f
c4439cc0 81fb42f3 7aff2a28 7c090330 863d0000 ClientDriver!WdfDeviceEnqueueRequest+0x1a [c:\winddk\7600.16385.0\inc\wdf\kmdf\1.9\wdfdevice.h @ 3429]
c4439d28 8b00cb3a 7aff2a28 7c090330 00000000 ClientDriver!EvtIoInCallerContext+0x233 [c:\path\ClientDriver\ioctl.c @ 2343]
c4439dd8 80e61a3f 01009960 013d1b90 00000100 Wdf01000!FxDevice::DispatchWithLock+0x66e
c4439df4 8106d1ae 863d1c90 863d1b90 00000000 nt!IofCallDriver+0x3f
c4439e50 8106e618 878fcb30 00000000 00000001 nt!IopSynchronousServiceTail+0x16e
c4439ef8 8106d626 00000000 00000000 00000204 nt!IopXxxControlFile+0x3e8
c4439f24 80f0d337 00000f10 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
c4439f24 773efb74 00000f10 00000000 00000000 nt!KiSystemServicePostCall
0016f120 773eebf2 7501fbb9 00000f10 00000000 ntdll!KiFastSystemCallRet
0016f124 7501fbb9 00000f10 00000000 00000000 ntdll!NtDeviceIoControlFile+0xa
0016f184 76bf17c9 00000f10 00222100 0016f1e4 KERNELBASE!DeviceIoControl+0x77
0016f1b0 661e28c0 00000f10 00222100 0016f1e4 KERNEL32!DeviceIoControlImplementation+0x3d
WARNING: Stack unwind information not available. Following frames may be wrong.
STACK_COMMAND: kb
FOLLOWUP_IP:
BusDriver!WdfDmaTransactionRelease+1e [c:\program files\windows kits\8.1\include\wdf\kmdf\1.11\wdfdmatransaction.h @ 344]
9044082e 5d pop ebp
FAULTING_SOURCE_LINE: c:\program files\windows kits\8.1\include\wdf\kmdf\1.11\wdfdmatransaction.h
FAULTING_SOURCE_FILE: c:\program files\windows kits\8.1\include\wdf\kmdf\1.11\wdfdmatransaction.h
FAULTING_SOURCE_LINE_NUMBER: 344
FAULTING_SOURCE_CODE:
340: WDFDMATRANSACTION DmaTransaction
341: )
342: {
343: return ((PFN_WDFDMATRANSACTIONRELEASE) WdfFunctions[WdfDmaTransactionReleaseTableIndex])(WdfDriverGlobals, DmaTransaction);
> 344: }
345:
346: //
347: // WDF Function: WdfDmaTransactionDmaCompleted
348: //
349: typedef
SYMBOL_STACK_INDEX: 8
SYMBOL_NAME: BusDriver!WdfDmaTransactionRelease+1e
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: BusDriver
IMAGE_NAME: BusDriver.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 520e6c92
BUCKET_ID_FUNC_OFFSET: 1e
FAILURE_BUCKET_ID: 0x10D_8_BusDriver!WdfDmaTransactionRelease
BUCKET_ID: 0x10D_8_BusDriver!WdfDmaTransactionRelease
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:0x10d_8_BusDriver!wdfdmatransactionrelease
FAILURE_ID_HASH: {632a7951-8c82-c2bf-483e-cd4d6e14c247}
Followup: MachineOwner
---------
Run !wdfkd.wdflogdump to see what is wrong
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Friday, August 16, 2013 11:37 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WDF_VIOLATION (10d) BSOD when calling WdfDmaTransactionRelease during cancellation
Hello,
I am getting a WDF_VIOLATION (10d) bug check when calling WdfDmaTransactionRelease during a cancellation routine for a Bulk-In request in an xhci controller driver I’m working on. The cancellation routine is very straightforward; we basically just stop the bulk in endpoint, and then call WdfDmaTransactionRelease and then WdfObjectDelete on the WDFDMATRANSACTION object associated with the request being cancelled, then WdfRequestCompleteWithInformation on the request. The problem is that things never get this far when the cancellation routine fires; The WdfDmaTransactionRelease call BSODs with WDF_VIOLATION (10d) and reports that “An operation occurred on a DMA transaction object while it was not in the correct state.”
The MSDN documentation only says “A bug check occurs if the driver supplies an invalid object handle.”. What does this blue screen represent, and what do I need to do to get the DMA transaction object in a state where it is safe to cancel?
Here is the !analyze -v output:
7: kd> !analyze -v
Bugcheck Analysis
WDF_VIOLATION (10d)
The Kernel-Mode Driver Framework was notified that Windows detected an error in a framework-based driver. In general, the dump file will yield additional information about the driver that caused this bug check.
Arguments:
Arg1: 00000008, An operation occurred on a DMA transaction object while it
was not in the correct state.
Arg2: 7b00f510, Reserved.
Arg3: 00000004, Reserved.
Arg4: 8767ebb0, Reserved.
Debugging Details:
------------------
The version of SOS does not match the version of CLR you are debugging. Please load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.0.30319.32559
SOS Version: 4.0.30319.18213
Failed to load data access DLL, 0x80004005 Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
2) the file mscordacwks.dll that matches your version of clr.dll is
in the version directory or on the symbol path
3) or, if you are debugging a dump file, verify that the file
mscordacwks_.dll is on your symbol path.
4) you are debugging on supported cross platform architecture as
the dump file. For example, an ARM dump file must be debugged
on an X86 or an ARM machine; an AMD64 dump file must be
debugged on an AMD64 machine.
You can also run the debugger command .cordll to control the debugger’s load of mscordacwks.dll. .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.
If you are debugging a minidump, you need to make sure that your executable path is pointing to clr.dll as well.
The version of SOS does not match the version of CLR you are debugging. Please load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.0.30319.32559
SOS Version: 4.0.30319.18213
Failed to load data access DLL, 0x80004005 Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
2) the file mscordacwks.dll that matches your version of clr.dll is
in the version directory or on the symbol path
3) or, if you are debugging a dump file, verify that the file
mscordacwks_.dll is on your symbol path.
4) you are debugging on supported cross platform architecture as
the dump file. For example, an ARM dump file must be debugged
on an X86 or an ARM machine; an AMD64 dump file must be
debugged on an AMD64 machine.
You can also run the debugger command .cordll to control the debugger’s load of mscordacwks.dll. .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.
If you are debugging a minidump, you need to make sure that your executable path is pointing to clr.dll as well.
OVERLAPPED_MODULE: Address regions for ‘BusDriver’ and ‘BusDriver.sys’ overlap
BUGCHECK_STR: 0x10D_8
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
PROCESS_NAME: (Application name)
CURRENT_IRQL: 0
ANALYSIS_VERSION: 6.3.9431.0 (debuggers(dbg).130615-1214) x86fre
DEVICE_OBJECT: 878fcb30
DRIVER_OBJECT: 00000000
MANAGED_STACK: !dumpstack -EE
The version of SOS does not match the version of CLR you are debugging. Please load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.0.30319.32559
SOS Version: 4.0.30319.18213
Failed to load data access DLL, 0x80004005 Some functionality may be impaired OS Thread Id: 0x0 (7) TEB information is not available so a stack size of 0xFFFF is assumed Current frame:
ChildEBP RetAddr Caller, Callee
LAST_CONTROL_TRANSFER: from 80f7b3a9 to 80efe084
STACK_TEXT:
c4439424 80f7b3a9 00000003 faf3628c 00000065 nt!RtlpBreakWithStatusInstruction
c4439478 80f7aec3 8b31d340 c4439878 c44398ac nt!KiBugCheckDebugBreak+0x1f c443984c 80efcc46 0000010d 00000008 7b00f510 nt!KeBugCheck2+0x676
c4439870 80efcb7d 0000010d 00000008 7b00f510 nt!KiBugCheck2+0xc6
c4439890 8b061762 0000010d 00000008 7b00f510 nt!KeBugCheckEx+0x19 c44398ac 8b0502c5 7b00f510 00000004 7b00f510 Wdf01000!FxVerifierBugCheck+0x1f c44398cc 8b04e1ae 00000000 8500b7d8 00000000 Wdf01000!FxDmaTransactionBase::ReleaseForReuse+0xa2
c44398ec 9044082e 00000000 84ff0ae8 c4439910 Wdf01000!imp_WdfDmaTransactionRelease+0x96
c44398fc 904417ba 7b00f510 7aff4880 84ff0b90 BusDriver!WdfDmaTransactionRelease+0x1e [c:\program files\windows kits\8.1\include\wdf\kmdf\1.11\wdfdmatransaction.h @ 344]
c4439910 90447df0 7b00f510 c0000120 00000000 BusDriver!IOCTLRequestComplete+0x4a [c:\path\vs2013-BusDriver\dma.c @ 51]
c4439944 8b01833f 7aff4880 84e63ae8 8500b778 BusDriver!EvtRequestBulkInCancel+0xf0 [c:\path\vs2013-BusDriver\ioctl.c @ 208] c443995c 8b0182cf 00000000 7aff4880 00000009 Wdf01000!FxRequestCancelCallback::InvokeCancel+0x24
c4439984 8b00e65d c44399c0 8500b778 84e63ae8 Wdf01000!FxIoQueue::ProcessCancelledRequests+0xe3
c44399b8 8b017f6b 8500b700 00000000 8500b778 Wdf01000!FxIoQueue::DispatchEvents+0x5e9
c44399d0 8b0184c4 8500b700 84e63b70 878a1f00 Wdf01000!FxIoQueue::CancelForDriver+0x60
c44399e8 8b016c13 84e63b70 878a1f00 8500b7b8 Wdf01000!FxIoQueue::_IrpCancelForDriver+0x57
c4439a10 80e74a28 84e63ef0 878a1f00 8501f25c Wdf01000!FxIrpQueue::_WdmCancelRoutineInternal+0x5b
c4439a2c 8b018ccd 878a1f00 7afe0e08 8501f1f0 nt!IoCancelIrp+0x50
c4439a40 8b0181de 85009648 83f6fcc8 7aff69b0 Wdf01000!FxRequestBase::Cancel+0x4a
c4439a5c 81fb3f86 00000000 8501f1f0 c4439a80 Wdf01000!imp_WdfRequestCancelSentRequest+0x4e
c4439a6c 81fb3e2a 7afe0e08 00000000 7afe0e08 ClientDriver!WdfRequestCancelSentRequest+0x16 [c:\winddk\7600.16385.0\inc\wdf\kmdf\1.9\wdfrequest.h @ 827]
c4439a80 81fbcac3 8500d758 7aff69b0 00222100 ClientDriver!closeGrabbing+0x8a [c:\path\ClientDriver\ioctl.c @ 2048]
c4439bb8 8b00ec05 7aff69b0 7c090330 00000008 ClientDriver!OsrFxEvtIoDeviceControl+0x903 [c:\path\ClientDriver\ioctl.c @ 873] c4439c0c 8b00e301 7c090330 850096bc 83f6fcc8 Wdf01000!FxIoQueue::DispatchRequestToDriver+0x175
c4439c40 8b00de59 83f6fc00 00000000 8500d5d0 Wdf01000!FxIoQueue::DispatchEvents+0x289
c4439c84 8b00c44a 0100d5d0 83f6fc00 7c090330 Wdf01000!FxPkgIo::EnqueueRequest+0x209
c4439cac 81fb437a 83f6fcc8 8500d5d0 7c090330 Wdf01000!imp_WdfDeviceEnqueueRequest+0x9f
c4439cc0 81fb42f3 7aff2a28 7c090330 863d0000 ClientDriver!WdfDeviceEnqueueRequest+0x1a [c:\winddk\7600.16385.0\inc\wdf\kmdf\1.9\wdfdevice.h @ 3429]
c4439d28 8b00cb3a 7aff2a28 7c090330 00000000 ClientDriver!EvtIoInCallerContext+0x233 [c:\path\ClientDriver\ioctl.c @ 2343]
c4439dd8 80e61a3f 01009960 013d1b90 00000100 Wdf01000!FxDevice::DispatchWithLock+0x66e
c4439df4 8106d1ae 863d1c90 863d1b90 00000000 nt!IofCallDriver+0x3f
c4439e50 8106e618 878fcb30 00000000 00000001 nt!IopSynchronousServiceTail+0x16e
c4439ef8 8106d626 00000000 00000000 00000204 nt!IopXxxControlFile+0x3e8
c4439f24 80f0d337 00000f10 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
c4439f24 773efb74 00000f10 00000000 00000000 nt!KiSystemServicePostCall
0016f120 773eebf2 7501fbb9 00000f10 00000000 ntdll!KiFastSystemCallRet
0016f124 7501fbb9 00000f10 00000000 00000000 ntdll!NtDeviceIoControlFile+0xa
0016f184 76bf17c9 00000f10 00222100 0016f1e4 KERNELBASE!DeviceIoControl+0x77
0016f1b0 661e28c0 00000f10 00222100 0016f1e4 KERNEL32!DeviceIoControlImplementation+0x3d
WARNING: Stack unwind information not available. Following frames may be wrong.
STACK_COMMAND: kb
FOLLOWUP_IP:
BusDriver!WdfDmaTransactionRelease+1e [c:\program files\windows kits\8.1\include\wdf\kmdf\1.11\wdfdmatransaction.h @ 344]
9044082e 5d pop ebp
FAULTING_SOURCE_LINE: c:\program files\windows kits\8.1\include\wdf\kmdf\1.11\wdfdmatransaction.h
FAULTING_SOURCE_FILE: c:\program files\windows kits\8.1\include\wdf\kmdf\1.11\wdfdmatransaction.h
FAULTING_SOURCE_LINE_NUMBER: 344
FAULTING_SOURCE_CODE:
340: WDFDMATRANSACTION DmaTransaction
341: )
342: {
343: return ((PFN_WDFDMATRANSACTIONRELEASE) WdfFunctions[WdfDmaTransactionReleaseTableIndex])(WdfDriverGlobals, DmaTransaction);
> 344: }
345:
346: //
347: // WDF Function: WdfDmaTransactionDmaCompleted
348: //
349: typedef
SYMBOL_STACK_INDEX: 8
SYMBOL_NAME: BusDriver!WdfDmaTransactionRelease+1e
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: BusDriver
IMAGE_NAME: BusDriver.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 520e6c92
BUCKET_ID_FUNC_OFFSET: 1e
FAILURE_BUCKET_ID: 0x10D_8_BusDriver!WdfDmaTransactionRelease
BUCKET_ID: 0x10D_8_BusDriver!WdfDmaTransactionRelease
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:0x10d_8_BusDriver!wdfdmatransactionrelease
FAILURE_ID_HASH: {632a7951-8c82-c2bf-483e-cd4d6e14c247}
Followup: MachineOwner
---------
—
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
xxxxx@gmail.com wrote:
I am getting a WDF_VIOLATION (10d) bug check when calling WdfDmaTransactionRelease during a cancellation routine for a Bulk-In request in an xhci controller driver I’m working on. The cancellation routine is very straightforward; we basically just stop the bulk in endpoint, and then call WdfDmaTransactionRelease and then WdfObjectDelete on the WDFDMATRANSACTION object associated with the request being cancelled, then WdfRequestCompleteWithInformation on the request.
You can only release a DMA transaction that has been completed. Have
you called one of the WdfDmaTransactionDmaCompleted* functions for thi
transaction yet?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Great! Fixed! I added a WdfDmaTransactionDmaCompletedFinal(dmaTransaction, 0, &status); before the call to release and everything worked.
I was looking at some other cancel code that was not calling this, and was under the impression we could leave it off.
Thanks all,
-R