Question about inverted call

Hi all,

right now I plan to implement the inverted call into my WDM driver from User Mode.
Yes it is WDM and it is an older stack which I can not change right now. So I need to handle it with WDM I guess.

First step was to implement the User Mode code and send down the IOCTL with the Overlapped struct.

This is working if I create and attache my own event to the Overlapped.
If I do not add this I will get ERROR 6.

I write this because in the GItHub sample: https://github.com/OSRDrivers/Inverted
in the InvertedTest the Event is not created explizit. Is this somehow done or handle with the: CreateIoCompletionPort ?

Another question is:
If I send the IOCTL down and do not mark the IRP as PENDING, do I should get a callback via Event immediately or does this only happen if I queue the IRP in my driver and complete it later?

If I have understood it correct I need to implement IO_CSQ in my driver to queue and keep the IRPs in my driver and to complete them at a later timer on my driver. Is this correct?

I guess I will have more questions later if I made progress with my implementation.

Thanks!
Regards K. Weller

" The user must initialize this member either to zero or a valid event handle " error 6 is ERROR_INVALID_HANDLE. So if you are not correctly initializing the OVERLAPPED object, this would explain the error.

The OSR example is using iocompletionports because this approach scales. One event per io is limited by the maximum number of event handles that can be used in waitformultipleobjects, 64 handles. If you need to scale up to thousands of ios, this is the way to go.

If I send the IOCTL down and do not mark the IRP as PENDING, do I should get a callback via Event immediately or does this only happen if I queue the IRP in my driver and complete it later?

The user-mode caller will get the callback immediately, and the memory for the IRP will be freed, so the driver can’t touch it any more. In other words, DON’T DO THAT. Either call IoCompleteRequest, or call IoMarkIrpPending. Anything else is a design error.

If I have understood it correct I need to implement IO_CSQ in my driver to queue and keep the IRPs in my driver and to complete them at a later timer on my driver. Is this correct?

If you mark the IRP as pending, then you need to store it somewhere so you can complete it later. That’s a requirement.

Technically, you don’t NEED to use IO_CSQ to do that (you could use a LINKED_LIST), but it certainly makes things more convenient, and it allows you to handle cancellation properly, which is one of the top three sources of errors in WDM drivers.

Thanks a lot for the replays.

The user-mode caller will get the callback immediately, and the memory for the IRP will
be freed, so the driver can’t touch it any more. In other words, DON’T DO THAT. Either
call IoCompleteRequest, or call IoMarkIrpPending. Anything else is a design error.

Yes of course that makes totaly sense and I just did this for testing purpose. But of course, if the IPR completed and is gone the Event is gone as well.

I will look if it works now as expected.

Thanks again!

Best regards,
K. Weller

“One event per io is limited by the maximum number of event handles that can be used in waitformultipleobjects, 64 handles”

IO Completion ports are a vastly better method, but this statement is not true. If only one thread is doing the waiting, and all of the in progress IO has to be waited for in one UM - KM call, then yes MAX_WAIT_OBJECTS (64) is the limit. But of course many more can be in progress if ‘select’ style coding is used. It performs horribly even at the best of times, but it can be done.

In any case, the problems seem clear - the OP is not ZeroMemory’ing the OVERLAPPED before passing it. And he should certainly use IOCP. Even If he doesn’t think that he needs to scale up, It is better at all levels of IO. It becomes increasingly better the more load the system is under - which is another highly desirable design point

Sure you van work around the 64 handle limit, but it remains the limit, and the work arounds are horrible. So what exactly wasn’t true?

Let’s say that we are loudly agreeing ‘DO NOT DO THIS’. But disagreeing on a subtle and abstruse point

Thanks again for the discussion and the help.

I have it now working as expected as replacement for a shared event between UM and KM.

Now I have one more question for now about it.

Can I use this mechanism to move data between UM and KM in both direction from about 100 KB size each IOCTRL or is this not the correct approach?
I want to transmit the IN USB data from KM into UM and from UM back into KM to USB OUT.

Every milisecond there could be up to 8.192 byte each direction or if I group them together, every 5 ms 40.960 byte for example.

K. Weller

Are you planning to copy back 8MB/second? If so, yes… that should work.

But it’d be better if you could provide the user data buffer directly to the underlying stack/device and avoid doing any data copying. Unless that’s just not possible.

Thanks Peter!
That help me a lot. I will also check if I can make it to use the data buffer directly. Which of course makes sense.

But I have another issue which now appears.

If I use my code direct in my:

DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = DispatchControl;

Everything works nice.

If I try to call the

IoCsqInsertIrp(&pdx->CancelSafeQueue, Irp, NULL);
or
IoCsqRemoveNextIrp(&pdx->CancelSafeQueue, NULL);

from the code I use for the USB completion callbacks, it seems the CancelSaveQueue is not valid.
I checked the deviceExtentione address and queue address and everything seems to be OK.
The queue is initialized etc.

But I get an Bugcheck

KERNEL_SECURITY_CHECK_FAILURE (139)
A kernel component has corrupted a critical data structure. The corruption~~~~
could potentially allow a malicious user to gain control of this machine.
Arguments:
Arg1: 000000000000000a, Type of memory safety violation
Arg2: 0000000000000000, Address of the trap frame for the exception that caused the bugcheck
Arg3: 0000000000000000, Address of the exception record for the exception that caused the bugcheck
Arg4: 0000000000000000, Reserved

From Microsoft Bugcheck documentation:

10 Indirect call guard check detected invalid control transfer.

Right now I have no idea what I’m doing wrong here.
Any idear?

Thanks
K. Weller

!analyze -v is always a good idea. I’m guessing your CSQ callbacks are the prime suspects, but the stack would provide the answers.

Right. It’s not exactly trivial to set up a CancelSafeQueue. Show us the code that created it.

Thanks again,

I will add two !analyze -v stack traces in two sepertae posts to make it hopefuly readable.

About your qeustion Tim:
I used for a starting point this example.

https://github.com/microsoft/Windows-driver-samples/blob/main/general/cancel/sys/cancel.h
https://github.com/microsoft/Windows-driver-samples/blob/main/general/cancel/sys/cancel.cpp

without any changes. And as I said if I use the code from my

MajorFunction[IRP_MJ_DEVICE_CONTROL] = DispatchControl;

It works as expected.

In my AddDevice I do the initialisation:

status = IoCreateDevice(DriverObject, xsize, NULL, FILE_DEVICE_UNKNOWN, FILE_DEVICE_SECURE_OPEN, FALSE, &fdo);

PDEVICE_EXTENSION pdx = (PDEVICE_EXTENSION) fdo->DeviceExtension;

KeInitializeSpinLock(&pdx->QueueLock);

KeInitializeSemaphore(&pdx->IrpQueueSemaphore, 0, MAXLONG);

//
// Initialize the pending Irp devicequeue
//

InitializeListHead(&pdx->PendingIrpQueue);

// IO Cacnle save queue
status = IoCsqInitialize(&pdx->CancelSafeQueue,
	CsampInsertIrp,
	CsampRemoveIrp,
	CsampPeekNextIrp,
	CsampAcquireLock,
	CsampReleaseLock,
	CsampCompleteCanceledIrp);

I will now add two stack traces which show different bugchecks.

The IRQL_NOT_LESS_OR_EQUAL happen in the USB callback
The other 139 bugcheck happen if I call it from user mode via my controll panel and a IOCNTRL call.

Thanks
K. Weller

0: kd> p
KDTARGET: Refreshing KD connection

*** Fatal System Error: 0x00000139
					(0x000000000000000A,0x0000000000000000,0x0000000000000000,0x0000000000000000)

WARNING: This break is not a step/trace completion.
The last command has been cleared to prevent
accidental continuation of this unrelated event.
Check the event, location and thread before resuming.
Break instruction exception - code 80000003 (first chance)

A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

Connected to Windows 10 22621 x64 target at (Fri Dec  8 11:11:19.699 2023 (UTC + 1:00)), ptr64 TRUE
Loading Kernel Symbols
...............................................................
................................................................
.......................................................
Loading User Symbols
........................................................
Loading unloaded module list
.............
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 139, {a, 0, 0, 0}

*** ERROR: Module load completed but symbols could not be loaded for testpanel.exe
Probably caused by : usbotgmdrv.sys ( usbotgmdrv!cusbcom::MixerSet+115 )

Followup:     MachineOwner
---------

nt!DbgBreakPointWithStatus:
fffff802`54620960 cc              int     3
0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

KERNEL_SECURITY_CHECK_FAILURE (139)
A kernel component has corrupted a critical data structure.  The corruption
could potentially allow a malicious user to gain control of this machine.
Arguments:
Arg1: 000000000000000a, Type of memory safety violation
Arg2: 0000000000000000, Address of the trap frame for the exception that caused the bugcheck
Arg3: 0000000000000000, Address of the exception record for the exception that caused the bugcheck
Arg4: 0000000000000000, Reserved

Debugging Details:
------------------


KEY_VALUES_STRING: 1


STACKHASH_ANALYSIS: 1

TIMELINE_ANALYSIS: 1


DUMP_CLASS: 1

DUMP_QUALIFIER: 0

BUILD_VERSION_STRING:  22621.2506.amd64fre.ni_release_svc_prod3.231018-1809

DUMP_TYPE:  0

BUGCHECK_P1: a

BUGCHECK_P2: 0

BUGCHECK_P3: 0

BUGCHECK_P4: 0

TRAP_FRAME:  0000000000000000 -- (.trap 0x0)

EXCEPTION_RECORD:  0000000000000000 -- (.exr 0x0)
Cannot read Exception record @ 0000000000000000

CPU_COUNT: 4

CPU_MHZ: c79

CPU_VENDOR:  GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 3c

CPU_STEPPING: 3

CPU_MICROCODE: 6,3c,3,0 (F,M,S,R)  SIG: 28'00000000 (cache) 28'00000000 (init)

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

BUGCHECK_STR:  0x139

PROCESS_NAME:  testpanel.exe

CURRENT_IRQL:  0

ANALYSIS_SESSION_HOST:  PC-562

ANALYSIS_SESSION_TIME:  12-08-2023 11:11:36.0115

ANALYSIS_VERSION: 10.0.17763.1 amd64fre

LAST_CONTROL_TRANSFER:  from fffff80254766882 to fffff80254620960

STACK_TEXT:  
ffff820c`fac75a48 fffff802`54766882 : ffff820c`fac75bb0 fffff802`5451afa0 fffff802`4e5f3180 00000000`00000001 : nt!DbgBreakPointWithStatus
ffff820c`fac75a50 fffff802`54765f43 : fffff802`00000003 ffff820c`fac75bb0 fffff802`5462fc70 00000000`00000139 : nt!KiBugCheckDebugBreak+0x12
ffff820c`fac75ab0 fffff802`54616a87 : 00000000`00000000 00000000`00000000 000001ee`4cb39540 ffffede0`2af5118b : nt!KeBugCheck2+0xba3
ffff820c`fac76220 fffff802`546216be : 00000000`00000139 00000000`0000000a 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx+0x107
ffff820c`fac76260 fffff802`54536103 : ffff820c`fac762d8 fffff802`607e581f 00000000`00000010 00000000`00000284 : nt!guard_icall_bugcheck+0x1e
ffff820c`fac76290 fffff802`607e5825 : 00000000`00000000 000001ee`4cb39540 ffff820c`fac763c0 00000000`00000000 : nt!IoCsqRemoveNextIrp+0x33
ffff820c`fac762c0 fffff802`607f71d8 : ffffa300`00000000 00000000`000009d2 ffff850e`14292680 00000000`00001001 : usbotgmdrv!cusbcom::MixerSet+0x115 [d:\work\common.cpp @ 2078] 
ffff820c`fac76580 fffff802`607f7461 : ffff850e`0c8119b0 ffff850e`14292680 ffff850e`12260c10 ffff850e`0c30b000 : usbotgmdrv!Do_MixerIO+0x128 [d:\work\currentsources\iewdm\usb_2_project\1-comminc\ioctrl.cpp @ 965] 
ffff820c`fac765d0 fffff802`607ec69f : 00000000`0000031f ffff850e`11b0fa20 00000000`00000000 fffff802`60d81723 : usbotgmdrv!WdmIoCall+0x71 [d:\work\currentsources\iewdm\usb_2_project\1-comminc\ioctrl.cpp @ 1015] 
ffff820c`fac76600 fffff802`544ec015 : ffff820c`fac766e0 00000000`00000000 ffff850e`11b0fa20 ffff850e`0c802000 : usbotgmdrv!DispatchControl+0xff [d:\work\currentsources\iewdm\usb_2_project\1-multifunc\driverentry.cpp @ 871] 
ffff820c`fac76650 fffff802`60d81415 : ffff850e`11b0fa20 ffff820c`fac766e0 ffff850e`11b0ff70 ffff850e`112f6d30 : nt!IofCallDriver+0x55
ffff820c`fac76690 fffff802`60d81133 : ffff850e`11b0fa20 00000000`00000002 00000000`00000000 ffff850e`0ff8c300 : ksthunk!CKernelFilterDevice::DispatchIrp+0xf5
ffff820c`fac766f0 fffff802`544ec015 : 00000000`42536f49 fffff802`54942437 00000000`00000000 00000000`00000500 : ksthunk!CKernelFilterDevice::DispatchIrpBridge+0x13
ffff820c`fac76720 fffff802`54940080 : ffff850e`11b0fa20 00000000`00000002 ffff850e`124a7b80 ffff850e`124a7b80 : nt!IofCallDriver+0x55
ffff820c`fac76760 fffff802`54941ab0 : ffff850e`11b0fa20 00000000`00000080 ffff820c`fac76b05 ffff850e`124a7b80 : nt!IopSynchronousServiceTail+0x1d0
ffff820c`fac76810 fffff802`54941396 : ffffa300`871de9a0 00000000`00000001 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0x700
ffff820c`fac76a00 fffff802`5462b6e8 : 0000006e`0000003e 00000144`0000004d ffffe8fb`0eb94694 00000000`000702d6 : nt!NtDeviceIoControlFile+0x56
ffff820c`fac76a70 00007ffe`1e44f454 : 00007ffe`1b8a664b 00000000`00000000 00000000`00000003 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x28
000000d8`fc0feed8 00007ffe`1b8a664b : 00000000`00000000 00000000`00000003 00000000`00000000 000000d8`fc0fefa9 : ntdll!NtDeviceIoControlFile+0x14
000000d8`fc0feee0 00007ffe`1cda27f1 : 00000000`002a3bb8 000001ee`4c9107d0 00000000`00000000 00007ff6`759968b0 : KERNELBASE!DeviceIoControl+0x6b
000000d8`fc0fef50 00007ff6`759bbc31 : 00007ff6`75c2fab0 00000000`00000000 00000000`00000000 000001ee`4c9107d0 : KERNEL32!DeviceIoControlImplementation+0x81
000000d8`fc0fefa0 00007ff6`75c2fab0 : 00000000`00000000 00000000`00000000 000001ee`4c9107d0 000000d8`fc0feff0 : testpanel+0x11bc31
000000d8`fc0fefa8 00000000`00000000 : 00000000`00000000 000001ee`4c9107d0 000000d8`fc0feff0 000000d6`00000080 : testpanel+0x38fab0


THREAD_SHA1_HASH_MOD_FUNC:  b71ff00aaaf4c4ad4a5f16e0d459f8afb7b5bbc9

THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  d5d049b00f6e22d14e9de669ff9e651581b96afe

THREAD_SHA1_HASH_MOD:  84580b37206fa18d6affcbb13778ba1e046533ec

FOLLOWUP_IP: 
usbotgmdrv!cusbcom::MixerSet+115 [d:\work\common.cpp @ 2078]
fffff802`607e5825 4c8bf0          mov     r14,rax

FAULT_INSTR_CODE:  48f08b4c

FAULTING_SOURCE_LINE:  d:\work\common.cpp

FAULTING_SOURCE_FILE:  d:\work\common.cpp

FAULTING_SOURCE_LINE_NUMBER:  2078

FAULTING_SOURCE_CODE:  
2074: 	{

2078: 		PIRP p = IoCsqRemoveNextIrp(&devExtension1->CancelSafeQueue, NULL);
2079: 		if (p)
2080: 		{



SYMBOL_STACK_INDEX:  6

SYMBOL_NAME:  usbotgmdrv!cusbcom::MixerSet+115

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: usbotgmdrv

IMAGE_NAME:  usbotgmdrv.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  6572eb74

STACK_COMMAND:  .thread ; .cxr ; kb

BUCKET_ID_FUNC_OFFSET:  115

FAILURE_BUCKET_ID:  0x139_a_GUARD_ICALL_CHECK_FAILURE_usbotgmdrv!cusbcom::MixerSet

BUCKET_ID:  0x139_a_GUARD_ICALL_CHECK_FAILURE_usbotgmdrv!cusbcom::MixerSet

PRIMARY_PROBLEM_CLASS:  0x139_a_GUARD_ICALL_CHECK_FAILURE_usbotgmdrv!cusbcom::MixerSet

TARGET_TIME:  2023-12-08T10:11:39.000Z

OSBUILD:  22621

OSSERVICEPACK:  0

SERVICEPACK_NUMBER: 0

OS_REVISION: 0

SUITE_MASK:  272

PRODUCT_TYPE:  1

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

OSEDITION:  Windows 10 WinNt TerminalServer SingleUserTS

OS_LOCALE:  

USER_LCID:  0

OSBUILD_TIMESTAMP:  1989-12-11 11:40:12

BUILDDATESTAMP_STR:  231018-1809

BUILDLAB_STR:  ni_release_svc_prod3

BUILDOSVER_STR:  10.0.22621.2506.amd64fre.ni_release_svc_prod3.231018-1809

ANALYSIS_SESSION_ELAPSED_TIME:  1b95

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:0x139_a_guard_icall_check_failure_usbotgmdrv!cusbcom::MixerSet

FAILURE_ID_HASH:  {24ee6655-1688-934c-6cb1-84da9d98800a}

Followup:     MachineOwner
---------
0: kd> p
usbotgmdrv!cusbcom::asyncincompletion+0x32e:
fffff806`67d2461e 498d8dc8010000  lea     rcx,[r13+1C8h]
0: kd> p
KDTARGET: Refreshing KD connection

*** Fatal System Error: 0x0000000a
					(0x00000000000001E8,0x0000000000000002,0x0000000000000000,0xFFFFF806319360E4)


Connected to Windows 10 22621 x64 target at (Fri Dec  8 10:58:42.770 2023 (UTC + 1:00)), ptr64 TRUE
Loading Kernel Symbols
...............................................................
................................................................
...............................................................
Loading User Symbols

Loading unloaded module list
........................
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {1e8, 2, 0, fffff806319360e4}



Followup:     MachineOwner
---------

nt!DbgBreakPointWithStatus:
fffff806`31a20960 cc              int     3
0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000000000001e8, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
	bit 0 : value 0 = read operation, 1 = write operation
	bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff806319360e4, address which referenced memory

Debugging Details:
------------------


KEY_VALUES_STRING: 1


STACKHASH_ANALYSIS: 1

TIMELINE_ANALYSIS: 1


DUMP_CLASS: 1

DUMP_QUALIFIER: 0

BUILD_VERSION_STRING:  22621.2506.amd64fre.ni_release_svc_prod3.231018-1809

DUMP_TYPE:  0

BUGCHECK_P1: 1e8

BUGCHECK_P2: 2

BUGCHECK_P3: 0

BUGCHECK_P4: fffff806319360e4

READ_ADDRESS: Unable to get offset of nt!_MI_VISIBLE_STATE.SpecialPool
Unable to get value of nt!_MI_VISIBLE_STATE.SessionSpecialPool
MAX_SYSTEM_VA_ASSIGNMENTS needs to be increased
00000000000001e8 

CURRENT_IRQL:  2

FAULTING_IP: 
nt!IoCsqRemoveNextIrp+14
fffff806`319360e4 488b4120        mov     rax,qword ptr [rcx+20h]

CPU_COUNT: 4

CPU_MHZ: c79

CPU_VENDOR:  GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 3c

CPU_STEPPING: 3

CPU_MICROCODE: 6,3c,3,0 (F,M,S,R)  SIG: 28'00000000 (cache) 28'00000000 (init)

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

BUGCHECK_STR:  AV

PROCESS_NAME:  System

ANALYSIS_SESSION_HOST:  PC-562

ANALYSIS_SESSION_TIME:  12-08-2023 10:59:01.0180

ANALYSIS_VERSION: 10.0.17763.1 amd64fre

TRAP_FRAME:  fffff8063567fbf0 -- (.trap 0xfffff8063567fbf0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=00000000000001c8
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff806319360e4 rsp=fffff8063567fd80 rbp=ffffca0fa95cd7b0
r8=0000000000000001  r9=0000000000000000 r10=fffff80631869d80
r11=0000000000000680 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na pe nc
nt!IoCsqRemoveNextIrp+0x14:
fffff806`319360e4 488b4120        mov     rax,qword ptr [rcx+20h] ds:00000000`000001e8=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff80631b66882 to fffff80631a20960

STACK_TEXT:  
fffff806`3567f298 fffff806`31b66882 : fffff806`3567f400 fffff806`3191afa0 fffff806`2e0cb180 00000000`00000101 : nt!DbgBreakPointWithStatus
fffff806`3567f2a0 fffff806`31b65f43 : fffff806`00000003 fffff806`3567f400 fffff806`31a2fd00 fffff806`3567f9b0 : nt!KiBugCheckDebugBreak+0x12
fffff806`3567f300 fffff806`31a16a87 : fffff806`3567fb10 fffff806`31ac5784 00000000`00000002 00000000`00000003 : nt!KeBugCheck2+0xba3
fffff806`3567fa70 fffff806`31a2bfa9 : 00000000`0000000a 00000000`000001e8 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx+0x107
fffff806`3567fab0 fffff806`31a27634 : 00000000`00000000 00000000`00000600 00000000`00000020 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff806`3567fbf0 fffff806`319360e4 : ffffca0f`afc4a501 fffff806`67d2462e 00000000`00000010 00000000`00000244 : nt!KiPageFault+0x474
fffff806`3567fd80 fffff806`67d24634 : 00000000`00000002 00000000`00000002 ffffca0f`a95cd7b0 ffffca0f`a9569000 : nt!IoCsqRemoveNextIrp+0x14
fffff806`3567fdb0 fffff806`3195f076 : 00000000`00000000 00000000`00000000 ffffca0f`ae331300 00000000`00000030 : usbotgmdrv!cusbcom::AsyncInCompletion+0x344 [d:\work\common.cpp @ 8390] 
fffff806`3567fe20 fffff806`318149b4 : 00000000`00000000 fffff806`3567fec9 ffffca0f`afc4aa2b 00000000`00000000 : nt!IopUnloadSafeCompletion+0x56
fffff806`3567fe50 fffff806`31814867 : ffffca0f`afc4a520 00000000`00000000 00000000`00000000 00000000`00000000 : nt!IopfCompleteRequest+0x134
fffff806`3567ff30 fffff806`35d83cc6 : 00000000`00000002 00000000`00000000 00000000`00000000 fffff806`35dc267d : nt!IofCompleteRequest+0x17
fffff806`3567ff60 fffff806`35d82031 : ffffca0f`afc4a520 fffff806`00000001 ffffca0f`aa8d8230 ffffca0f`aed71b30 : Wdf01000!FxRequest::CompleteInternal+0x246 [minkernel\wdf\framework\shared\core\fxrequest.cpp @ 869] 
fffff806`3567fff0 fffff806`35d81fbf : 00000000`00000000 ffffca0f`aed71cd0 ffffca0f`b0c43e00 00000000`00000000 : Wdf01000!FxRequest::Complete+0x4d [minkernel\wdf\framework\shared\inc\private\common\FxRequest.hpp @ 806] 
fffff806`35680050 fffff806`41312e58 : ffffca0f`aed71b30 ffffca0f`aed71cd0 ffffca0f`afbe4d60 fffff806`00000001 : Wdf01000!imp_WdfRequestComplete+0x3f [minkernel\wdf\framework\shared\core\fxrequestapi.cpp @ 437] 
fffff806`35680080 fffff806`4131240e : ffffca0f`b0c43e00 ffffca0f`b0c43e00 ffffca0f`00000048 fffff806`2ff33501 : USBXHCI!Isoch_Stage_CompleteTD+0x488
fffff806`35680140 fffff806`41311ea0 : fffff806`35680328 fffff806`35680200 00000000`00000000 fffff806`00000000 : USBXHCI!Isoch_ProcessTransferEventWithED1+0x54e
fffff806`35680220 fffff806`41319cd8 : 00000000`00000004 fffff806`356802f8 00000000`00000008 fffff806`35680300 : USBXHCI!Isoch_EP_TransferEventHandler+0x10
fffff806`35680250 fffff806`41319348 : ffffca0f`aadf9220 ffffca0f`aabf9d00 ffffca0f`aaf162f0 ffffca0f`aadf9220 : USBXHCI!Endpoint_TransferEventHandler+0x108
fffff806`356802b0 fffff806`41318bfc : 00000000`00000000 00000000`00000000 ffffca0f`aadf9020 00000000`00000000 : USBXHCI!Interrupter_DeferredWorkProcessor+0x738
fffff806`356803b0 fffff806`35d86d2d : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : USBXHCI!Interrupter_WdfEvtInterruptDpc+0xc
fffff806`356803e0 fffff806`35d86cd5 : 00000000`00001f01 fffff806`2e0ce4d8 ffffca0f`aadf9020 00000000`00000000 : Wdf01000!FxInterrupt::DpcHandler+0x49 [minkernel\wdf\framework\shared\irphandlers\pnp\km\interruptobjectkm.cpp @ 75] 
fffff806`35680410 fffff806`318720fc : 00000000`00000000 ffffa101`a15c1ab0 fffff806`00000000 fffff806`35680694 : Wdf01000!FxInterrupt::_InterruptDpcThunk+0x35 [minkernel\wdf\framework\shared\irphandlers\pnp\km\interruptobjectkm.cpp @ 410] 
fffff806`35680450 fffff806`318733b1 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiExecuteAllDpcs+0x42c
fffff806`35680990 fffff806`31a1b77e : 00000000`00000000 fffff806`2e0cb180 00000000`00000000 fffff806`3234d700 : nt!KiRetireDpcList+0x1b1
fffff806`35680c40 00000000`00000000 : fffff806`35681000 fffff806`3567b000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x9e


THREAD_SHA1_HASH_MOD_FUNC:  031b8918b08ac5bfdb5a7b58165d77b9f4eb1ca5

THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  6c1753ca43ec3a489ce777cbe864333d64345e08

THREAD_SHA1_HASH_MOD:  b68d1351d98fb4878534d14e42d243a39f5ec8ff

FOLLOWUP_IP: 
usbotgmdrv!cusbcom::AsyncInCompletion+344 [d:\work\common.cpp @ 8390]
fffff806`67d24634 488bf8          mov     rdi,rax

FAULT_INSTR_CODE:  48f88b48

FAULTING_SOURCE_LINE:  d:\work\common.cpp

FAULTING_SOURCE_FILE:  d:\work\common.cpp

FAULTING_SOURCE_LINE_NUMBER:  8390

FAULTING_SOURCE_CODE:  

8390: 		PIRP p = IoCsqRemoveNextIrp(&devExtension1->CancelSafeQueue, NULL);
8391: 		if (p)
8392: 		{



SYMBOL_STACK_INDEX:  7

SYMBOL_NAME:  usbotgmdrv!cusbcom::asyncincompletion+344

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: usbotgmdrv

IMAGE_NAME:  usbotgmdrv.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  6572e893

STACK_COMMAND:  .thread ; .cxr ; kb

BUCKET_ID_FUNC_OFFSET:  344

FAILURE_BUCKET_ID:  AV_usbotgmdrv!cusbcom::asyncincompletion

BUCKET_ID:  AV_usbotgmdrv!cusbcom::asyncincompletion

PRIMARY_PROBLEM_CLASS:  AV_usbotgmdrv!cusbcom::asyncincompletion

TARGET_TIME:  2023-12-08T09:58:52.000Z

OSBUILD:  22621

OSSERVICEPACK:  0

SERVICEPACK_NUMBER: 0

OS_REVISION: 0

SUITE_MASK:  272

PRODUCT_TYPE:  1

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

OSEDITION:  Windows 10 WinNt TerminalServer SingleUserTS

OS_LOCALE:  

USER_LCID:  0

OSBUILD_TIMESTAMP:  1989-12-11 11:40:12

BUILDDATESTAMP_STR:  231018-1809

BUILDLAB_STR:  ni_release_svc_prod3

BUILDOSVER_STR:  10.0.22621.2506.amd64fre.ni_release_svc_prod3.231018-1809

ANALYSIS_SESSION_ELAPSED_TIME:  1aff

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:av_usbotgmdrv!cusbcom::asyncincompletion

FAILURE_ID_HASH:  {7697af12-d5e3-bec1-22f9-5b89164c1522}

Followup:     MachineOwner
---------
0: kd> p
KDTARGET: Refreshing KD connection

*** Fatal System Error: 0x00000139
					(0x000000000000000A,0x0000000000000000,0x0000000000000000,0x0000000000000000)


Connected to Windows 10 22621 x64 target at (Fri Dec  8 11:11:19.699 2023 (UTC + 1:00)), ptr64 TRUE
Loading Kernel Symbols
...............................................................
................................................................
.......................................................
Loading User Symbols
........................................................
Loading unloaded module list
.............
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 139, {a, 0, 0, 0}

*** ERROR: Module load completed but symbols could not be loaded for testpanel.exe
Probably caused by : usbotgmdrv.sys ( usbotgmdrv!cusbcom::MixerSet+115 )

Followup:     MachineOwner
---------

nt!DbgBreakPointWithStatus:
fffff802`54620960 cc              int     3
0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

KERNEL_SECURITY_CHECK_FAILURE (139)
A kernel component has corrupted a critical data structure.  The corruption
could potentially allow a malicious user to gain control of this machine.
Arguments:
Arg1: 000000000000000a, Type of memory safety violation
Arg2: 0000000000000000, Address of the trap frame for the exception that caused the bugcheck
Arg3: 0000000000000000, Address of the exception record for the exception that caused the bugcheck
Arg4: 0000000000000000, Reserved

Debugging Details:
------------------


KEY_VALUES_STRING: 1


STACKHASH_ANALYSIS: 1

TIMELINE_ANALYSIS: 1


DUMP_CLASS: 1

DUMP_QUALIFIER: 0

BUILD_VERSION_STRING:  22621.2506.amd64fre.ni_release_svc_prod3.231018-1809

DUMP_TYPE:  0

BUGCHECK_P1: a

BUGCHECK_P2: 0

BUGCHECK_P3: 0

BUGCHECK_P4: 0

TRAP_FRAME:  0000000000000000 -- (.trap 0x0)

EXCEPTION_RECORD:  0000000000000000 -- (.exr 0x0)
Cannot read Exception record @ 0000000000000000

CPU_COUNT: 4

CPU_MHZ: c79

CPU_VENDOR:  GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 3c

CPU_STEPPING: 3

CPU_MICROCODE: 6,3c,3,0 (F,M,S,R)  SIG: 28'00000000 (cache) 28'00000000 (init)

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

BUGCHECK_STR:  0x139

PROCESS_NAME:  testpanel.exe

CURRENT_IRQL:  0

ANALYSIS_SESSION_HOST:  PC-562

ANALYSIS_SESSION_TIME:  12-08-2023 11:11:36.0115

ANALYSIS_VERSION: 10.0.17763.1 amd64fre

LAST_CONTROL_TRANSFER:  from fffff80254766882 to fffff80254620960

STACK_TEXT:  
ffff820c`fac75a48 fffff802`54766882 : ffff820c`fac75bb0 fffff802`5451afa0 fffff802`4e5f3180 00000000`00000001 : nt!DbgBreakPointWithStatus
ffff820c`fac75a50 fffff802`54765f43 : fffff802`00000003 ffff820c`fac75bb0 fffff802`5462fc70 00000000`00000139 : nt!KiBugCheckDebugBreak+0x12
ffff820c`fac75ab0 fffff802`54616a87 : 00000000`00000000 00000000`00000000 000001ee`4cb39540 ffffede0`2af5118b : nt!KeBugCheck2+0xba3
ffff820c`fac76220 fffff802`546216be : 00000000`00000139 00000000`0000000a 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx+0x107
ffff820c`fac76260 fffff802`54536103 : ffff820c`fac762d8 fffff802`607e581f 00000000`00000010 00000000`00000284 : nt!guard_icall_bugcheck+0x1e
ffff820c`fac76290 fffff802`607e5825 : 00000000`00000000 000001ee`4cb39540 ffff820c`fac763c0 00000000`00000000 : nt!IoCsqRemoveNextIrp+0x33
ffff820c`fac762c0 fffff802`607f71d8 : ffffa300`00000000 00000000`000009d2 ffff850e`14292680 00000000`00001001 : usbotgmdrv!cusbcom::MixerSet+0x115 [d:\work\common.cpp @ 2078] 
ffff820c`fac76580 fffff802`607f7461 : ffff850e`0c8119b0 ffff850e`14292680 ffff850e`12260c10 ffff850e`0c30b000 : usbotgmdrv!Do_MixerIO+0x128 [d:\work\currentsources\iewdm\usb_2_project\1-comminc\ioctrl.cpp @ 965] 
ffff820c`fac765d0 fffff802`607ec69f : 00000000`0000031f ffff850e`11b0fa20 00000000`00000000 fffff802`60d81723 : usbotgmdrv!WdmIoCall+0x71 [d:\work\currentsources\iewdm\usb_2_project\1-comminc\ioctrl.cpp @ 1015] 
ffff820c`fac76600 fffff802`544ec015 : ffff820c`fac766e0 00000000`00000000 ffff850e`11b0fa20 ffff850e`0c802000 : usbotgmdrv!DispatchControl+0xff [d:\work\currentsources\iewdm\usb_2_project\1-multifunc\driverentry.cpp @ 871] 
ffff820c`fac76650 fffff802`60d81415 : ffff850e`11b0fa20 ffff820c`fac766e0 ffff850e`11b0ff70 ffff850e`112f6d30 : nt!IofCallDriver+0x55
ffff820c`fac76690 fffff802`60d81133 : ffff850e`11b0fa20 00000000`00000002 00000000`00000000 ffff850e`0ff8c300 : ksthunk!CKernelFilterDevice::DispatchIrp+0xf5
ffff820c`fac766f0 fffff802`544ec015 : 00000000`42536f49 fffff802`54942437 00000000`00000000 00000000`00000500 : ksthunk!CKernelFilterDevice::DispatchIrpBridge+0x13
ffff820c`fac76720 fffff802`54940080 : ffff850e`11b0fa20 00000000`00000002 ffff850e`124a7b80 ffff850e`124a7b80 : nt!IofCallDriver+0x55
ffff820c`fac76760 fffff802`54941ab0 : ffff850e`11b0fa20 00000000`00000080 ffff820c`fac76b05 ffff850e`124a7b80 : nt!IopSynchronousServiceTail+0x1d0
ffff820c`fac76810 fffff802`54941396 : ffffa300`871de9a0 00000000`00000001 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0x700
ffff820c`fac76a00 fffff802`5462b6e8 : 0000006e`0000003e 00000144`0000004d ffffe8fb`0eb94694 00000000`000702d6 : nt!NtDeviceIoControlFile+0x56
ffff820c`fac76a70 00007ffe`1e44f454 : 00007ffe`1b8a664b 00000000`00000000 00000000`00000003 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x28
000000d8`fc0feed8 00007ffe`1b8a664b : 00000000`00000000 00000000`00000003 00000000`00000000 000000d8`fc0fefa9 : ntdll!NtDeviceIoControlFile+0x14
000000d8`fc0feee0 00007ffe`1cda27f1 : 00000000`002a3bb8 000001ee`4c9107d0 00000000`00000000 00007ff6`759968b0 : KERNELBASE!DeviceIoControl+0x6b
000000d8`fc0fef50 00007ff6`759bbc31 : 00007ff6`75c2fab0 00000000`00000000 00000000`00000000 000001ee`4c9107d0 : KERNEL32!DeviceIoControlImplementation+0x81
000000d8`fc0fefa0 00007ff6`75c2fab0 : 00000000`00000000 00000000`00000000 000001ee`4c9107d0 000000d8`fc0feff0 : testpanel+0x11bc31
000000d8`fc0fefa8 00000000`00000000 : 00000000`00000000 000001ee`4c9107d0 000000d8`fc0feff0 000000d6`00000080 : testpanel+0x38fab0


THREAD_SHA1_HASH_MOD_FUNC:  b71ff00aaaf4c4ad4a5f16e0d459f8afb7b5bbc9

THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  d5d049b00f6e22d14e9de669ff9e651581b96afe

THREAD_SHA1_HASH_MOD:  84580b37206fa18d6affcbb13778ba1e046533ec

FOLLOWUP_IP: 
usbotgmdrv!cusbcom::MixerSet+115 [d:\work\common.cpp @ 2078]
fffff802`607e5825 4c8bf0          mov     r14,rax

FAULT_INSTR_CODE:  48f08b4c

FAULTING_SOURCE_LINE:  d:\work\common.cpp

FAULTING_SOURCE_FILE:  d:\work\common.cpp

FAULTING_SOURCE_LINE_NUMBER:  2078

FAULTING_SOURCE_CODE:  
2074: 	{

2078: 		PIRP p = IoCsqRemoveNextIrp(&devExtension1->CancelSafeQueue, NULL);
2079: 		if (p)
2080: 		{



SYMBOL_STACK_INDEX:  6

SYMBOL_NAME:  usbotgmdrv!cusbcom::MixerSet+115

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: usbotgmdrv

IMAGE_NAME:  usbotgmdrv.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  6572eb74

STACK_COMMAND:  .thread ; .cxr ; kb

BUCKET_ID_FUNC_OFFSET:  115

FAILURE_BUCKET_ID:  0x139_a_GUARD_ICALL_CHECK_FAILURE_usbotgmdrv!cusbcom::MixerSet

BUCKET_ID:  0x139_a_GUARD_ICALL_CHECK_FAILURE_usbotgmdrv!cusbcom::MixerSet

PRIMARY_PROBLEM_CLASS:  0x139_a_GUARD_ICALL_CHECK_FAILURE_usbotgmdrv!cusbcom::MixerSet

TARGET_TIME:  2023-12-08T10:11:39.000Z

OSBUILD:  22621

OSSERVICEPACK:  0

SERVICEPACK_NUMBER: 0

OS_REVISION: 0

SUITE_MASK:  272

PRODUCT_TYPE:  1

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

OSEDITION:  Windows 10 WinNt TerminalServer SingleUserTS

OS_LOCALE:  

USER_LCID:  0

OSBUILD_TIMESTAMP:  1989-12-11 11:40:12

BUILDDATESTAMP_STR:  231018-1809

BUILDLAB_STR:  ni_release_svc_prod3

BUILDOSVER_STR:  10.0.22621.2506.amd64fre.ni_release_svc_prod3.231018-1809

ANALYSIS_SESSION_ELAPSED_TIME:  1b95

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:0x139_a_guard_icall_check_failure_usbotgmdrv!cusbcom::MixerSet

FAILURE_ID_HASH:  {24ee6655-1688-934c-6cb1-84da9d98800a}

Followup:     MachineOwner
---------

We need to see your CODE. The common thread in your dumps here is that your device extension pointer is NULL (or garbage), leading me to believe that you have configured the CSQ incorrectly.

Thanks Tim,

I will try to reduce and explain the relevant code to a minimal.

I have a “DriverEntry.cpp” which includes “Driver.h”
Driver.h has the declararion of the Csamp functions and also the declaration of the DeviceExtention.
In AddDevice I do the init of the queue and the spin lock etc. See above code which I aleady posted.

The CsampXXX code is taken 1:1 from here:
https://github.com/microsoft/Windows-driver-samples/blob/main/general/cancel/sys/cancel.cpp

typedef struct _DEVICE_EXTENSION {
	ULONG flags;							// flags
	LONG handles;							// # open handles
	PDEVICE_OBJECT DeviceObject;			// device object this extension belongs to
	PDEVICE_OBJECT LowerDeviceObject;		// next lower driver in same stack
	PDEVICE_OBJECT Pdo;						// the PDO

	PDRIVER_OBJECT DriverObject;			// our own driver object
	IO_REMOVE_LOCK RemoveLock;				// removal control locking structure
	UNICODE_STRING devname;					// name of this device
	DEVSTATE state;							// current state of device
	DEVSTATE prevstate;						// state prior to removal query
	DEVICE_POWER_STATE devpower;			// current device power state
	SYSTEM_POWER_STATE syspower;			// current system power state
	DEVICE_CAPABILITIES devcaps;			// copy of most recent device capabilities

	LIST_ENTRY   PendingIrpQueue;
	//  SpinLock to protect access to the queue
	KSPIN_LOCK QueueLock;
	IO_CSQ CancelSafeQueue;
	KSEMAPHORE IrpQueueSemaphore;

} DEVICE_EXTENSION, *PDEVICE_EXTENSION;

	VOID
CsampInsertIrp(
	_In_ PIO_CSQ   Csq,
	_In_ PIRP      Irp
);

VOID
CsampRemoveIrp(
	_In_  PIO_CSQ Csq,
	_In_  PIRP    Irp
);

PIRP
CsampPeekNextIrp(
	_In_  PIO_CSQ Csq,
	_In_  PIRP    Irp,
	_In_  PVOID   PeekContext
);

_IRQL_raises_(DISPATCH_LEVEL)
_IRQL_requires_max_(DISPATCH_LEVEL)
_Acquires_lock_(CONTAINING_RECORD(Csq, DEVICE_EXTENSION, CancelSafeQueue)->QueueLock)
VOID
CsampAcquireLock(
	_In_                                   PIO_CSQ Csq,
	_Out_ _At_(*Irql, _Post_ _IRQL_saves_) PKIRQL  Irql
);

_IRQL_requires_(DISPATCH_LEVEL)
_Releases_lock_(CONTAINING_RECORD(Csq, DEVICE_EXTENSION, CancelSafeQueue)->QueueLock)
VOID
CsampReleaseLock(
	_In_                    PIO_CSQ Csq,
	_In_ _IRQL_restores_    KIRQL   Irql
);

VOID
CsampCompleteCanceledIrp(
	_In_  PIO_CSQ             pCsq,
	_In_  PIRP                Irp
);

In DriverEntry.cpp my functions look like this:

VOID CsampInsertIrp(
	_In_ PIO_CSQ   Csq,
	_In_ PIRP      Irp
)
{
	PDEVICE_EXTENSION   devExtension;

	//BREAK_ONCE;
	devExtension = CONTAINING_RECORD(Csq,
		DEVICE_EXTENSION, CancelSafeQueue);

	InsertTailList(&devExtension->PendingIrpQueue,
		&Irp->Tail.Overlay.ListEntry);

}

VOID CsampRemoveIrp(
	_In_  PIO_CSQ Csq,
	_In_  PIRP    Irp
)
{
	UNREFERENCED_PARAMETER(Csq);
	//BREAK_ONCE;

	RemoveEntryList(&Irp->Tail.Overlay.ListEntry);
}

PIRP CsampPeekNextIrp(
	_In_  PIO_CSQ Csq,
	_In_  PIRP    Irp,
	_In_  PVOID   PeekContext
)
{
	PDEVICE_EXTENSION      devExtension;
	PIRP                    nextIrp = NULL;
	PLIST_ENTRY             nextEntry;
	PLIST_ENTRY             listHead;
	PIO_STACK_LOCATION     irpStack;

	//BREAK_ONCE;
	devExtension = CONTAINING_RECORD(Csq,
		DEVICE_EXTENSION, CancelSafeQueue);

	listHead = &devExtension->PendingIrpQueue;

	//
	// If the IRP is NULL, we will start peeking from the listhead, else
	// we will start from that IRP onwards. This is done under the
	// assumption that new IRPs are always inserted at the tail.
	//

	if (Irp == NULL) {
		nextEntry = listHead->Flink;
	}
	else {
		nextEntry = Irp->Tail.Overlay.ListEntry.Flink;
	}

	while (nextEntry != listHead) {

		nextIrp = CONTAINING_RECORD(nextEntry, IRP, Tail.Overlay.ListEntry);

		irpStack = IoGetCurrentIrpStackLocation(nextIrp);

		//
		// If context is present, continue until you find a matching one.
		// Else you break out as you got next one.
		//

		if (PeekContext) {
			if (irpStack->FileObject == (PFILE_OBJECT)PeekContext) {
				break;
			}
		}
		else {
			break;
		}
		nextIrp = NULL;
		nextEntry = nextEntry->Flink;
	}

	return nextIrp;

}

_IRQL_raises_(DISPATCH_LEVEL)
_IRQL_requires_max_(DISPATCH_LEVEL)
_Acquires_lock_(CONTAINING_RECORD(Csq, DEVICE_EXTENSION, CancelSafeQueue)->QueueLock)
VOID CsampAcquireLock(
	_In_                                PIO_CSQ Csq,
	_Out_ _At_(*Irql, _Post_ _IRQL_saves_)     PKIRQL  Irql
)
{
	PDEVICE_EXTENSION   devExtension;
	//BREAK_ONCE;
	devExtension = CONTAINING_RECORD(Csq,
		DEVICE_EXTENSION, CancelSafeQueue);
	//
	// Suppressing because the address below csq is valid since it's
	// part of DEVICE_EXTENSION structure.
	//
#pragma prefast(suppress: __WARNING_BUFFER_UNDERFLOW, "Underflow using expression 'devExtension->QueueLock'")
	KeAcquireSpinLock(&devExtension->QueueLock, Irql);
}

//
// CsampReleaseLock modifies the execution level of the current processor.
//
// KeReleaseSpinLock assumes we already hold the spin lock and are therefore
// running at Dispatch level.  It will use the Irql parameter saved in a
// previous call to KeAcquireSpinLock to return the thread back to it's original
// execution level.
//
// The annotations reflect these changes and requirments.
//

_IRQL_requires_(DISPATCH_LEVEL)
_Releases_lock_(CONTAINING_RECORD(Csq, DEVICE_EXTENSION, CancelSafeQueue)->QueueLock)
VOID CsampReleaseLock(
	_In_                    PIO_CSQ Csq,
	_In_ _IRQL_restores_    KIRQL   Irql
)
{
	PDEVICE_EXTENSION   devExtension;
	//BREAK_ONCE;
	devExtension = CONTAINING_RECORD(Csq,
		DEVICE_EXTENSION, CancelSafeQueue);
	//
	// Suppressing because the address below csq is valid since it's
	// part of DEVICE_EXTENSION structure.
	//
#pragma prefast(suppress: __WARNING_BUFFER_UNDERFLOW, "Underflow using expression 'devExtension->QueueLock'")
	KeReleaseSpinLock(&devExtension->QueueLock, Irql);
}

VOID CsampCompleteCanceledIrp(
	_In_  PIO_CSQ             pCsq,
	_In_  PIRP                Irp
)
{

	UNREFERENCED_PARAMETER(pCsq);
	//BREAK_ONCE;
	Irp->IoStatus.Status = STATUS_CANCELLED;
	Irp->IoStatus.Information = 0;

	IoCompleteRequest(Irp, IO_NO_INCREMENT);
}

In DriverEntry.cpp my PnpDispatch looks like this:

NTSTATUS DispatchPnp(PDEVICE_OBJECT DeviceObject, PIRP Irp)
	{							// DispatchPnp
	PAGED_CODE();
	KOUT(("\nPnp*[%X] ",DeviceObject));
	
	PCOMMON_EXTENSION pcx = (PCOMMON_EXTENSION) DeviceObject->DeviceExtension;
	//DbgPrintEx(DPFLTR_IHVAUDIO_ID, 0, "%s %X %d\n", __FUNCTION__, pcx, pcx->flags);
	if (pcx->flags & ISPDO)
		return DispatchPnpPdo(DeviceObject, Irp);
	else
		return DispatchPnpFdo(DeviceObject, Irp);
	}	

Now from within the DispatchPnPFdo I get the call to HandleStartDevice, // IRP_MN_START_DEVICE

Here I pass my DeviceObject into my part of CODE where I hande the USB stuff: cusbcom

In cusbcom I hold a pointer to the DeviceObject from “DispatchPnp”.

I hope this will help enough to understand what I’m doing.

Regards,
K. Weller

I hope this will help enough to understand what I’m doing.

No, actually, it’s not. My theory is that, somehow, you are calling CSQ functions through your CancelSafeQueue object before you have initialized it. That’s why I wanted to see the code where you initialize the CSQ.

Well this peace of CODE I have already posted. And as I said. If I use this code “directly” in my DispatchControl with manualy with a user mode software, it works exactly how it should work. Pending, Completing. Cleanup. Nice an smooth… Also my deviceExtention, I have a pointer in this one I init a bit later compared to the CSQ but this pointer is defently valid and usable. So either I use the QSC and it is out of scope (why ever, this I was hoping someone can see here) or I just have in on the stack and did not created it or what ever.

Again the part in my AddDevice

DriverObject->DriverExtension->AddDevice = AddDevice;

status = IoCreateDevice(DriverObject, xsize, NULL, FILE_DEVICE_UNKNOWN, FILE_DEVICE_SECURE_OPEN, FALSE, &fdo);

PDEVICE_EXTENSION pdx = (PDEVICE_EXTENSION) fdo->DeviceExtension;

KeInitializeSpinLock(&pdx->QueueLock);

KeInitializeSemaphore(&pdx->IrpQueueSemaphore, 0, MAXLONG);

//
// Initialize the pending Irp devicequeue
//

InitializeListHead(&pdx->PendingIrpQueue);

// IO Cacnle save queue
**status = IoCsqInitialize(&pdx->CancelSafeQueue, **
CsampInsertIrp,
CsampRemoveIrp,
CsampPeekNextIrp,
CsampAcquireLock,
CsampReleaseLock,
CsampCompleteCanceledIrp);