An APC sent to the wrong thread??!!

I have a thread that has two irps listed in the irplist, which would mean they are synchronous right?
I have a failure in an kernel APC queued to the thread… The irp appears to be completed… can this happen i.e a stale APC is queued to a wrong thread
0: kd> !thread
THREAD ffffe00001588880 Cid 156c.15e8 Teb: 000000007e7cc000 Win32Thread: fffff90141d92010 RUNNING on processor 0
IRP List:
ffffe00000ed1b40: (0006,04c0) Flags: 00060000 Mdl: 00000000 <– suspicious
ffffe000012faab0: (0006,04c0) Flags: 00060030 Mdl: 00000000
Not impersonating
DeviceMap ffffc00009d75500
Owning Process ffffe000021c2080 Image: dxdiag.exe
Attached Process N/A Image: N/A
Wait Start TickCount 241264 Ticks: 0
Context Switch Count 1324 IdealProcessor: 7
UserTime 00:00:00.343
KernelTime 00:00:00.656
Win32 Start Address 0x0000000000ce178f
Stack Init ffffd000239dac90 Current ffffd000239d9770
Base ffffd000239db000 Limit ffffd000239d5000 Call 0

0: kd> !irp ffffe00000ed1b40 <-------- This is in the IRP from the irp list but the thread is different
Irp is active with 11 stacks 13 is current (= 00000000)
No Mdl: No System Buffer: Thread fffff8010faea0d0 <—: Irp is completed. Pending has been returned
cmd flg cl Device File Completion-Context
[0, 0] 0 2 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000

[f, 0] 0 2 ffffe00007482050 00000000 00000000-00000000
\Driver\usbehci
Args: 00000000 00000000 00000000 00000000 <<------------ File object is NULL and event objct is NULL

0: kd> !irp ffffe000012faab0 <---------- This is a good irp with the same thread
Irp is active with 7 stacks 6 is current (= 0xffffe000012face8)
No Mdl: System buffer=ffffe000032e5010: Thread ffffe00001588880: Irp stack trace.
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

!apc thre ffffe00001588880
Thread ffffe00001588880 ApcStateIndex 0 ApcListHead ffffe00001588918 [KERNEL]
Thread ffffe00001588880 ApcStateIndex 0 ApcListHead ffffe00001588928 [USER]

This is caused by STATUS_PENDING returned and IoMarkIrpPending mismatch in some driver.

Thanks a lot Alex.
The IRQL is dispatch level. I imagine the bugcheck can raise it to that level, right?
The thread that shows up with the irp is not a thread at all. Could this mean a thread that died and the irp being completed in the context of this thread

: kd> !irp ffffe00000ed1b40
Irp is active with 11 stacks 13 is current (= 00000000)
No Mdl: No System Buffer: Thread fffff8010faea0d0 <—: This is not a thread at all.
Pending has been returned and the cancel flag is set. The user event looks garbled and all fields zeroed in the irp.

I was doubting this too. I need to look at the filter drivers in the stack!

Thanks again for your help.

Are you actually getting a bugcheck, or what?

Yes it is a bugcheck IRQL_NOT_LESS_OR_EQUAL (a)

f a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000000000000000, 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: fffff8010faeb03a, address which referenced memory

FAULTING_IP:
nt!IoFreeIrp+f76
fffff801`0faeb03a 488b00 mov rax,qword ptr [rax]

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: AV

LAST_CONTROL_TRANSFER: from fffff8010fbe2ba9 to fffff8010fbd6fa0

STACK_TEXT:
ffffd000239d9a68 fffff8010fbe2ba9 : 000000000000000a 0000000000000000 0000000000000002 0000000000000000 : nt!KeBugCheckEx
ffffd000239d9a70 fffff8010fbe13fa : 0000000000000000 ffffe00000ed1b40 ffffd00000000000 ffffd000239d9bb0 : nt!setjmpex+0x38a9
ffffd000239d9bb0 fffff8010faeb03a : 0000000000000000 0000000000000002 0000000000000000 0000000000000000 : nt!setjmpex+0x20fa
ffffd000239d9d40 fffff8010fb35d06 : ffffd000239d9e00 fffff8010fbe1417 0000000000000001 ffffc00000acfff0 : nt!IoFreeIrp+0xf76
ffffd000239d9e20 fffff8010fbdbd23 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KeRemoveQueueEx+0x2a06
ffffd000239d9ea0 fffff8010fe707ba : ffffc0000002a000 ffffe000002f34d0 ffffc0000002a000 ffffc0000002a000 : nt!KeSynchronizeExecution+0x4133
ffffd000239da030 fffff8010fe7067f : ffffc00003128b98 ffffc0000002a000 0000000000000000 fffff8010fe1dece : nt!FsRtlReleaseFile+0xab6
ffffd000239da0c0 fffff8010fe7320a : 01ce882f7a7bb0bc ffffd000239da1e1 ffffc00003128b98 0000000000000000 : nt!FsRtlReleaseFile+0x97b
ffffd000239da120 fffff8010fe73bb5 : ffffc0000e4fba60 ffffd000239da280 ffffc00000000003 ffffc0000e5ebde0 : nt!FsRtlReleaseFile+0x3506
ffffd000239da230 fffff8010fbe2873 : ffffc0000e3fd170 fffff8010fd162c6 ffffd000239da300 ffffd000239da450 : nt!FsRtlReleaseFile+0x3eb1
ffffd000239da3b0 fffff8010fbdac00 : fffff800051e104a ffffc00005cb6650 0000000000000077 ffffd000239da6c0 : nt!setjmpex+0x3573
ffffd000239da5b8 fffff800051e104a : ffffc00005cb6650 0000000000000077 ffffd000239da6c0 00000000000007ff : nt!KeSynchronizeExecution+0x3010
ffffd000239da5c0 fffff80002e944b5 : ffffe000020da2c0 ffffe000012faab0 0000000000000001 0000000000000000 : MSKSSRV+0x204a
ffffd000239da720 fffff80002e9401b : ffffe000000000d6 0000000000000001 fffff800051e0160 fffff8000361d631 : ks!KsPropertyHandler+0x4b5
ffffd000239da790 fffff800051e1361 : ffffe000012faab0 ffffe000012fad30 ffffd000239da880 ffffd000239da880 : ks!KsPropertyHandler+0x1b
ffffd000239da7e0 fffff8000361c7d7 : ffffe000012faab0 ffffd000239da860 ffffe000012fad30 ffffe00000917cc0 : MSKSSRV+0x2361
ffffd000239da810 fffff8010fe6a146 : 0000000000000000 ffffe000012faab0 ffffe00000000000 0000000000000001 : ksthunk+0x7d7
ffffd000239da870 fffff8010fe69922 : ffffd000239daa38 0000000000000000 0000000000000001 00000000004cef8c : nt!NtDeviceIoControlFile+0x87a
ffffd000239daa20 fffff8010fbe2873 : ffffe00001588880 ffffd000001f0003 000000000048df48 fffff80100000000 : nt!NtDeviceIoControlFile+0x56
ffffd000239daa90 00000000772a2772 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!setjmpex+0x3573
000000000048e848 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x772a2772

You need to specify the symbols for the kernel in the debugger. Use Microsoft symbol server.

ffffd000239d9a68 fffff8010fbe2ba9 : 000000000000000a 0000000000000000 0000000000000002 0000000000000000 : nt!KeBugCheckEx
ffffd000239d9a70 fffff8010fbe13fa : 0000000000000000 ffffe00000ed1b40 ffffd00000000000 ffffd000239d9bb0 : nt!KiBugCheckDispatch+0x69
ffffd000239d9bb0 fffff8010faeb03a : 0000000000000000 0000000000000002 0000000000000000 0000000000000000 : nt!KiPageFault+0x23a
ffffd000239d9d40 fffff8010fb35d06 : ffffd000239d9e00 fffff8010fbe1417 0000000000000001 ffffc00000acfff0 : nt!IopCompleteRequest+0xf6a
ffffd000239d9e20 fffff8010fbdbd23 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiDeliverApc+0x136
ffffd000239d9ea0 fffff8010fe707ba : ffffc0000002a000 ffffe000002f34d0 ffffc0000002a000 ffffc0000002a000 : nt!KiApcInterrupt+0xc3
ffffd000239da030 fffff8010fe7067f : ffffc00003128b98 ffffc0000002a000 0000000000000000 fffff8010fe1dece : nt!CmpReportNotifyHelper+0xae
ffffd000239da0c0 fffff8010fe7320a : 01ce882f7a7bb0bc ffffd000239da1e1 ffffc00003128b98 0000000000000000 : nt!CmpReportNotify+0x57
ffffd000239da120 fffff8010fe73bb5 : ffffc0000e4fba60 ffffd000239da280 ffffc00000000003 ffffc0000e5ebde0 : nt!CmSetValueKey+0x41e
ffffd000239da230 fffff8010fbe2873 : ffffc0000e3fd170 fffff8010fd162c6 ffffd000239da300 ffffd000239da450 : nt!NtSetValueKey+0x525
ffffd000239da3b0 fffff8010fbdac00 : fffff800051e104a ffffc00005cb6650 0000000000000077 ffffd000239da6c0 : nt!KiSystemServiceCopyEnd+0x13
ffffd000239da5b8 fffff800051e104a : ffffc00005cb6650 0000000000000077 ffffd000239da6c0 00000000000007ff : nt!KiServiceLinkage
ffffd000239da5c0 fffff80002e944b5 : ffffe000020da2c0 ffffe000012faab0 0000000000000001 0000000000000000 : MSKSSRV!PropertySrv+0x2da
ffffd000239da720 fffff80002e9401b : ffffe000000000d6 0000000000000001 fffff800051e0160 fffff8000361d631 : ks!KspPropertyHandler+0x495
ffffd000239da790 fffff800051e1361 : ffffe000012faab0 ffffe000012fad30 ffffd000239da880 ffffd000239da880 : ks!KsPropertyHandler+0x1b
ffffd000239da7e0 fffff8000361c7d7 : ffffe000012faab0 ffffd000239da860 ffffe000012fad30 ffffe00000917cc0 : MSKSSRV!SrvDispatchIoControl+0x39
ffffd000239da810 fffff8010fe6a146 : 0000000000000000 ffffe000012faab0 ffffe00000000000 0000000000000001 : ksthunk!CKernelFilterDevice::DispatchIrp+0x10f
ffffd000239da870 fffff8010fe69922 : ffffd000239daa38 0000000000000000 0000000000000001 00000000004cef8c : nt!IopXxxControlFile+0x816
ffffd000239daa20 fffff8010fbe2873 : ffffe00001588880 ffffd000001f0003 000000000048df48 fffff80100000000 : nt!NtDeviceIoControlFile+0x56
ffffd000239daa90 00000000772a2772 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13

What kind of driver are you developing and debugging? Show your dispatch and completion routines.