BSOD on killing process holding DirectShow/AVStream circuit

We have created 2 (pin-oriented) AVStream kernel filters: one that acts as a producer of video-data and the other as a consumer. We have also created a test-application which creates 4 graphs and each graph holds such a producer feeding directly into a consumer. When nicely stopping all graphs and releasing the involved objects before exiting this application, there is no problem. However if the application is killed or it terminates without nice cleanup, we get a BSOD.

I’ve included the crash analysis and some possibly useful additional input below.

Now, this does not happen if I just insert a non-AVStream in-place transform filter - that does nothing - in between the producer and the consumer in each graph. If I understand the various info I found on the Internet correctly, I guess this means that we only hit this if we have a closed AVStream circuit between our two components.

Can anyone offer information on what we could be doing wrong here? All actions on our internal structures are guarded with spinlocks/mutexes and we also don’t get any problems with access to those. So, is there any condition in which we should not be calling KsStreamPointerDelete for a KSSTREAM_POINTER that we acquired with KsStreamPointerClone (from a KSSTREAM_POINTER which was locked) or is there some extra synchronization needed?

Thanks in advance for all your input!

*******************************************************************************
* *
* 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: 0000000000000048, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, 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: fffff80002ec7365, address which referenced memory

Debugging Details:

DUMP_CLASS: 1

DUMP_QUALIFIER: 0

BUILD_VERSION_STRING: 7601.23796.amd64fre.win7sp1_ldr.170427-1518

DUMP_TYPE: 0

BUGCHECK_P1: 48

BUGCHECK_P2: 2

BUGCHECK_P3: 1

BUGCHECK_P4: fffff80002ec7365

WRITE_ADDRESS: 0000000000000048

CURRENT_IRQL: 2

FAULTING_IP:
nt!KeAcquireSpinLockRaiseToDpc+55
fffff800`02ec7365 f0480fba2900 lock bts qword ptr [rcx],0

CPU_COUNT: c

CPU_MHZ: ce2

CPU_VENDOR: GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 3f

CPU_STEPPING: 2

CPU_MICROCODE: 6,3f,2,0 (F,M,S,R) SIG: 38’00000000 (cache) 38’00000000 (init)

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: System

ANALYSIS_SESSION_HOST: KNDCLT20376

ANALYSIS_SESSION_TIME: 11-24-2017 14:05:32.0610

ANALYSIS_VERSION: 10.0.10586.567 amd64fre

TRAP_FRAME: fffff88002f1b620 – (.trap 0xfffff88002f1b620)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000002 rbx=0000000000000000 rcx=0000000000000048
rdx=fffffa800fe2def0 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002ec7365 rsp=fffff88002f1b7b0 rbp=0000000000000048
r8=fffffa80208e6900 r9=0000000000000000 r10=fffff80002e4e000
r11=0000000000000002 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
nt!KeAcquireSpinLockRaiseToDpc+0x55:
fffff80002ec7365 f0480fba2900 lock bts qword ptr [rcx],0 ds:0000000000000048=???
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80002faf4a2 to fffff80002eb52f0

STACK_TEXT:
fffff88002f1ad68 fffff80002faf4a2 : 0000000000000048 fffff880009fd1c0 0000000000000065 fffff80002ef9bfc : nt!DbgBreakPointWithStatus
fffff88002f1ad70 fffff80002fb028e : 0000000000000003 0000000000000000 fffff80002efa460 000000000000000a : nt!KiBugCheckDebugBreak+0x12
fffff88002f1add0 fffff80002ebd5c4 : 0000000000000001 fffff880013ae17b 0000000000000000 fffff80002f398f2 : nt!KeBugCheck2+0x71e
fffff88002f1b4a0 fffff80002ebca69 : 000000000000000a 0000000000000048 0000000000000002 0000000000000001 : nt!KeBugCheckEx+0x104
fffff88002f1b4e0 fffff80002ebb6e0 : 0000000000005200 fffff80002eb1ecc 00000000000052f6 0000000000000002 : nt!KiBugCheckDispatch+0x69
fffff88002f1b620 fffff80002ec7365 : fffff880009f2100 0000000000000000 fffff88002f1b901 00000000000bb800 : nt!KiPageFault+0x260
fffff88002f1b7b0 fffff88004a51850 : fffffa800e3c5102 fffff88004a4cea1 0000000000000000 fffffa800fe2def0 : nt!KeAcquireSpinLockRaiseToDpc+0x55
fffff88002f1b800 fffff88004a4cea1 : fffffa800fe2db08 fffffa800d579402 fffffa800e3c5102 fffffa800e3c5102 : ks!KsQueueWorkItem+0x24
fffff88002f1b830 fffff88004a4c487 : fffffa800e3c5010 fffffa800d579402 fffffa80208e6920 fffffa800e3c5010 : ks!CKsPin::Process+0x85
fffff88002f1b860 fffff88004a4c1d1 : fffffa800e3c5010 fffffa800d579408 fffffa800d579320 fffffa80208e6920 : ks!CKsQueue::AddFrame+0x1e7
fffff88002f1b8a0 fffff88004a4b5cc : fffffa8000000000 fffffa800e296a30 fffff88002f1b960 fffffa800ede7f80 : ks!CKsQueue::TransferKsIrp+0x4a1
fffff88002f1b930 fffff88004a4c71f : fffffa800e3c5010 0000000000000000 0000000000000000 fffffa8010b332b8 : ks!KspTransferKsIrp+0x54
fffff88002f1b960 fffff88004a4c7af : fffffa800e296a30 0000000000000002 0000000000000000 00000000020d0102 : ks!CKsQueue::ForwardIrp+0x167
fffff88002f1b9b0 fffff88004a4d17f : fffffa800e296a30 0000000000000000 fffffa800d579320 fffffa801e8d05c0 : ks!CKsQueue::ForwardWaitingIrps+0x5f
fffff88002f1b9e0 fffff88004a4c945 : fffffa801e8d05c0 0000000000000000 0000000000000000 0000000000000000 : ks!CKsQueue::UnlockStreamPointer+0x123
fffff88002f1ba30 fffff880085e5401 : fffffa800ed845f0 0000000000000000 0000057ff127bd00 fffffa801fa623f0 : ks!CKsQueue::DeleteStreamPointer+0xf5
fffff88002f1ba70 fffff880085dd487 : fffffa800ed845f0 fffffa801fa62518 0000057ff127bd08 fffffa801fa62461 : MNA_180_Stream!CEncoderStreamPin::completeFrameDMA+0x85 [d:\devel\compositor3\drivers\avstream\windows\driver\encoderstreampin.cpp @ 584]
fffff88002f1bab0 fffff8800483e9a6 : fffffa800ed845f0 0000057ff1640fd8 0000057ff127bd78 fffffa800ea365d0 : MNA_180_Stream!CMNA1x0Device::dispatchHwISR+0xff [d:\devel\compositor3\drivers\avstream\windows\driver\mna1x0device.cpp @ 720]
fffff88002f1baf0 fffff88000c738a7 : 0000057ff15c9ab8 fffffa800ea36540 fffffa800ea365d0 ffffd3192f2e18e2 : MNA_180+0x29a6
fffff88002f1bb60 fffff80002ec88fc : fffff880009f2180 0000000d88d95ed5 0000000d88d8d675 fffffa800dff7118 : Wdf01000!FxInterrupt::_InterruptDpcThunk+0x8f
fffff88002f1bb90 fffff80002eb51ca : fffff880009f2180 fffff880009fd1c0 0000000000000000 fffff88000c73818 : nt!KiRetireDpcList+0x1bc
fffff88002f1bc40 0000000000000000 : fffff88002f1c000 fffff88002f16000 fffff88002f1bc00 0000000000000000 : nt!KiIdleLoop+0x5a

STACK_COMMAND: kb

THREAD_SHA1_HASH_MOD_FUNC: fd14a5e528caf58e85330912312fa94897419379

THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 3d96cdb641e3210790d6716bf29cc0bcf8ce424f

THREAD_SHA1_HASH_MOD: 61ed7f98d169b2955416919b0bae7fdaffbb49d6

FOLLOWUP_IP:
ks!KsQueueWorkItem+24
fffff880`04a51850 4c8d4f38 lea r9,[rdi+38h]

FAULT_INSTR_CODE: 384f8d4c

SYMBOL_STACK_INDEX: 7

SYMBOL_NAME: ks!KsQueueWorkItem+24

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: ks

IMAGE_NAME: ks.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4ce7a3f3

IMAGE_VERSION: 6.1.7601.17514

FAILURE_BUCKET_ID: X64_0xA_ks!KsQueueWorkItem+24

BUCKET_ID: X64_0xA_ks!KsQueueWorkItem+24

PRIMARY_PROBLEM_CLASS: X64_0xA_ks!KsQueueWorkItem+24

TARGET_TIME: 2017-11-24T12:50:55.000Z

OSBUILD: 7601

OSSERVICEPACK: 1000

SERVICEPACK_NUMBER: 0

OS_REVISION: 0

SUITE_MASK: 336

PRODUCT_TYPE: 1

OSPLATFORM_TYPE: x64

OSNAME: Windows 7

OSEDITION: Windows 7 WinNt (Service Pack 1) TerminalServer EmbeddedNT SingleUserTS

OS_LOCALE:

USER_LCID: 0

OSBUILD_TIMESTAMP: 2017-04-28 02:13:49

BUILDDATESTAMP_STR: 170427-1518

BUILDLAB_STR: win7sp1_ldr

BUILDOSVER_STR: 6.1.7601.23796.amd64fre.win7sp1_ldr.170427-1518

ANALYSIS_SESSION_ELAPSED_TIME: 149f

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:x64_0xa_ks!ksqueueworkitem+24

FAILURE_ID_HASH: {005516bc-4fb8-66d8-b322-cfa8ebdc299a}

Followup: MachineOwner

1: kd> .frame /c 9
09 fffff88002f1b860 fffff88004a4c1d1 ks!CKsQueue::AddFrame+0x1e7
rax=0000000000000002 rbx=fffffa800e3c5010 rcx=0000000000000048
rdx=fffffa800fe2def0 rsi=fffffa800e3c5102 rdi=fffffa80208e6920
rip=fffff88004a4c487 rsp=fffff88002f1b860 rbp=fffffa800d579402
r8=fffffa80208e6900 r9=0000000000000000 r10=fffff80002e4e000
r11=0000000000000002 r12=0000000000000000 r13=fffff88002f1b901
r14=0000000000000000 r15=fffffa800d5793f8
iopl=0 nv up ei ng nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00000282
ks!CKsQueue::AddFrame+0x1e7:
fffff88004a4c487 ebb3 jmp ks!CKsQueue::AddFrame+0x19c (fffff88004a4c43c)
1: kd> !ks.dump @rbx
Queue fffffa800e3c5010:
Frames Received : 2330
Frames Waiting : 1
Frames Cancelled : 0
And Gate fffffa800fe2dec0 : count = 0, next = 0000000000000000
Frame Gate [AND] fffffa800fe2dec0 : count = 0, next = 0000000000000000
Frame Header fffffa80208e6920:
NextFrameHeaderInIrp = 0000000000000000
OriginalIrp = fffffa800d579320
Mdl = fffffa800e51e200
Irp = fffffa800d579320
StreamHeader = fffffa800ede7f48
FrameBuffer = fffff880062fa040
StreamHeaderSize = 00000000
FrameBufferSize = 000bb800
Context = 0000000000000000
Refcount = 1

1: kd> !ks.dump 0xfffffa800d579320
IRP fffffa800d579320 was adjusted to an object fffffa800fe2dc00

Pin object fffffa800fe2dc00 [CKsPin = fffffa800fe2db00]
Descriptor fffff8a00ae610d0
Context fffffa8010b33000
Id 0
Communication Source
DataFlow Out
Interface Standard Interface
Medium Standard Medium
StreamHdr Size 0
DeviceState KSSTATE_RUN
ClientState KSSTATE_RUN
ResetState KSRESET_END

xxxxx@barco.com wrote:

We have created 2 (pin-oriented) AVStream kernel filters: one that acts as a producer of video-data and the other as a consumer. We have also created a test-application which creates 4 graphs and each graph holds such a producer feeding directly into a consumer. When nicely stopping all graphs and releasing the involved objects before exiting this application, there is no problem. However if the application is killed or it terminates without nice cleanup, we get a BSOD.

The usual cause of a problem like this is erroneously cleaning up some
global resource before all of the users of that resource are finished. 
It is interesting that the dump shows you are still in your ISR.  Is
that possible?  You can’t call KeStreamPointerDelete from an IRQL above
DISPATCH_LEVEL.  The dump indicated that you are at DISPATCH_LEVEL, but
that shouldn’t be the case if you are in your ISR.

Did you get a transition out of KSSTATE_RUN before this happened?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Hello Tim,

Thanks for your reply. The name of the dispatchHwISR method is probably somewhat misleading. The actual interrupt is handled by a routine not in the stack here and that triggers a DPC and the function it executes is unfortunately called dispatchHwISR. So indeed, it is running at DISPATCH_LEVEL.

My first idea was also that some synchronization would be missing in cleaning up, but the problem is that I don’t seem to get any indication yet that cleaning up would be needed.

As mentioned, all of this works fine if I just put a non-AVStream filter in between my 2 AVStream filters. As far as I can tell the filter that is calling DeleteStreamPointer did not yet get a transition out of KSSTATE_RUN and if the !ks.dump output that I included is correct, I guess also the filter whose CKsPin::Process is called (am I correct in thinking this is the source filter) is still in KSSTATE_RUN.

I get the impression that here a WorkItem is getting destroyed/de-initialized before the graph or rather the AVStream circuit is stopped. Is there any info on how destruction of such an AVStream circuit is supposed to happen if the user-space process is killed? Are state-changes communicated to the filter and if so, would that be a jump from RUN to STOPPED or go through all the stages? In which order are filters notified of such changes: from source to sink, vice-versa or undefined? We also use Object Bags in both the pin and the filter. As far as I can tell these aren’t triggered yet, but to get a better picture I have some questions on those too: Are the items added to an Object Bag freed in a specific order? Are the items in the Pin’s Object Bag all freed before the items of the Filter’s Object Bag?

Thanks for any additional insight you can give me,
Kurt

xxxxx@barco.com wrote:

I get the impression that here a WorkItem is getting destroyed/de-initialized before the graph or rather the AVStream circuit is stopped.

Certainly some structure that holds a spinlock has been destroyed.  Or,
more accurately, the pointer to that structure has been zeroed.

Is there any info on how destruction of such an AVStream circuit is supposed to happen if the user-space process is killed?

The KSPIN_DISPATCH structure has callbacks for Create and Close, which
map to IRP_MJ_CREATE and IRP_MJ_CLOSE.  You should get a Close callback
when the process is dying.

Are state-changes communicated to the filter and if so, would that be a jump from RUN to STOPPED or go through all the stages?

The Kernel Streaming contract is that it never jumps states, so you
should go from RUN to PAUSE to ACQUIRE to STOP.  There used to be a bug
on one of the old operating systems (2000?) that didn’t follow that
rule, but these days it’s pretty reliable.

However, it shouldn’t move from PAUSE to ACQUIRE until all of the pins
are in PAUSE.  That’s what looks odd here.  Are you disabling your
interrupts when you move out of RUN state?  Or at least setting a flag
to ignore further interrupts?

In which order are filters notified of such changes: from source to sink, vice-versa or undefined?

As far as I know, that’s undefined.  It’s not common to have a source
and a sink share resources, so that isn’t typically important.

We also use Object Bags in both the pin and the filter. As far as I can tell these aren’t triggered yet, but to get a better picture I have some questions on those too: Are the items added to an Object Bag freed in a specific order? Are the items in the Pin’s Object Bag all freed before the items of the Filter’s Object Bag?

Typically, the device holds a reference to the filters, and the filter
holds a reference to the pins, so the filter cannot be destroyed until
all of the pins are destroyed.  But there’s no guarantee between the
pins of filter A and the pins of filter B.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Hi Tim,

I’ve done some more digging, adding traces to the code to verify whether some state-transition might be coming in parallel or before the processing causing the crash. Note that the crash isn’t always from the DMA-handling code. The first call to DeleteStreamPointer triggers the crash. This time this was the stack trace below. Basically my Sink filter is now getting notified of a state-change from RUN to PAUSE, but even at that point already calling DeleteStreamPointer on one of the clone StreamPointers I am holding causes the same wrong reference to a spinlock in CKsPin::Process.

As said, I added tracing info basically keeping track of timestamp, location (file/function/line), this-pointer and CPU-core each time a trace is hit in a circular buffer. My buffer was able to store +/- 1.7s of all actions before the point of the crash. I wanted to add the result of the traces here, but ListManager complained it was too long. Anyway, from the traces I see that basically 4 of the cores are involved in those last seconds. The sink’s input pin is getting a state-change notification (CEncoderStreamPin::dispatchSetState) for going from RUN to PAUSE and the source’s pin has not yet received any indication of a state-change. In handling that transition from RUN to PAUSE, the code attempts to cleanup all the clone StreamPointers we still have got hold off, but that already causes the problem. Those StreamPointers were acquired during the Process callback to the filter, which first executes leading = KsPinGetLeadingEdgeStreamPointer(pin,KSSTREAM_POINTER_STATE_LOCKED); and then after some checks does KsStreamPointerClone(leading,NULL,sizeof(STREAM_POINTER_CONTEXT),&clone); giving us in clone the PKSSTREAM_POINTER which we keep and release either after the DMA is complete or when it needs to be cleaned up (and all those are synchronized with a spinlock and once deleted the clone StreamPointer we have is reset to NULL to avoid double-deleting).

I’m lost at what I could be doing wrong here which causes this problem - and only when the user-space application gets killed and even then only when I have both AVStream filter directly attached to each other, so any further input would be very welcome …

Thanks,
Kurt

10: 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: 0000000000000048, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, 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: fffff80002ec9365, address which referenced memory

Debugging Details:

DUMP_CLASS: 1

DUMP_QUALIFIER: 0

BUILD_VERSION_STRING: 7601.23796.amd64fre.win7sp1_ldr.170427-1518

DUMP_TYPE: 0

BUGCHECK_P1: 48

BUGCHECK_P2: 2

BUGCHECK_P3: 1

BUGCHECK_P4: fffff80002ec9365

WRITE_ADDRESS: 0000000000000048

CURRENT_IRQL: 2

FAULTING_IP:
nt!KeAcquireSpinLockRaiseToDpc+55
fffff800`02ec9365 f0480fba2900 lock bts qword ptr [rcx],0

CPU_COUNT: c

CPU_MHZ: ce2

CPU_VENDOR: GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 3f

CPU_STEPPING: 2

CPU_MICROCODE: 6,3f,2,0 (F,M,S,R) SIG: 38’00000000 (cache) 38’00000000 (init)

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: auto-graph.exe

ANALYSIS_SESSION_HOST: KNDCLT20376

ANALYSIS_SESSION_TIME: 11-29-2017 15:55:04.0879

ANALYSIS_VERSION: 10.0.10586.567 amd64fre

TRAP_FRAME: fffff880098bbec0 – (.trap 0xfffff880098bbec0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000002 rbx=0000000000000000 rcx=0000000000000048
rdx=fffffa800d383ad0 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002ec9365 rsp=fffff880098bc050 rbp=0000000000000048
r8=fffffa800d24d300 r9=0000000000000000 r10=fffff8000304cc20
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz ac po nc
nt!KeAcquireSpinLockRaiseToDpc+0x55:
fffff80002ec9365 f0480fba2900 lock bts qword ptr [rcx],0 ds:0000000000000048=???
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80002fb14a2 to fffff80002eb72f0

STACK_TEXT:
fffff880098bb608 fffff80002fb14a2 : 0000000000000048 fffffa800d68e4e0 0000000000000065 fffff80002efbbfc : nt!DbgBreakPointWithStatus
fffff880098bb610 fffff80002fb228e : 0000000000000003 0000000000000000 fffff80002efc460 000000000000000a : nt!KiBugCheckDebugBreak+0x12
fffff880098bb670 fffff80002ebf5c4 : fffffa800d68e400 fffff8800196ba10 0000000000000002 fffff80002f3b8f2 : nt!KeBugCheck2+0x71e
fffff880098bbd40 fffff80002ebea69 : 000000000000000a 0000000000000048 0000000000000002 0000000000000001 : nt!KeBugCheckEx+0x104
fffff880098bbd80 fffff80002ebd6e0 : fffffa800d4e40b0 fffff8800187cfa0 0004000c0fae3c04 0000000000000000 : nt!KiBugCheckDispatch+0x69
fffff880098bbec0 fffff80002ec9365 : 0000000000000000 fffffa800e098d40 0000000000001000 fffff880080f4079 : nt!KiPageFault+0x260
fffff880098bc050 fffff88004e2a850 : fffffa8010580d00 fffff80002eff828 0000000000000000 fffffa800d383ad0 : nt!KeAcquireSpinLockRaiseToDpc+0x55
fffff880098bc0a0 fffff88004e25ea1 : fffffa800d3836e8 fffffa800d47bd00 fffffa8010580d00 fffffa8010580d00 : ks!KsQueueWorkItem+0x24
fffff880098bc0d0 fffff88004e25487 : fffffa8010580c60 fffffa800d47bd00 fffffa800d24d310 fffffa8010580c60 : ks!CKsPin::Process+0x85
fffff880098bc100 fffff88004e251d1 : fffffa8010580c60 fffffa800d47bd58 fffffa800d47bc70 fffffa800d24d310 : ks!CKsQueue::AddFrame+0x1e7
fffff880098bc140 fffff88004e245cc : fffffa8000000000 fffffa800d64e010 fffff880098bc200 fffffa800d4a89c0 : ks!CKsQueue::TransferKsIrp+0x4a1
fffff880098bc1d0 fffff88004e2571f : fffffa8010580c60 0000000000000000 0000000000000000 fffff88001311e1c : ks!KspTransferKsIrp+0x54
fffff880098bc200 fffff88004e257af : fffffa800d64e010 0000000000000002 0000000000000000 0000000000000000 : ks!CKsQueue::ForwardIrp+0x167
fffff880098bc250 fffff88004e2617f : fffffa800d64e010 0000000000000000 fffffa800d47bc70 fffffa800fd8d010 : ks!CKsQueue::ForwardWaitingIrps+0x5f
fffff880098bc280 fffff88004e25945 : fffffa800fd8d010 0000000000000000 0000000000000000 0000000000000000 : ks!CKsQueue::UnlockStreamPointer+0x123
fffff880098bc2d0 fffff880081afdfd : fffff880098bc340 0000000000000000 0000000000000003 fffff880081b41d0 : ks!CKsQueue::DeleteStreamPointer+0xf5
fffff880098bc310 fffff880081b0305 : fffffa800d378750 0000000000000000 0000000000000003 fffffa800d535b00 : MNA_180_Stream!CEncoderStreamPin::dropAllBuffers+0x205 [d:\devel\compositor3\drivers\avstream\windows\driver\encoderstreampin.cpp @ 767]
fffff880098bc3e0 fffff880081b0652 : fffffa800d535b00 0000000000000000 0000000000000003 0000000000000002 : MNA_180_Stream!CEncoderStreamPin::pausePinHardware+0x1a1 [d:\devel\compositor3\drivers\avstream\windows\driver\encoderstreampin.cpp @ 874]
fffff880098bc420 fffff880081af045 : fffffa800d2911f0 0000000000000003 0000000000000002 0000000000000003 : MNA_180_Stream!CEncoderStreamPin::setState+0x9e [d:\devel\compositor3\drivers\avstream\windows\driver\encoderstreampin.cpp @ 955]
fffff880098bc460 fffff88004e41078 : fffffa800d2910f0 0000000000000002 fffff880098bc5d8 fffffa800e45a180 : MNA_180_Stream!CEncoderStreamPin::dispatchSetState+0x99 [d:\devel\compositor3\drivers\avstream\windows\driver\encoderstreampin.cpp @ 185]
fffff880098bc4a0 fffff88004e408e0 : fffffa800d2912b8 0000000000000002 0000000000000000 fffffa800d34d6a0 : ks!CKsPin::ClientSetDeviceState+0x148
fffff880098bc4e0 fffff88004e40113 : fffffa800d64e010 0000000000000002 0000000000000003 fffff8800146ae84 : ks!CKsPipeSection::DistributeStateChangeToPins+0x70
fffff880098bc520 fffff88004e40a77 : fffffa800d64e010 0000000000000002 0000000000000003 0000000000000000 : ks!CKsQueue::SetDeviceState+0xa3
fffff880098bc570 fffff88004e40771 : fffffa800d48f520 fffffa800d2b92f0 0000000000000000 fffffa800d2b92f0 : ks!CKsPipeSection::DistributeDeviceStateChange+0xab
fffff880098bc5d0 fffff88004e3f487 : fffffa800d3836e0 fffffa800d2b92f0 fffffa800d43f8a0 fffffa800d43f8a0 : ks!CKsPipeSection::SetDeviceState+0x281
fffff880098bc630 fffff88004e3fb1f : fffffa800d3836e0 0000000000000005 fffffa800d43f8a0 fffffa800d281000 : ks!CKsFilter::RemoveProcessPin+0xc7
fffff880098bc670 fffff88004e3e52d : 0000000000000000 fffffa800d43fb20 fffffa800d4c7da0 fffffa800d43f8a0 : ks!CKsPin::DispatchClose+0x12f
fffff880098bc6e0 fffff88004f1b825 : 0000000000000001 fffffa800d4c7da0 fffff880098bc990 0000000000000000 : ks!DispatchClose+0x4d
fffff880098bc710 fffff800031c25ce : fffffa800f10ba50 0000000000000001 fffffa8000000000 fffffa800d43f8a0 : ksthunk!CKernelFilterDevice::DispatchIrp+0x11d
fffff880098bc770 fffff80002ec92a4 : fffff880098bc990 fffffa800f10ba20 fffffa800cdc8990 fffffa800d28a900 : nt!IopDeleteFile+0x11e
fffff880098bc800 fffff800031bc7d1 : fffffa800f10ba20 0000000000000000 fffffa800d68e4e0 0000000000000000 : nt!ObfDereferenceObject+0xd4
fffff880098bc860 fffff8000317abb8 : 00000000000004d4 fffff8a007a5cf90 fffff8a00872a350 00000000000004d4 : nt!ObpCloseHandleTableEntry+0xc1
fffff880098bc8f0 fffff8000317aa90 : 0000000000000404 0000000000000001 fffffa800ced7060 fffff80003165b01 : nt!ObpCloseHandleProcedure+0x30
fffff880098bc930 fffff8000317b32f : fffff8a0086b9a01 0000000000000000 fffffa800ced7060 0000000000000001 : nt!ExSweepHandleTable+0x6c
fffff880098bc970 fffff8000319828d : fffff8a0086b9a30 0000000000000000 0000000000000000 fffffa800fa15090 : nt!ObKillProcess+0x6f
fffff880098bc9b0 fffff8000317aea5 : 00000000c0000005 0000000000000001 000007ffffeea000 0000000000000000 : nt!PspExitThread+0x88d
fffff880098bca70 fffff80002ebe753 : ffffffffffffffff fffffa800d68e4e0 fffffa800ced7060 0000000000000026 : nt!NtTerminateProcess+0x2d5
fffff880098bcae0 000000007718bffa : 00000000771a2434 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13
00000000052af938 00000000771a2434 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!NtTerminateProcess+0xa
00000000052af940 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!RtlUserThreadStart+0x38