Software Diagnostics Library

DPC Stack Collection is yet another area to mine for Execution Residue and Rough Stack Traces. Some DPC Stacks may be visible in Stack Trace Collections such as from CPUs.

Each CPU has a DPC stack for execution of queued DPCs. We can get its base stack region address from the corresponding _KPRCB structure for each CPU. The stack region limit can be calculated from the KeKernelStackSize Module Variable:

0: kd> dd nt!KeKernelStackSize L1
fffff800`e27c4028 00007000

0: kd> !dpcs
CPU Type KDPC Function
0: Normal : 0xffffc9019b313400 0xfffff8008b6b31b0 igdkmd64

0: kd> !prcb 0
PRCB for Processor 0 at fffff8006ff97180:
Current IRQL — 0
Threads– Current ffffc901ad242040 Next 0000000000000000 Idle fffff800e27d1640
Processor Index 0 Number (0, 0) GroupSetMember 1
Interrupt Count — 06278469
Times — Dpc 0000b229 Interrupt 0000b897
Kernel 00d11420 User 000b6650

0: kd> dt nt!_KPRCB fffff8006ff97180 DpcStack
+0×38a0 DpcStack : 0xfffff800`745b1fb0 Void

0: kd> dpS 0xfffff800`745b1fb0-7000 L7000/8
fffff800`e1ba7e6c nt!RtlpHpLfhSlotAllocateSlow+0×484
fffff800`e26ee9c0 nt!ExPoolState+0×86940
fffff800`e1a3ecb4 nt!ExAllocateHeapPool+0×2134
fffff800`e1800000 nt!RtlCompressBufferProcs
fffff800`e236a196 nt!ExFreePoolWithTag+0×4c6
fffff800`e2369189 nt!ExAllocatePool2+0×99
fffff800`e1b9e0ba nt!AuthzBasepEvaluateExpression+0×3a
fffff800`e1b9c1a0 nt!AuthzBasepEvaluateAceCondition+0×2a0
fffff800`e1b9b649 nt!SepNormalAccessCheck+0×589
fffff800`e1b9a852 nt!SepAccessCheck+0×2c2
fffff800`e26ee9c0 nt!ExPoolState+0×86940
fffff800`e1a3ecb4 nt!ExAllocateHeapPool+0×2134
fffff800`7400e5d8 LXCORE!VfsFileGetPathString+0×114
fffff800`e1d022ee nt!qsort+0×3be
fffff800`e26ee9c0 nt!ExPoolState+0×86940
fffff800`e1a3ecb4 nt!ExAllocateHeapPool+0×2134
fffff800`e1800000 nt!RtlCompressBufferProcs
fffff800`e236a196 nt!ExFreePoolWithTag+0×4c6
fffff800`e2638a00 nt!MiSystemPartition
fffff800`e1b7166f nt!MmDeleteKernelStack+0×22f
fffff800`e1b7235b nt!KiExpandKernelStackAndCalloutOnStackSegment+0×31b
fffff800`75464450 NETIO!ArbitrateAndEnforceCallout
fffff800`e1aeef4c nt!KiExpandKernelStackAndCalloutSwitchStack+0×17c
fffff800`75464450 NETIO!ArbitrateAndEnforceCallout
fffff800`e1aeeca3 nt!KeExpandKernelStackAndCalloutInternal+0×33
fffff800`75464450 NETIO!ArbitrateAndEnforceCallout
fffff800`75282d7e ndis!NdisAcquireRWLockRead+0×2e
fffff800`e1aeec5d nt!KeExpandKernelStackAndCalloutEx+0×1d
fffff800`7544a27d NETIO!UpdateLayerClassifyStat+0×19d
fffff800`e2638a00 nt!MiSystemPartition
fffff800`e1b7166f nt!MmDeleteKernelStack+0×22f
fffff800`754a6000 NETIO!WPP_GLOBAL_Control
fffff800`e1b2db6f nt!KeSetEvent+0×10f
fffff800`786a3faa Ndu!NduUpdateProcessEnergyContext+0×6a
fffff800`786ab8c9 Ndu!NduUpdateInterfaceTimeStatsEntryList+0×149
fffff800`e1bf167c nt!ExFreeToLookasideListEx+0×4c
fffff800`786a1aee Ndu!NduUpdateInterfacePowerContext+0×1be
fffff800`786a38ff Ndu!NduDeleteNblContext+0×9f
fffff800`e1800000 nt!RtlCompressBufferProcs
fffff800`8b739bc0 igdkmd64+0×399bc0
fffff800`8b739bc0 igdkmd64+0×399bc0
fffff800`75260642 ndis!NdisFSendNetBufferListsComplete+0×32
fffff800`75419b30 NETIO!WfpNblInfoDestroyIfUnused+0xf0
fffff800`8b732bc2 igdkmd64+0×392bc2
fffff800`752a7557 ndis!NdisFreeMemory+0×17
fffff800`8b73113c igdkmd64+0×39113c
fffff800`8b48f165 igdkmd64+0xef165
fffff800`8b57aeaa igdkmd64+0×1daeaa
fffff800`8b73113c igdkmd64+0×39113c
fffff800`8b5f3ad9 igdkmd64+0×253ad9
fffff800`8b48f165 igdkmd64+0xef165
fffff800`8b4778d3 igdkmd64+0xd78d3
fffff800`8b625db3 igdkmd64+0×285db3
fffff800`e1ae3a2f nt!KiSelectProcessorToPreempt+0xff
fffff800`8b739bc0 igdkmd64+0×399bc0
fffff800`8b467e79 igdkmd64+0xc7e79
fffff800`8b7355ad igdkmd64+0×3955ad
fffff800`8b73a25a igdkmd64+0×39a25a
fffff800`8b732bc2 igdkmd64+0×392bc2
fffff800`8b732d0c igdkmd64+0×392d0c
fffff800`8b731209 igdkmd64+0×391209
fffff800`8b6c1081 igdkmd64+0×321081
fffff800`8b6a54ac igdkmd64+0×3054ac
fffff800`8b6cccec igdkmd64+0×32ccec
fffff800`8b6c0390 igdkmd64+0×320390
fffff800`8b6b3577 igdkmd64+0×313577
fffff800`8b739bc0 igdkmd64+0×399bc0
fffff800`8b739bc0 igdkmd64+0×399bc0
fffff800`e1b3143c nt!KeAcquireSpinLockAtDpcLevel+0×1c
fffff800`786a406a Ndu!NduUpdateProcessEnergyContext+0×12a
fffff800`7525b85d ndis!ndisFreeToLookasideList+0×5d
fffff800`786ab8c9 Ndu!NduUpdateInterfaceTimeStatsEntryList+0×149
fffff800`7525b645 ndis!NdisFreeNetBufferList+0xa5
fffff800`786a1aee Ndu!NduUpdateInterfacePowerContext+0×1be
fffff800`75451260 NETIO!NetioFreeNetBufferAndNetBufferList+0×10
fffff800`e1b3143c nt!KeAcquireSpinLockAtDpcLevel+0×1c
fffff800`786a406a Ndu!NduUpdateProcessEnergyContext+0×12a
fffff800`7569b5dc tcpip!TcpTcbSendDatagramsComplete+0×9c
fffff800`7525b85d ndis!ndisFreeToLookasideList+0×5d
fffff800`7525b645 ndis!NdisFreeNetBufferList+0xa5
fffff800`75451260 NETIO!NetioFreeNetBufferAndNetBufferList+0×10
fffff800`75514e63 fwpkclnt!FwppNetBufferListAssociateContext+0×153
fffff800`75611fb1 tcpip!TcpSendDatagramsComplete+0xd1
fffff800`786a2f9f Ndu!NduHandleNblContextRemoved+0×1b3
fffff800`75260564 ndis!FILTER_TEST_FLAG+0×14
fffff800`75611ee0 tcpip!TcpSendDatagramsComplete
fffff800`75419dd4 NETIO!NetioDereferenceNetBufferListChain+0×174
fffff800`75512f51 fwpkclnt!FwppNetBufferListEventNotify+0×1a1
fffff800`7571ca2d tcpip!FlSendNetBufferListChainComplete+0×6d
fffff800`7527258b ndis!ndisMSendCompleteNetBufferListsInternal+0×25b
fffff800`7551342f fwpkclnt!FwpsNetBufferListRetrieveContext0+0×4f
fffff800`91054a30 bridge+0×4a30
fffff800`786a251e Ndu!NduFindOrAssociateNblContext+0×6e
fffff800`75287472 ndis!NdisMSendNetBufferListsComplete+0×5c2
fffff800`786a2b2d Ndu!NduOutboundMacClassifyProcessSingleNbl+0×5d
fffff800`786a2961 Ndu!NduOutboundMacClassify+0×181
fffff800`754a6000 NETIO!WPP_GLOBAL_Control
fffff800`75434553 NETIO!ProcessCallout2+0×163
fffff800`78016d00 nwifi!Dot11SendNBComplete+0×170
fffff800`75463246 NETIO!KfdClassify2+0xbb6
fffff800`7527258b ndis!ndisMSendCompleteNetBufferListsInternal+0×25b
fffff800`e1eaeb31 nt!HvcallpExtendedFastHypercall+0×51
fffff800`e1ae040b nt!HvcallFastExtended+0×13b
fffff800`75272330 ndis!ndisMSendCompleteNetBufferListsInternal
fffff800`e1ae0903 nt!HvlFlushRangeListTb+0×353
fffff800`8ad0b2cd wdiwifi!CPort::CompletePendingCancelSendsOrHaltJobs+0xdd
fffff800`8adea5f0 wdiwifi!WPP_de984c7e04793f3292dfaa0cae396821_Traceguids
fffff800`e1aee810 nt!EtwpReserveTraceBuffer+0×310
fffff800`e1aee810 nt!EtwpReserveTraceBuffer+0×310
fffff800`e1aed852 nt!EtwpTraceMessageVa+0×7f2
fffff800`8abae2d8 mrvlpcie8897+0×2e2d8
fffff800`8abb72a0 mrvlpcie8897+0×372a0
fffff800`8abae1af mrvlpcie8897+0×2e1af
fffff800`8abb72a0 mrvlpcie8897+0×372a0
fffff800`8abb7c74 mrvlpcie8897+0×37c74
fffff800`73ee2e1a WppRecorder!WppAutoLogTrace+0×31a
fffff800`e1c6b43e nt!WmiTraceMessage+0×1e
fffff800`e1800000 nt!RtlCompressBufferProcs
fffff800`e236a196 nt!ExFreePoolWithTag+0×4c6
fffff800`e1c6b43e nt!WmiTraceMessage+0×1e
fffff800`8ad05493 wdiwifi!WPP_RECORDER_SF_DDD+0xbf
fffff800`8ad184da wdiwifi!operator delete+0×1a
fffff800`73ee2e1a WppRecorder!WppAutoLogTrace+0×31a
fffff800`8acaf8f0 mrvlpcie8897+0×12f8f0
fffff800`8abad86d mrvlpcie8897+0×2d86d
fffff800`8acaf8f0 mrvlpcie8897+0×12f8f0
fffff800`8ab8facb mrvlpcie8897+0xfacb
fffff800`e1c3e85a nt!DbgPrint+0×5a
fffff800`8acaf8f0 mrvlpcie8897+0×12f8f0
fffff800`8abc4510 mrvlpcie8897+0×44510
fffff800`8acaf8f0 mrvlpcie8897+0×12f8f0
fffff800`8ab8fdad mrvlpcie8897+0xfdad
fffff800`e1eba502 nt! ?? ::FNODOBFM::`string’+0×2
fffff800`8abb000d mrvlpcie8897+0×3000d
fffff800`8abc4510 mrvlpcie8897+0×44510
fffff800`8acaf8f0 mrvlpcie8897+0×12f8f0
fffff800`8ab883d6 mrvlpcie8897+0×83d6
fffff800`8abb72a0 mrvlpcie8897+0×372a0
fffff800`8ab9311b mrvlpcie8897+0×1311b
fffff800`8abb72a0 mrvlpcie8897+0×372a0
fffff800`8abb7c40 mrvlpcie8897+0×37c40
fffff800`8abaf470 mrvlpcie8897+0×2f470
fffff800`8abb72a0 mrvlpcie8897+0×372a0
fffff800`8adea5e0 wdiwifi!WPP_fabfc031111e31c4b597567128b91120_Traceguids
fffff800`8ad0832b wdiwifi!CTxMgr::AddNBLToTxQueue+0×2bb
fffff800`e1b3149e nt!KeAcquireSpinLockRaiseToDpc+0×3e
fffff800`8ad06051 wdiwifi!CTxMgr::ServiceQueues+0×1c1
fffff800`75518cc8 fwpkclnt!FwpiGetValueFromClassifyContext+0×38
fffff800`8adfd040 wdiwifi!WPP_RECORDER_INITIALIZED
fffff800`8ad06599 wdiwifi!CPort::SendNetBufferLists+0×129
fffff800`786a2015 Ndu!NduInboundMacClassify+0×355
fffff800`8adea5f0 wdiwifi!WPP_de984c7e04793f3292dfaa0cae396821_Traceguids
fffff800`754a6000 NETIO!WPP_GLOBAL_Control
fffff800`75434553 NETIO!ProcessCallout2+0×163
fffff800`75463246 NETIO!KfdClassify2+0xbb6
fffff800`e26ee9c0 nt!ExPoolState+0×86940
fffff800`e1a3ecb4 nt!ExAllocateHeapPool+0×2134
fffff800`7527bfff ndis!ndisInvokeNextSendHandler+0×23f
fffff800`75260564 ndis!FILTER_TEST_FLAG+0×14
fffff800`e1a3cb12 nt!ExpAllocatePoolWithTagFromNode+0×52
fffff800`e2369189 nt!ExAllocatePool2+0×99
fffff800`e23690b4 nt!ExAllocatePoolWithTag+0xa4
fffff800`e1c4ea7d nt!ExAllocatePoolEx+0xd
fffff800`e2369189 nt!ExAllocatePool2+0×99
fffff800`e1bef072 nt!ExAllocateFromLookasideListEx+0×152
fffff800`91055984 bridge+0×5984
fffff800`9105dd94 bridge+0xdd94
fffff800`75451dc4 NETIO!PplpGenericAllocateFunction+0×14
fffff800`e1beef35 nt!ExAllocateFromLookasideListEx+0×15
fffff800`e1a8f495 nt!ObfReferenceObjectWithTag+0×25
fffff800`e23690b4 nt!ExAllocatePoolWithTag+0xa4
fffff800`75416008 NETIO!WfpNblInfoAlloc+0×58
fffff800`e1a8eace nt!ObfReferenceObject+0xe
fffff800`75514e63 fwpkclnt!FwppNetBufferListAssociateContext+0×153
fffff800`e1a3ecb4 nt!ExAllocateHeapPool+0×2134
fffff800`75514cc7 fwpkclnt!FwpsNetBufferListAssociateContext1+0×77
fffff800`786b42d8 Ndu!NduWfpCalloutProviderGuid
fffff800`786a1280 Ndu!NduNblNotifyCallback
fffff800`75260564 ndis!FILTER_TEST_FLAG+0×14
fffff800`786a2613 Ndu!NduFindOrAssociateNblContext+0×163
fffff800`75273918 ndis!NdisFIndicateReceiveNetBufferLists+0×68
fffff800`786a1280 Ndu!NduNblNotifyCallback
fffff800`754a6000 NETIO!WPP_GLOBAL_Control
fffff800`75988200 wfplwfs!L2NativeIsNetBufferListPermitted+0×2d0
fffff800`759897b3 wfplwfs!L2InspectNetBufferListsFast+0×183
fffff800`75463246 NETIO!KfdClassify2+0xbb6
fffff800`7609e7f3 afd!AFDETW_TRACESENDMSG+0×8f
fffff800`e2369189 nt!ExAllocatePool2+0×99
fffff800`75288882 ndis!NdisAcquireReadWriteLock+0×62
fffff800`91055a73 bridge+0×5a73
fffff800`e1b3149e nt!KeAcquireSpinLockRaiseToDpc+0×3e
fffff800`9105662a bridge+0×662a
fffff800`91057920 bridge+0×7920
fffff800`91057db5 bridge+0×7db5
fffff800`752888d3 ndis!NdisAcquireReadWriteLock+0xb3
fffff800`910543b0 bridge+0×43b0
fffff800`91054448 bridge+0×4448
fffff800`75988260 wfplwfs!LwfLowerRecvNetBufferLists
fffff800`75276dc1 ndis!NdisMIndicateReceiveNetBufferLists+0×1941
fffff800`7525b678 ndis!NdisFreeNetBufferList+0xd8
fffff800`786a38ff Ndu!NduDeleteNblContext+0×9f
fffff800`75419dd4 NETIO!NetioDereferenceNetBufferListChain+0×174
fffff800`756b95c0 tcpip!UdpSendMessagesDatagramsComplete
fffff800`786804d5 NdisImPlatform!implatUpdateInStatisticsCounters+0×235
fffff800`e1bf2146 nt!HalpApicRequestInterrupt+0×96
fffff800`e1b5141c nt!HalpInterruptSendIpi+0xac
fffff800`e1cf553c nt!KiSetProcessorIdle_LockFree+0×2b8
fffff800`e1ae22f8 nt!KiHeteroSelectIdleProcessorFromSubNode+0×308
fffff800`7867f6c7 NdisImPlatform!implatReceiveNetBufferLists+0×1f7
fffff800`e1ae9a0b nt!KiComputeThreadQos+0xfb
fffff800`e1bf2146 nt!HalpApicRequestInterrupt+0×96
fffff800`e1b5141c nt!HalpInterruptSendIpi+0xac
fffff800`e1cf553c nt!KiSetProcessorIdle_LockFree+0×2b8
fffff800`e1ae22f8 nt!KiHeteroSelectIdleProcessorFromSubNode+0×308
fffff800`e1ae9a0b nt!KiComputeThreadQos+0xfb
fffff800`e1dda677 nt!PpmEventTraceCoreParkingSelection+0×197
fffff800`e1b50cfc nt!KiExitDispatcher+0×4c
fffff800`e1cf277c nt!PpmParkComputeUnparkMask+0xa2c
fffff800`e1bb2241 nt!KiIntSteerCalculatePriorityDistribution+0×201
fffff800`e1bb361d nt!KiIntSteerLogMask+0×55
fffff800`e270f7b0 nt!KiIntTrackRootList
fffff800`e1bb3699 nt!KiIntSteerLogProc+0×5d
fffff800`e270f7b0 nt!KiIntTrackRootList
fffff800`e1bb37e3 nt!KiIntSteerCalculateDistribution+0×103
fffff800`e1bb32c3 nt!KeIntSteerPeriodic+0×17f
fffff800`e1bb2ed8 nt!PpmParkSteerInterrupts+0×5e8
fffff800`e1b335a4 nt!EtwpLogKernelEvent+0×2f4
fffff800`e270b0a8 nt!PpmPerfPolicyLock+0×8
fffff800`e1b2db6f nt!KeSetEvent+0×10f
fffff800`e270b0ac nt!PpmPerfPolicyLock+0xc
fffff800`e1be8f10 nt!PpmCheckMakeupSkippedChecks
fffff800`e1be9040 nt!PpmPerfReadFeedback
fffff800`e1be9177 nt!PpmReleaseLock+0×1b
fffff800`e1b32bc6 nt!KiExecuteAllDpcs+0xdc6
fffff800`e2709dc0 nt!PpmCheckDpc
fffff800`e1a0cfb9 nt!KiNormalPriorityReadyScan+0×2b9
fffff800`e1be8e00 nt!PpmCheckRun
fffff800`e1a0c228 nt!KiRetireDpcList+0×668
fffff800`e1bb4180 nt!PpmPerfAction
fffff800`e1be8e00 nt!PpmCheckRun
fffff800`e1eac3c5 nt!KxSwapStacksAndRetireDpcList+0×5

0: kd> !prcb 1
PRCB for Processor 1 at ffff84014911c180:
Current IRQL — 0
Threads– Current ffffc901a7d580c0 Next 0000000000000000 Idle ffffc9019375f040
Processor Index 1 Number (0, 1) GroupSetMember 2
Interrupt Count — 057d181c
Times — Dpc 00005ae1 Interrupt 000072cb
Kernel 00cf00e2 User 000d7983

0: kd> dt nt!_KPRCB ffff84014911c180 DpcStack
+0×38a0 DpcStack : 0xffffa206`68e47fb0 Void

0: kd> dpS 0xffffa206`68e47fb0-7000 L7000/8
fffff800`e1adfa8f nt!MiFlushTbList+0×35f
fffff800`e1b0b02c nt!MiGetPage+0×8dc
fffff800`e1b158c5 nt!MiFlushTbAsNeeded+0×265
fffff800`e1a636e0 nt!MiAssignNonPagedPoolPte+0×110
fffff800`e2638180 nt!MiState+0xb940
fffff800`e1a63fcb nt!MiReturnExcessPoolCommit+0×27
fffff800`e1a631c6 nt!MiCommitPoolMemory+0×1b6
fffff800`e1a62c6b nt!RtlpHpEnvAllocVA+0×22b
fffff800`e1e9fb70 nt!HvlEndSystemInterrupt
fffff800`e1c20b6a nt!HalPerformEndOfInterrupt+0×1a
fffff800`e1ea6feb nt!KiInterruptDispatchNoLockNoEtw+0×5b
fffff800`e2638180 nt!MiState+0xb940
fffff800`8b739bc0 igdkmd64+0×399bc0
fffff800`e1bac123 nt!RtlpHpAllocVA+0xd7
fffff800`8b739bc0 igdkmd64+0×399bc0
fffff800`e1e9fb70 nt!HvlEndSystemInterrupt
fffff800`8b732bc2 igdkmd64+0×392bc2
fffff800`e1ae3a2f nt!KiSelectProcessorToPreempt+0xff
fffff800`8b73113c igdkmd64+0×39113c
fffff800`8b48f165 igdkmd64+0xef165
fffff800`8b57aeaa igdkmd64+0×1daeaa
fffff800`e27cfbc0 nt!ExNode0
fffff800`e2615740 nt!KiInitialNodeStructures+0×40
fffff800`e1ae3a2f nt!KiSelectProcessorToPreempt+0xff
fffff800`e27cfbc0 nt!ExNode0
fffff800`e1bf2146 nt!HalpApicRequestInterrupt+0×96
fffff800`e27cfbc0 nt!ExNode0
fffff800`e1b5141c nt!HalpInterruptSendIpi+0xac
fffff800`e1cf553c nt!KiSetProcessorIdle_LockFree+0×2b8
fffff800`e1ae22f8 nt!KiHeteroSelectIdleProcessorFromSubNode+0×308
fffff800`e1ae5cff nt!KiUpdateSoftParkElectionStatisticsOnInsertion+0×16f
fffff800`e1ae9a0b nt!KiComputeThreadQos+0xfb
fffff800`e1b51124 nt!KiProcessThreadWaitList+0×224
fffff800`e1beef35 nt!ExAllocateFromLookasideListEx+0×15
fffff800`786a1aee Ndu!NduUpdateInterfacePowerContext+0×1be
fffff800`786aa0b4 Ndu!PplpGenericAllocateFunction+0×14
fffff800`e1b2db6f nt!KeSetEvent+0×10f
fffff800`e1b3143c nt!KeAcquireSpinLockAtDpcLevel+0×1c
fffff800`786a406a Ndu!NduUpdateProcessEnergyContext+0×12a
fffff800`7525b85d ndis!ndisFreeToLookasideList+0×5d
fffff800`7525b645 ndis!NdisFreeNetBufferList+0xa5
fffff800`75451260 NETIO!NetioFreeNetBufferAndNetBufferList+0×10
fffff800`75611fb1 tcpip!TcpSendDatagramsComplete+0xd1
fffff800`786a2f9f Ndu!NduHandleNblContextRemoved+0×1b3
fffff800`75260564 ndis!FILTER_TEST_FLAG+0×14
fffff800`75611ee0 tcpip!TcpSendDatagramsComplete
fffff800`75419dd4 NETIO!NetioDereferenceNetBufferListChain+0×174
fffff800`75512f51 fwpkclnt!FwppNetBufferListEventNotify+0×1a1
fffff800`7571ca2d tcpip!FlSendNetBufferListChainComplete+0×6d
fffff800`7527258b ndis!ndisMSendCompleteNetBufferListsInternal+0×25b
fffff800`91054a30 bridge+0×4a30
fffff800`75272330 ndis!ndisMSendCompleteNetBufferListsInternal
fffff800`75287472 ndis!NdisMSendNetBufferListsComplete+0×5c2
fffff800`75260993 ndis!NdisFSendNetBufferListsComplete+0×383
fffff800`7867fe70 NdisImPlatform!implatSendNetBufferListsComplete+0×1a0
fffff800`78016d00 nwifi!Dot11SendNBComplete+0×170
fffff800`7527258b ndis!ndisMSendCompleteNetBufferListsInternal+0×25b
fffff800`7615aff9 vwififlt!FilterSendNetBufferListsCompleteWDI+0xd9
fffff800`75272330 ndis!ndisMSendCompleteNetBufferListsInternal
fffff800`75287472 ndis!NdisMSendNetBufferListsComplete+0×5c2
fffff800`8b739bc0 igdkmd64+0×399bc0
fffff800`e1b3149e nt!KeAcquireSpinLockRaiseToDpc+0×3e
fffff800`8ad0b2cd wdiwifi!CPort::CompletePendingCancelSendsOrHaltJobs+0xdd
fffff800`8adea5f0 wdiwifi!WPP_de984c7e04793f3292dfaa0cae396821_Traceguids
fffff800`8ad09710 wdiwifi!CTxMgr::CompleteNdisNbl+0×250
fffff800`8adfd040 wdiwifi!WPP_RECORDER_INITIALIZED
fffff800`8b48f0c8 igdkmd64+0xef0c8
fffff800`8b48f0c8 igdkmd64+0xef0c8
fffff800`8adea5e0 wdiwifi!WPP_fabfc031111e31c4b597567128b91120_Traceguids
fffff800`8adfd040 wdiwifi!WPP_RECORDER_INITIALIZED
fffff800`8ad07570 wdiwifi!CTxMgr::TxTransferCompleteInd+0×2f0
fffff800`e1b3149e nt!KeAcquireSpinLockRaiseToDpc+0×3e
fffff800`73de6345 Wdf01000!imp_WdfSpinLockRelease+0×95 [minkernel\wdf\framework\shared\support\fxspinlockapi.cpp @ 180]
fffff800`73de6345 Wdf01000!imp_WdfSpinLockRelease+0×95 [minkernel\wdf\framework\shared\support\fxspinlockapi.cpp @ 180]
fffff800`8abab1d3 mrvlpcie8897+0×2b1d3
fffff800`73de62b0 Wdf01000!imp_WdfSpinLockRelease [minkernel\wdf\framework\shared\support\fxspinlockapi.cpp @ 159]
fffff800`8ab94257 mrvlpcie8897+0×14257
fffff800`73de62b0 Wdf01000!imp_WdfSpinLockRelease [minkernel\wdf\framework\shared\support\fxspinlockapi.cpp @ 159]
fffff800`8abb72a0 mrvlpcie8897+0×372a0
fffff800`8abac585 mrvlpcie8897+0×2c585
fffff800`786a2d6b Ndu!NduIsL2MediaTypeWan+0×3b
fffff800`8b625db3 igdkmd64+0×285db3
fffff800`8abb72a0 mrvlpcie8897+0×372a0
fffff800`8aba71db mrvlpcie8897+0×271db
fffff800`754a6000 NETIO!WPP_GLOBAL_Control
fffff800`8ab93f3e mrvlpcie8897+0×13f3e
fffff800`75463246 NETIO!KfdClassify2+0xbb6
fffff800`8b6ce960 igdkmd64+0×32e960
fffff800`8b6cfdf2 igdkmd64+0×32fdf2
fffff800`75260564 ndis!FILTER_TEST_FLAG+0×14
fffff800`8ab93e4a mrvlpcie8897+0×13e4a
fffff800`e1beef35 nt!ExAllocateFromLookasideListEx+0×15
fffff800`e1b3149e nt!KeAcquireSpinLockRaiseToDpc+0×3e
fffff800`e1b3149e nt!KeAcquireSpinLockRaiseToDpc+0×3e
fffff800`73de6345 Wdf01000!imp_WdfSpinLockRelease+0×95 [minkernel\wdf\framework\shared\support\fxspinlockapi.cpp @ 180]
fffff800`8ab8c4f4 mrvlpcie8897+0xc4f4
fffff800`73de62b0 Wdf01000!imp_WdfSpinLockRelease [minkernel\wdf\framework\shared\support\fxspinlockapi.cpp @ 159]
fffff800`8adea5e0 wdiwifi!WPP_fabfc031111e31c4b597567128b91120_Traceguids
fffff800`73e18d40 Wdf01000!imp_WdfMemoryGetBuffer+0×60 [minkernel\wdf\framework\shared\core\fxmemorybufferapi.cpp @ 204]
fffff800`8ab8f1ca mrvlpcie8897+0xf1ca
fffff800`e1b3149e nt!KeAcquireSpinLockRaiseToDpc+0×3e
fffff800`73de6345 Wdf01000!imp_WdfSpinLockRelease+0×95 [minkernel\wdf\framework\shared\support\fxspinlockapi.cpp @ 180]
fffff800`e1b3149e nt!KeAcquireSpinLockRaiseToDpc+0×3e
fffff800`73de6345 Wdf01000!imp_WdfSpinLockRelease+0×95 [minkernel\wdf\framework\shared\support\fxspinlockapi.cpp @ 180]
fffff800`8ab92a47 mrvlpcie8897+0×12a47
fffff800`8ab87de2 mrvlpcie8897+0×7de2
fffff800`73de62b0 Wdf01000!imp_WdfSpinLockRelease [minkernel\wdf\framework\shared\support\fxspinlockapi.cpp @ 159]
fffff800`8ab9311b mrvlpcie8897+0×1311b
fffff800`73de62b0 Wdf01000!imp_WdfSpinLockRelease [minkernel\wdf\framework\shared\support\fxspinlockapi.cpp @ 159]
fffff800`8adea5e0 wdiwifi!WPP_fabfc031111e31c4b597567128b91120_Traceguids
fffff800`e1b3149e nt!KeAcquireSpinLockRaiseToDpc+0×3e
fffff800`8ad06051 wdiwifi!CTxMgr::ServiceQueues+0×1c1
fffff800`8adfd040 wdiwifi!WPP_RECORDER_INITIALIZED
fffff800`8ad06599 wdiwifi!CPort::SendNetBufferLists+0×129
fffff800`8adea5f0 wdiwifi!WPP_de984c7e04793f3292dfaa0cae396821_Traceguids
fffff800`7527eac1 ndis!ndisWdmSetBusyAsync+0×101
fffff800`8adfd040 wdiwifi!WPP_RECORDER_INITIALIZED
fffff800`8ad05c30 wdiwifi!MPWrapperSendNetBufferLists+0×160
fffff800`8ad05ad0 wdiwifi!MPWrapperSendNetBufferLists
fffff800`75280dc2 ndis!ndisMSendNBLToMiniportInternal+0×122
fffff800`8ad05ad0 wdiwifi!MPWrapperSendNetBufferLists
fffff800`76158ab3 vwififlt!FilterSendNetBufferListsWDI+0×1c3
fffff800`75280c80 ndis!ndisMSendNBLToMiniport
fffff800`75280c8e ndis!ndisMSendNBLToMiniport+0xe
fffff800`75988620 wfplwfs!LwfLowerSendNetBufferLists
fffff800`7527bf92 ndis!ndisInvokeNextSendHandler+0×1d2
fffff800`7525feed ndis!NdisFSendNetBufferLists+0×3bd
fffff800`759897b3 wfplwfs!L2InspectNetBufferListsFast+0×183
fffff800`75260564 ndis!FILTER_TEST_FLAG+0×14
fffff800`753325f2 ndis!NdisSendNetBufferLists+0xc1372
fffff800`78014750 nwifi!FilterSendNetBufferLists
fffff800`8b78c622 igdkmd64+0×3ec622
fffff800`759887e8 wfplwfs!LwfLowerSendNetBufferLists+0×1c8
fffff800`910581d1 bridge+0×81d1
fffff800`910559c5 bridge+0×59c5
fffff800`9105dd94 bridge+0xdd94
fffff800`e1adfa8f nt!MiFlushTbList+0×35f
fffff800`7867f394 NdisImPlatform!implatPrepareForSendNetBufferLists+0xec
fffff800`7867fc52 NdisImPlatform!implatSendNetBufferLists+0×182
fffff800`9105ce01 bridge+0xce01
fffff800`7867fad0 NdisImPlatform!implatSendNetBufferLists
fffff800`75280dc2 ndis!ndisMSendNBLToMiniportInternal+0×122
fffff800`9105d4ae bridge+0xd4ae
fffff800`e1b0b02c nt!MiGetPage+0×8dc
fffff800`7867fad0 NdisImPlatform!implatSendNetBufferLists
fffff800`e1b158c5 nt!MiFlushTbAsNeeded+0×265
fffff800`e1a636e0 nt!MiAssignNonPagedPoolPte+0×110
fffff800`e2638180 nt!MiState+0xb940
fffff800`e1a63fcb nt!MiReturnExcessPoolCommit+0×27
fffff800`e1a631c6 nt!MiCommitPoolMemory+0×1b6
fffff800`e1a62c6b nt!RtlpHpEnvAllocVA+0×22b
fffff800`e2638180 nt!MiState+0xb940
fffff800`e1bac123 nt!RtlpHpAllocVA+0xd7
fffff800`e1babdb7 nt!RtlpHpVaMgrCtxQuery+0×4b
fffff800`e1bab920 nt!RtlpHpSegMgrCommit+0×228
fffff800`e1ae3a2f nt!KiSelectProcessorToPreempt+0xff
fffff800`e1bf2146 nt!HalpApicRequestInterrupt+0×96
fffff800`e1ba7e6c nt!RtlpHpLfhSlotAllocateSlow+0×484
fffff800`e27cfbc0 nt!ExNode0
fffff800`e1b5141c nt!HalpInterruptSendIpi+0xac
fffff800`e1cf553c nt!KiSetProcessorIdle_LockFree+0×2b8
fffff800`e1ae22f8 nt!KiHeteroSelectIdleProcessorFromSubNode+0×308
fffff800`e1ae5cbc nt!KiUpdateSoftParkElectionStatisticsOnInsertion+0×12c
fffff800`e1ae9a0b nt!KiComputeThreadQos+0xfb
fffff800`e1dda677 nt!PpmEventTraceCoreParkingSelection+0×197
fffff800`e1b51124 nt!KiProcessThreadWaitList+0×224
fffff800`e1b50cfc nt!KiExitDispatcher+0×4c
fffff800`e1cf277c nt!PpmParkComputeUnparkMask+0xa2c
fffff800`e1b3149e nt!KeAcquireSpinLockRaiseToDpc+0×3e
fffff800`e1bb2241 nt!KiIntSteerCalculatePriorityDistribution+0×201
fffff800`e1bb361d nt!KiIntSteerLogMask+0×55
fffff800`e270f7b0 nt!KiIntTrackRootList
fffff800`e1bb3699 nt!KiIntSteerLogProc+0×5d
fffff800`e270f7b0 nt!KiIntTrackRootList
fffff800`e1bb37e3 nt!KiIntSteerCalculateDistribution+0×103
fffff800`e1bb32c3 nt!KeIntSteerPeriodic+0×17f
fffff800`e1bb2ed8 nt!PpmParkSteerInterrupts+0×5e8
fffff800`e1c594e9 nt!HvlUpdatePerformanceStateCountersForLp+0×79
fffff800`776b2781 intelppm!PerfHvReadFeedback+0×61
fffff800`e1cf553c nt!KiSetProcessorIdle_LockFree+0×2b8
fffff800`e1ae22f8 nt!KiHeteroSelectIdleProcessorFromSubNode+0×308
fffff800`e1a0afa5 nt!KiUpdateThreadQosGroupingSummaries+0×75
fffff800`e1a0a927 nt!KiCommitRescheduleContextEntry+0×1e7
fffff800`e27d1183 nt!KiInitialSharedReadyQueue+0×243
fffff800`e1ae9a0b nt!KiComputeThreadQos+0xfb
fffff800`e1b3673a nt!KiDeferredReadySingleThread+0×29fa
fffff800`e1a0f077 nt!PpmUpdatePerformanceFeedback+0×3b7
fffff800`e1b51006 nt!KiProcessThreadWaitList+0×106
fffff800`e1b335a4 nt!EtwpLogKernelEvent+0×2f4
fffff800`e1b2db6f nt!KeSetEvent+0×10f
fffff800`e1bb7182 nt!PopQueueTargetDpc+0xee
fffff800`e1b32bc6 nt!KiExecuteAllDpcs+0xdc6
fffff800`e1bb6680 nt!PopExecuteProcessorCallback
fffff800`e1bb6680 nt!PopExecuteProcessorCallback
fffff800`e1a0c228 nt!KiRetireDpcList+0×668
fffff800`e1bb6680 nt!PopExecuteProcessorCallback
fffff800`e1eac3c5 nt!KxSwapStacksAndRetireDpcList+0×5

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Message Embedding, as a representational technique in ML, are a variant of Trace Field. We can also consider the sequence of Message Embeddings as a trace itself with columns as latent features, forming separate latent Features of Activity. We can also treat these embeddings as sentence embeddings when interpreting traces and logs as Text Traces.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

We can view traces and logs as abstract polynomials that consists of abstract monomials. For example, if we have trace messages A,B,C, and D, the trace ABCACACACCD represents a single monomial. The multiplication operation in monomials represents message concatenation. But we can also split the trace as an abstract sum of several monomials, for example, ABC + AC + AC + AC + CD, or ABC + 3*AC + CD. The addition operation is a concatenation of traces even if concatenated traces consist of just one message. Note the distinction here between concatenation of messages and traces. By Trace Polynomial we mean a canonical abstract polynomial representation where we divide the trace by monomial when the next message in the message stream is already contained in the previous monomial, for example, ABC + 2AC + AC^2D.

Both addition and multiplication are non-commutative, and no distributivity between them. Mathematically speaking, we have the so-called a non‑distributive bi‑semigroup, or, in a category-theoretic sense, such abstract polynomials are objects in a free 2‑semigroupal category without interchange.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

A page to reference all different kinds of collection-related analysis patterns is necessary, so I created this post:

• Stack Trace Collection (unmanaged space)
• Stack Trace Collection (managed space)
• Stack Trace Collection (predicate)
• Stack Trace Collection (I/O requests)
• Stack Trace Collection (CPUs)
• Last Error Collection
• Module Collection
• Module Collection (predicate)
• Structure Field Collection
• Rough Stack Trace Collection (unmanaged space)
• Exception Collection
• Interrupt Stack Collection
• DPC Stack Collection

I’ll update it as soon as I add more similar patterns.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Interrupt Stack Collection is another area to mine for Execution Residue and Rough Stack Traces. Some Interrupt Stacks may be visible in Stack Trace Collections such as from CPUs. In addition to Stack Overflow double fault stack region, we also have debug, NMI, and machine check interrupt stack 6Kb regions:

6: kd> !idt

Dumping IDT: ffffbd014d6b1000

00: fffff806f53ad100 nt!KiDivideErrorFaultShadow
01: fffff806f53ad180 nt!KiDebugTrapOrFaultShadow Stack = 0xFFFFBD014D6B59D0
02: fffff806f53ad240 nt!KiNmiInterruptShadow Stack = 0xFFFFBD014D6B57D0
03: fffff806f53ad2c0 nt!KiBreakpointTrapShadow
04: fffff806f53ad340 nt!KiOverflowTrapShadow
05: fffff806f53ad3c0 nt!KiBoundFaultShadow
06: fffff806f53ad440 nt!KiInvalidOpcodeFaultShadow
07: fffff806f53ad4c0 nt!KiNpxNotAvailableFaultShadow
08: fffff806f53ad540 nt!KiDoubleFaultAbortShadow Stack = 0xFFFFBD014D6B53D0
09: fffff806f53ad5c0 nt!KiNpxSegmentOverrunAbortShadow
0a: fffff806f53ad640 nt!KiInvalidTssFaultShadow
0b: fffff806f53ad6c0 nt!KiSegmentNotPresentFaultShadow
0c: fffff806f53ad740 nt!KiStackFaultShadow
0d: fffff806f53ad7c0 nt!KiGeneralProtectionFaultShadow
0e: fffff806f53ad840 nt!KiPageFaultShadow
10: fffff806f53ad8c0 nt!KiFloatingErrorFaultShadow
11: fffff806f53ad940 nt!KiAlignmentFaultShadow
12: fffff806f53ad9c0 nt!KiMcheckAbortShadow Stack = 0xFFFFBD014D6B55D0
13: fffff806f53adac0 nt!KiXmmExceptionShadow
[…]

These stacks are different for each CPU. It is also possible to get these stack bases from TSS:

6: kd> ~0s

0: kd> !pcr
KPCR for Processor 0 at fffff80680079000:
Major 1 Minor 1
NtTib.ExceptionList: fffff8068743efb0
NtTib.StackBase: fffff8068743d000
NtTib.StackLimit: 0000000000000000
NtTib.SubSystemTib: fffff80680079000
NtTib.Version: 0000000080079180
NtTib.UserPointer: fffff80680079870
NtTib.SelfTib: 00000060414a8000

SelfPcr: 0000000000000000
Prcb: fffff80680079180
Irql: 0000000000000000
IRR: 0000000000000000
IDR: 0000000000000000
InterruptMode: 0000000000000000
IDT: 0000000000000000
GDT: 0000000000000000
TSS: 0000000000000000

CurrentThread: ffffa80b0c8240c0
NextThread: 0000000000000000
IdleThread: fffff806f57d0640

DpcQueue:

0: kd> dt nt!_KPCR fffff80680079000
nt!_KPCR
+0×000 NtTib : _NT_TIB
+0×000 GdtBase : 0xfffff806`8743efb0 _KGDTENTRY64
+0×008 TssBase : 0xfffff806`8743d000 _KTSS64
+0×010 UserRsp : 0
+0×018 Self : 0xfffff806`80079000 _KPCR
+0×020 CurrentPrcb : 0xfffff806`80079180 _KPRCB
+0×028 LockArray : 0xfffff806`80079870 _KSPIN_LOCK_QUEUE
+0×030 Used_Self : 0×00000060`414a8000 Void
+0×038 IdtBase : 0xfffff806`8743c000 _KIDTENTRY64
+0×040 Unused : [2] 0
+0×050 Irql : 0 ”
+0×051 SecondLevelCacheAssociativity : 0×10 ”
+0×052 ObsoleteNumber : 0 ”
+0×053 Fill0 : 0 ”
+0×054 Unused0 : [3] 0
+0×060 MajorVersion : 1
+0×062 MinorVersion : 1
+0×064 StallScaleFactor : 0×840
+0×068 Unused1 : [3] (null)
+0×080 KernelReserved : [15] 0
+0×0bc SecondLevelCacheSize : 0×800000
+0×0c0 HalReserved : [16] 0×7de29000
+0×100 Unused2 : 0
+0×108 KdVersionBlock : (null)
+0×110 Unused3 : (null)
+0×118 PcrAlign1 : [24] 0

0: kd> dt nt!_KTSS64 0xfffff806`8743d000
nt!_KTSS64
+0×000 Reserved0 : 0
+0×004 Rsp0 : 0xfffff806`87440200
+0×00c Rsp1 : 0
+0×014 Rsp2 : 0
+0×01c Ist : [8] 0
+0×05c Reserved1 : 0
+0×064 Reserved2 : 0
+0×066 IoMapBase : 0×68

0: kd> dps 0xfffff806`8743d000+1c L8
fffff806`8743d01c 00000000`00000000
fffff806`8743d024 fffff806`874403d0
fffff806`8743d02c fffff806`874405d0
fffff806`8743d034 fffff806`874407d0
fffff806`8743d03c fffff806`874409d0
fffff806`8743d044 00000000`00000000
fffff806`8743d04c 00000000`00000000
fffff806`8743d054 00000000`00000000

0: kd> !idt 2

Dumping IDT: fffff8068743c000

02: fffff806f53ad240 nt!KiNmiInterruptShadow Stack = 0xFFFFF806874407D0

These stack base values may be transition stack values. In such a case, a redirection is required:

0: kd> dps fffff806`874407d0 L4
fffff806`874407d0 fffff806`80079000
fffff806`874407d8 fffff806`87471fe0
fffff806`874407e0 fffff806`80079000
fffff806`874407e8 00000004`237bf002

0: kd> dpS fffff806`87471fe0+20-6000 L6000/8
fffff806`f4dcd566 nt!KiSaveProcessorState+0xb6
fffff806`f4dc588a nt!KiFreezeTargetExecution+0×1ba
fffff806`f4db72ea nt!KiCheckForFreezeExecution+0×2a
fffff806`f4dbb242 nt!KiProcessNMI+0×52
fffff806`f4eb0fc2 nt!KxNmiInterrupt+0×82
fffff806`f4dcd124 nt!KiMcheckFastForward+0×64

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Trace Precision and Recall analysis patterns are borrowed from information retrieval and machine learning. In essence, Trace Precision is the fraction of trace messages used for successful diagnostics among all selected trace messages, for example, among CoTrace messages to reduce the noise. Trace Recall is the fraction of trace messages used for successful diagnostics among all relevant messages (these can also be messages not included in the trace, see Trace Bias).

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Traces and logs can be considered models of computation as was first proposed in Trace Bias analysis pattern. Borrowing metaphors from machine learning we can consider trace messages as Trace Parameters having associated values, for example, through Trace Field. These values can be numerical weights or linguistic values, for example, as proposed by Zadeh. Message values can be field values themselves, for example, Counter Values. As was noted in Trace Variance, different tracing environments with their set of “features” can be considered input data. if we use an artificial neural network metaphor, trace analysis itself can be considered as an activation function. CoTraces, as models of trace analysis, may form other “hidden” layers with “backpropagation” updating message weights. Tracing configuration parameters including Trace Schemas can be considered as Trace Hyperparameters. These concepts can be roughly illustrated by the following diagram:

To reduce the number of Trace Parameters we can use Quotient Traces.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

In some cases, when we have two trace messages we can infer the missing Implicit Message. This trace augmentation may help when we Sparse Traces and we want to train ML models on them. To illustrate, we asked ChatGPT:

We have a log file with two messages: 1. Reading file test.txt 2. Access denied. There is an implicit message in between.

The implicit message between the two log entries is:

“Attempting to open file ‘test.txt’.”

Reasoning:

1. “Reading file test.txt” → This suggests that the system or user has issued a command to read the file.
2. Implicit step (not logged explicitly) → The system attempts to open the file to read its contents.
3. “Access denied.” → The attempt fails due to permission restrictions or security policies.

Thus, the missing step is the system trying to open or access the file, which leads to the access denial.

Implicit Messages are different from Silent Messages which are padding messages to occupy the minimum resolution gaps.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

The fact that messages have types is mentioned in some trace and log analysis patterns but have never had its own analysis pattern. Trace and log messages may have the same Message Type if they have the same Adjoint Thread of Activity ATID (or Message Metadata) value, for example, “Warning”. Or they may have the same structure, for example, the same constants or message invariants, or belong to the same Trace Schema in Container Traces.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Terminated threads are not listed in unmanaged space Stack Trace Collections. In kernel space, we may notice them if we expect N kernel threads but see less like Missing Threads in user space. If we see less kernel threads in a process context then, definitely, user space counterparts to Dual Stack Traces are missing (but we may still recover Hidden Stacks). Sometimes, using appropriate extensions, like SwishDbgExt, we can see terminated threads based on exit time:

0: kd> !ms_process /pid 0x250 /threads
[...]
| 0x0250 | 0x02a0 | 0x00007FFC858FE680 | winsrvext!TerminalServerRequestThread | 13/11/2021 22:14:28 | 00/00/ 0 00:00:00 |
| 0×0250 | 0×02a4 | 0×00007FFC858F2710 | winsrvext!GdiAddInitialFontsThread | 13/11/2021 22:14:28 | 13/11/2021 22:14:29 |
| 0×0250 | 0×02a8 | 0×00007FFC858F3430 | winsrvext!NotificationThread | 13/11/2021 22:14:28 | 00/00/ 0 00:00:00 |
[…]

If we get thread ids from some Paratext, we can directly check if the thread is terminated or not:

0: kd> !thread -t 2a4 3f
THREAD ffffc38c3040e080 Cid 0250.02a4 Teb: 0000000000000000 Win32Thread: 0000000000000000 TERMINATED
Not impersonating
DeviceMap ffffac8a0423d290
Owning Process ffffc38c30880140 Image: csrss.exe
Attached Process N/A Image: N/A
Wait Start TickCount 1282 Ticks: 10674 (0:00:02:46.781)
Context Switch Count 1192 IdealProcessor: 0
UserTime 00:00:00.000
KernelTime 00:00:00.078
Win32 Start Address winsrvext!GdiAddInitialFontsThread (0×00007ffc858f2710)
Stack Init 0000000000000000 Current ffffbe8295331670
Base ffffbe8295332000 Limit ffffbe829532c000 Call 0000000000000000
Priority 14 BasePriority 13 IoPriority 2 PagePriority 5
Child-SP RetAddr Call Site
ffffbe82`953316b0 fffffc57`1e5ba085 0×4
ffffbe82`953316b8 fffff806`6255f501 0xfffffc57`1e5ba085
ffffbe82`953316c0 000002ac`02048e80 nt!PspThreadFromTicket+0×51
ffffbe82`953316f0 ffffffff`ffffffff 0×000002ac`02048e80
ffffbe82`953316f8 ffffbe82`95331b60 0xffffffff`ffffffff
ffffbe82`95331700 ffffbe82`953319a0 0xffffbe82`95331b60
ffffbe82`95331708 fffff806`62136778 0xffffbe82`953319a0
ffffbe82`95331710 fffff806`62138fdc nt!IoRemoveIoCompletion+0×98
ffffbe82`95331830 fffff806`62227b75 nt!NtWaitForWorkViaWorkerFactory+0×39c
ffffbe82`95331a70 00000000`00000000 nt!KiSystemServiceCopyEnd+0×25

Please note that in case of Incorrect Stack Trace we can get Rough Stack Trace or try to reconstruct the one manually from Execution Residue:

0: kd> dpS ffffbe829532c000 ffffbe8295332000
fffff806`6210aeb4 nt!MiGetPerfectColorHeadPage+0×94
fffff806`624e9fa2 nt!PspGetContext+0×2e2
fffff806`62a54e00 nt!MiSystemPartition
fffff806`624e9aba nt!PspGetSetContextInternal+0×3aa
fffff806`624e9aba nt!PspGetSetContextInternal+0×3aa
fffff806`621090b1 nt!MiAddWorkingSetEntries+0×451
fffff806`62108965 nt!MiAllocateWsle+0×295
fffff806`62a54e00 nt!MiSystemPartition
fffff806`62107eac nt!MiCompletePrivateZeroFault+0×77c
fffff806`62a54e00 nt!MiSystemPartition
fffff806`62107315 nt!MiResolvePrivateZeroFault+0×1a5
fffff806`62105c28 nt!MiResolveDemandZeroFault+0×298
fffff806`62a54e00 nt!MiSystemPartition
fffff806`621290cc nt!MiDispatchFault+0×2ac
fffff806`6221db3d nt!PspGetSetContextSpecialApc+0×6d
fffff806`624ea5fd nt!PspSetContextThreadInternal+0×16d
fffff806`624e9083 nt!PspInitializeThunkContext+0×28f
00007ffc`884b6870 ntdll!TppWorkerThread
00007ffc`884a4830 ntdll!RtlUserThreadStart
fffff806`620d58e4 nt!EtwpEventWriteFull+0×3f4
fffff806`620d58e4 nt!EtwpEventWriteFull+0×3f4
fffff806`61e0f808 nt!ThreadWorkOnBehalfUpdate
fffff806`6221d818 nt!SwapContext+0×4d8
fffff806`6221d056 nt!KiSwapContext+0×76
fffff806`62132457 nt!KiSwapThread+0×3a7
fffff806`61e0f808 nt!ThreadWorkOnBehalfUpdate
fffff806`61e0f808 nt!ThreadWorkOnBehalfUpdate
fffff806`62134309 nt!KiCommitThreadWait+0×159
fffff806`62136d66 nt!KeRemoveQueueEx+0×2b6
fffff806`6255f501 nt!PspThreadFromTicket+0×51
fffff806`62136778 nt!IoRemoveIoCompletion+0×98
fffff806`6256d901 nt!ObpReferenceObjectByHandleWithTag+0×231
fffff806`6256d6be nt!ObReferenceObjectByHandle+0×2e
fffff806`62138fdc nt!NtWaitForWorkViaWorkerFactory+0×39c
fffff806`62227b75 nt!KiSystemServiceCopyEnd+0×25
fffff806`62227b75 nt!KiSystemServiceCopyEnd+0×25
00007ffc`88546f14 ntdll!NtWaitForWorkViaWorkerFactory+0×14

Such Historical Information may help in the reconstruction of past system behavior.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Trace Sketch can have several Trace Models (borrowed from model theory with sketches representing the logic of traces and logs) when messages satisfy trace and log analysis patterns sketched in Dia|gram language illustrations:

The same Trace Sketch induces an equivalence relation between different Trace Models, yet another Trace Similarity measure. Also, models of traces and logs having the same Trace Shapes may not be equivalent.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Trace Sketch embodies Dia|gram language approach: in essence each trace and log analysis pattern illustration is a sketch. For example, a WinDbg log is represented as sequence of different Activity Regions:

Another example of Trace Sketch is Trace Skeleton.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

When analyzing Execution Residue we are interested in valid symbolic references, for example, valid return addresses for Rough Stack Trace and Past Stack Trace reconstruction. Some of them may be Coincidental Symbolic Information that we check with backward disassembly. However, some symbolic references may be Function Pointers if forward disassembly starts with valid function prologue. Some references may also point to the start of exception processing in the middle of a normal function body. These two variants are illustrated with the following two addresses taken from the raw stack data when debugging an x64 Linux process in WSL using the latest version of WinDbg:

0:000> u 00007f73`e45820b0
libgcc_s_so!Unwind_Backtrace+0x7c0:
00007f73`e45820b0 push r15
00007f73`e45820b2 push r14
00007f73`e45820b4 push r13
00007f73`e45820b6 push r12
00007f73`e45820b8 push rbp
00007f73`e45820b9 push rbx
00007f73`e45820ba sub rsp,58h
00007f73`e45820be mov ecx,dword ptr [rdx+28h]

0:000> u 00005564`99d582c8
ud5bv3!start_modeling+0xd7:
00005564`99d582c8 mov rdi,rax
00005564`99d582cb call ud5bv3!_cxa_begin_catch$plt (00005564`99d58040)
00005564`99d582d0 call ud5bv3!_cxa_end_catch$plt (00005564`99d580b0)
00005564`99d582d5 jmp ud5bv3!start_modeling+0x64 (00005564`99d58255)
00005564`99d582da leave
00005564`99d582db ret
ud5bv3!new_feature:
00005564`99d582dc push rbp
00005564`99d582dd mov rbp,rsp

0:000> ub 00005564`99d582c8
ud5bv3!start_modeling+0xb5:
00005564`99d582a6 mov rdi,rax
00005564`99d582a9 call ud5bv3!sem_close$plt (00005564`99d580a0)
00005564`99d582ae mov rax,qword ptr [rbp-8]
00005564`99d582b2 mov rdi,rax
00005564`99d582b5 call ud5bv3!sem_close$plt (00005564`99d580a0)
00005564`99d582ba lea rdi,[ud5bv3!IO_stdin_used+0x4 (00005564`99d59004)]
00005564`99d582c1 call ud5bv3!sem_unlink$plt (00005564`99d580c0)
00005564`99d582c6 jmp ud5bv3!start_modeling+0xe9 (00005564`99d582da)

As we see, some Function Pointers may have symbolic name plus some offset if they don’t have associated symbols.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Feynman Trace borrows ideas from the path integral formulation of quantum mechanics. Such a trace includes all possible traces from all possible traces generated from all possible executions including Trace Amplitudes, Empty Traces, Use Case Trails, and traces with Error Messages, but excluding Impossible Traces:

Code flow Declarative Trace analysis can be used to assess the relative contributions of trace and log variants. To reduce infinities arising from loops, Renormalization can be used.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

This analysis pattern is a Linux variant of the previous Not My Version Windows crash dump analysis pattern. In case of segmentation faults/core dumps with Stack Traces involving OS and 3rd-party shared libraries it is worth noting directories they come from:

(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x00007fad170d5950 0x00007fad170e2dc8 Yes (*) /lib64/lib3rdparty.so.0
0x00007fad170c3130 0x00007fad170c3eb5 Yes /lib/x86_64-linux-gnu/libdl.so.2
0x00007fad16f24320 0x00007fad1706a14b Yes /lib/x86_64-linux-gnu/libc.so.6
0x00007fad17103090 0x00007fad17120b50 Yes /lib64/ld-linux-x86-64.so.2
0x00007fad16bfd300 0x00007fad16c03578 Yes /lib/x86_64-linux-gnu/libnss_files.so.2

If you use WinDbg to analyze Linux core dumps, you can use lmv command or its variant. It is worth noting that referenced libraries can be symbolic links to different versions than you expect. Unfortunately, it is not so easy to extract library timestamps, so it is recommended to additionally use Paratext analysis pattern to supply such information.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

A page to reference all different kinds of region-related analysis patterns is necessary, so I created this post:

• Hidden Exception (user space)
• Hidden Exception (kernel space)
• Hidden Exception (managed space)
• Rough Stack Trace (unmanaged space)
• Rough Stack Trace (managed space)
• Region Profile
• Region Clusters
• Region Summary
• Region Spectrum
• Normalized Region

I’ll update it as soon as I add more similar patterns.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

If we dump contents of memory regions such as thread stacks we get different region memory addresses due to ASLR. To compare such regions from different executions we need to make them Normalized Regions replacing varying address parts with a common symbolic denominator, for example, 0-based addresses (or some other non-digital symbols to account of the possibility of already existing similar 0-based addresses) and adjusting address offsets appropriately. For example, the following raw stack region from Foreign Stack analysis pattern (we do not normalize foreign stack addresses below):

00000055`adbfe000 00000000`00000000
00000055`adbfe008 00000000`00000000
00000055`adbfe010 00000000`00000000
00000055`adbfe018 00000000`00000000
00000055`adbfe020 00000000`00000000
…
00000055`adbffa58 00000000`00000008
00000055`adbffa60 00000055`adbffb28
00000055`adbffa68 00007ff7`96e116a3 module!func+0×13
00000055`adbffa70 00000055`ad8ffde0
00000055`adbffa78 00000000`00000000
00000055`adbffa80 00000000`00000000
00000055`adbffa88 00007ffa`28ecc9a8 ucrtbase!`string’
00000055`adbffa90 00000000`00000000
00000055`adbffa98 00007ff7`96e116c3 module!thread_proc+0×13
00000055`adbffaa0 00000055`ad8ffde0
00000055`adbffaa8 00000055`adbffb28
00000055`adbffab0 ffffffff`ffffffff
00000055`adbffab8 00007ffa`28fa0748 KERNELBASE!GetAppModelPolicy+0×18
00000055`adbffac0 00000055`adbffba0
00000055`adbffac8 00007ff7`96e12657 module!std::invoke<void (__cdecl*)(int *),int *>+0×27
00000055`adbffad0 00000055`ad8ffde0
00000055`adbffad8 00000055`adbffb00
00000055`adbffae0 00000055`adbffb18
…

--------`00000000 00000000`00000000
--------`00000008 00000000`00000000
--------`00000010 00000000`00000000
--------`00000018 00000000`00000000
--------`00000020 00000000`00000000
…
--------`00001a58 00000000`00000008
--------`00001a60 --------`00001b28
--------`00001a68 00007ff7`96e116a3 module!func+0×13
--------`00001a70 00000055`ad8ffde0
--------`00001a78 00000000`00000000
--------`00001a80 00000000`00000000
--------`00001a88 00007ffa`28ecc9a8 ucrtbase!`string’
--------`00001a90 00000000`00000000
--------`00001a98 00007ff7`96e116c3 module!thread_proc+0×13
--------`00001aa0 00000055`ad8ffde0
--------`00001aa8 --------`00001b28
--------`00001ab0 ffffffff`ffffffff
--------`00001ab8 00007ffa`28fa0748 KERNELBASE!GetAppModelPolicy+0×18
--------`00001ac0 --------`00001ba0
--------`00001ac8 00007ff7`96e12657 module!std::invoke<void (__cdecl*)(int *),int *>+0×27
--------`00001ad0 00000055`ad8ffde0
--------`00001ad8 --------`00001b00
--------`00001ae0 --------`00001b18
…

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Values in memory regions, when interpreted as addresses, such as stack can be classified according to their categories such as zero, module (code and data), heap, stack, Foreign Stack, Small Value, error, and out-of-range (for example, kernel space address in user space). Such classification can be encoded and optionally visualized as Region Spectrum:

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Generative AI LLM models such as GPT-4 can be used as Analysis Summary devices (although such summaries should be treated with caution and double-checked). For example, let’s look at the default !analyze -v WinDbg command summary:

Summarize:
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: ffffbc06b64895a0, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff80403c61981, address which referenced memory

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

Unable to load image \??\C:\WINDOWS\system32\drivers\myfault.sys, Win32 error 0n2

KEY_VALUES_STRING: 1

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

This summary is based on a Windows bugcheck (blue screen of death) analysis report. The specific error encountered is DRIVER_IRQL_NOT_LESS_OR_EQUAL with a stop code of 0xD1. This error indicates that a driver attempted to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that was too high, which is typically a result of drivers using improper addresses.

Key details from the analysis include:

• Memory Referenced (Arg1): ffffbc06b64895a0. This is the memory address that was being accessed when the error occurred.
• IRQL (Arg2): 2, indicating the interrupt request level at the time of the error.
• Operation Type (Arg3): 0, meaning a read operation was being performed.
• Address that Referenced Memory (Arg4): fffff80403c61981, the address within the driver or system component that attempted the illegal memory access.

Additional debugging details highlight that the error was caused by the myfault.sys driver, which is notably used for generating system crashes for testing purposes. The error occurred while running the process notmyfault64.exe, further suggesting that this was a deliberate test of system stability or error handling.

The analysis also included various technical details about the system state, such as CPU and memory usage metrics, the virtual machine environment (VMware), and other system flags. The failure bucket identifies the issue as an access violation (AV) within the myfault driver, without specifying a known function, indicating a potentially unknown or unexpected path within the driver causing the crash.

Given the context, it appears this crash was induced as part of a debugging or system testing exercise, likely to analyze how the system and its error handling mechanisms respond to driver-induced errors.

The following are Analysis Summaries from the two latest pattern cooperation case studies:

Spiking Thread, Top Module, Module Hint, and Memory Fluctuation

The analysis revolves around diagnosing a sluggish performance issue on a Windows 7 system, attributed to high CPU and physical memory usage by one of the svchost.exe processes. A process memory dump revealed a significantly large file size (almost 1.5 GB), hinting at abnormal behavior warranting a deeper investigation using crash and hang dump analysis techniques.

Key Observations:

1. Spiking Thread Pattern: Initial analysis identified a single thread consuming a disproportionate amount of CPU time, indicative of a Spiking Thread pattern. This thread, identified through the !runaway command in WinDbg, significantly outpaced other threads in both user and kernel mode time.
2. Windows Update Agent Activity: The stack trace of the spiking thread pointed to activity related to the Windows Update Agent (wuaueng.dll), suggesting that the Windows Update process was contributing to the system’s sluggish performance.
3. Heap Usage and Potential Memory Leak: Examination of the process address space showed nearly 1 GB occupied by the process heap, with many large virtual blocks allocated. This was suspected to be indicative of a memory leak.
4. Temporary Condition: Interestingly, the system’s performance normalized after about 20 minutes, and a subsequent memory dump was significantly smaller (less than 150 KB). Analysis of this dump showed a different thread (#32) as having consumed CPU time in the past, but with the system no longer exhibiting high CPU or memory usage.
5. Memory Fluctuation: The investigation concluded that the observed behavior was a case of Memory Fluctuation, associated with the temporary demands of the Windows Update process. The initial large memory usage and CPU consumption were temporary and resolved without intervention, as evidenced by the normalization of resource usage and the significant reduction in the size of the process memory dump.

Conclusion:

The investigation showcases the importance of crash and hang dump analysis in diagnosing and understanding transient performance issues in Windows systems. It highlights how system processes, in this case, the Windows Update Agent, can temporarily consume significant system resources, leading to performance degradation. The analysis also demonstrates the system’s ability to recover from such states, emphasizing the temporary nature of certain performance issues.

Exception Stack Trace, Stored Exception, Translated Exception, Execution Residue, Hidden Exception, NULL Pointer, Exception Module, Stack Trace Motif, No Component Symbols, and Coincidental Symbolic Information

The analysis provided deals with an investigation into a series of crashes of the backgroundTaskHost.exe on a system, focusing on the crash dumps found in a specified folder set up through the LocalDumps Windows Error Reporting (WER) registry. These crashes are characterized by a consistent Exception Stack Trace and a Stored Exception that suggests a security vulnerability (stack buffer overrun) potentially exploitable by malicious actors. The investigation involves detailed WinDbg command outputs, providing insight into the nature of the crashes, the involved modules, and the potential causes.

Key Findings:

1. Consistent Crash Cause: All crash dumps share the same Exception Stack Trace and Stored Exception, indicating a consistent failure mode across multiple instances. The failure is identified as a stack buffer overrun (c0000409), a type of vulnerability that could allow unauthorized control over the application.
2. Exception Stack Trace Analysis: The stack trace points to several modules, including ucrtbase, vccorlib140_app, and Microsoft_Applications_Telemetry_Windows, among others. The presence of multiple calls to DllGetActivationFactory and the involvement of telemetry-related functions suggest the crashes may be related to the handling of telemetry data.
3. Translated and Hidden Exceptions: The analysis reveals a discrepancy between the exception addresses and contexts reported by different WinDbg commands, suggesting the presence of translated exceptions. Further examination of the execution residue uncovers hidden exceptions, indicating that the initial crash may be concealing additional underlying issues.
4. Module Involvement and Symbolic Information: The Microsoft_Applications_Telemetry_Windows module is highlighted as a significant factor in the crashes, particularly due to its association with telemetry data processing functions. However, the analysis also suggests that the symbolic information for this module may be coincidental, due to the absence of component symbols and an unusually large offset for the getJsonFormattedEvent function.
5. Function Size Discrepancy: Discrepancies in the expected size of the getJsonFormattedEvent function, compared to its offset, raise questions about the accuracy of the symbolic information provided. This discrepancy also complicates the search for pointers to JSON strings in the memory dump, as typical commands do not reveal expected patterns.

Overall, the analysis suggests that the crashes may be related to the processing of telemetry data, potentially due to a stack buffer overrun vulnerability in the backgroundTaskHost.exe. The involvement of the Microsoft_Applications_Telemetry_Windows module and discrepancies in symbolic information point to the need for further investigation, including the possibility of missing or inaccurate debugging symbols that could clarify the root cause of these crashes.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Generative AI LLM models such as GPT-4 are very good at annotation and summarization of memory regions (Region Summaries) with symbolic information and may provide additional insight even without symbolic information (although all such insights should be treated with caution):

Summarize:
0: kd> dpS ffffa7848e4c5000 ffffa7848e4cb000
fffff804`04c0fa78 nt!HalpApicRequestInterrupt+0xd8
fffff804`04d2b18d nt!HalpInterruptSendIpi+0xfd
fffff804`04d091f1 nt!MiAddWorkingSetEntries+0x451
fffff804`04a0f800 nt!MiFreeThenFree
fffff804`04d08aa5 nt!MiAllocateWsle+0x295
fffff804`04d0a520 nt!MiGetPageChain+0xeb0
fffff804`05654fc0 nt!MiSystemPartition
fffff804`04d07fec nt!MiCompletePrivateZeroFault+0x77c
fffff804`04cd2d1d nt!HalRequestIpiSpecifyVector+0x7d
fffff804`04cd2aa7 nt!KiIpiSendRequest+0x397
fffff804`04d5f66c nt!KiIpiSendRequestEx+0x88
fffff804`04d5f5d1 nt!KxFlushEntireTb+0x1a5
fffff804`04c31710 nt!KiFlushCurrentTbWorker
fffff804`05654fc0 nt!MiSystemPartition
fffff804`04d5eccd nt!KeFlushTb+0xa1
fffff804`04c65e3e nt!MiFlushEntireTbDueToAttributeChange+0x4a
fffff804`04d0b1c4 nt!MiGetPerfectColorHeadPage+0x94
fffff804`05654f00 nt!PnpSystemHiveTooLarge
fffff804`04c6cfad nt!MiChangePageAttribute+0xed
fffff804`04cf7fc6 nt!MiFlushTbAsNeeded+0x156
fffff804`04d50053 nt!MiGetContainingPageTable+0x43
fffff804`04d4fc5c nt!MiAssignNonPagedPoolPte+0x1ac
fffff804`04c0fa78 nt!HalpApicRequestInterrupt+0xd8
fffff804`04c0fa78 nt!HalpApicRequestInterrupt+0xd8
fffff804`04d2b18d nt!HalpInterruptSendIpi+0xfd
fffff804`04cf86a6 nt!MmAllocatePoolMemory+0xca
fffff804`05654fc0 nt!MiSystemPartition
fffff804`04c6feeb nt!MiReplenishPageSlist+0x31b
fffff804`05654fc0 nt!MiSystemPartition
fffff804`05654fc0 nt!MiSystemPartition
fffff804`04c1356a nt!HalPerformEndOfInterrupt+0x1a
fffff804`05655a00 nt!MiSystemPartition+0xa40
fffff804`04d2ee05 nt!ExReleaseAutoExpandPushLockShared+0x85
fffff804`0960cfde Ntfs!NtfsLookupNtfsMcbEntryWithSyncFlag+0x14e
fffff804`04e1e197 nt!SwapContext+0x1c7
fffff804`056eabd0 nt!KiAbTreeArray+0x52d0
fffff804`04cfb100 nt!KiAbEntryGetLockedHeadEntry+0x2a0
fffff804`04e1dce6 nt!KiSwapContext+0x76
fffff804`04cc0d52 nt!KiCancelTimer+0x262
fffff804`05653500 nt!MiState+0x4480
fffff804`05653500 nt!MiState+0x4480
fffff804`04cdd148 nt!MiReservePtes+0x48
fffff804`09543e42 Wof!WofPostReadCallback+0x72
fffff804`096086a9 Ntfs!NtfsVerifyAndRevertUsaBlock+0x25d
fffff804`0893676f FLTMGR!FltpPerformPostCallbacksWorker+0x3bf
fffff804`04d2ba3b nt!KeQueryCurrentStackInformationEx+0x8b
fffff804`04c0fa78 nt!HalpApicRequestInterrupt+0xd8
fffff804`04d2b18d nt!HalpInterruptSendIpi+0xfd
fffff804`04d2f11f nt!KeSetEvent+0xdf
fffff804`04cc5dc7 nt!IopFreeIrp+0xf7
fffff804`04d34cc7 nt!IofCompleteRequest+0x17
fffff804`09619028 Ntfs!NtfsExtendedCompleteRequestInternal+0x218
fffff804`04d2ee05 nt!ExReleaseAutoExpandPushLockShared+0x85
fffff804`04d0e611 nt!MmCheckCachedPageStates+0x681
fffff804`05659240 nt!MiSystemPartition+0x4280
fffff804`04d0e611 nt!MmCheckCachedPageStates+0x681
fffff804`05654fc0 nt!MiSystemPartition
fffff804`05654fc0 nt!MiSystemPartition
fffff804`04d30071 nt!MiUnlockWorkingSetShared+0x81
fffff804`04d2ee05 nt!ExReleaseAutoExpandPushLockShared+0x85
fffff804`04d0e611 nt!MmCheckCachedPageStates+0x681
fffff804`0960feca Ntfs!NtfsCheckMappingPairs+0xea
fffff804`0960cfde Ntfs!NtfsLookupNtfsMcbEntryWithSyncFlag+0x14e
fffff804`04c9b51a nt!SepNormalAccessCheck+0x1fa
fffff804`04d2f11f nt!KeSetEvent+0xdf
fffff804`04d0e611 nt!MmCheckCachedPageStates+0x681
fffff804`04c9ad64 nt!SepAccessCheck+0x304
fffff804`0960fe00 Ntfs!NtfsCheckMappingPairs+0x20
fffff804`054351f8 nt!IopFileMapping
fffff804`04c9a570 nt!SeAccessCheckWithHint+0x640
fffff804`054351f8 nt!IopFileMapping
fffff804`054351f8 nt!IopFileMapping
fffff804`09721fb2 Ntfs!TxfAccessCheck+0x192
fffff804`05163eff nt!CcUnpinData+0x1f
fffff804`054351f8 nt!IopFileMapping
fffff804`04c93842 nt!FsRtlCheckOplockEx2+0x922
fffff804`04d3027b nt!ExReleaseResourceLite+0xeb
fffff804`050f44bb nt!SeUnlockSubjectContext+0x1b
fffff804`0971f872 Ntfs!NtfsAccessCheck+0x11b2
fffff804`04c92f0c nt!FsRtlCheckOplockEx+0x3c
fffff804`09721b48 Ntfs!NtfsOpenAttribute+0x1768
fffff804`0971e585 Ntfs!NtfsCheckExistingFile+0x775
fffff804`096e7a2c Ntfs!NtfsBreakBatchOplock+0xfc
fffff804`0971dce2 Ntfs!NtfsOpenExistingAttr+0x252
fffff804`0971d6cb Ntfs!NtfsOpenAttributeInExistingFile+0xcbb
fffff804`04d2dae9 nt!FsRtlLookupPerStreamContextInternal+0x1a9
fffff804`04d2ee05 nt!ExReleaseAutoExpandPushLockShared+0x85
fffff804`08934f4e FLTMGR!FltGetStreamContext+0xce
fffff804`095637c6 Wof!WofPostCleanupCallback+0xa6
fffff804`0893676f FLTMGR!FltpPerformPostCallbacksWorker+0x3bf
fffff804`04d302d6 nt!ExReleaseResourceLite+0x146
fffff804`05157ff1 nt!HvpGetCellContextInitialize+0x15
fffff804`051580aa nt!HvpMapEntryGetBlockAddress+0xe
fffff804`05157fcf nt!HvpReleaseCellPaged+0x2f
fffff804`05158072 nt!HvpGetCellPaged+0x72
fffff804`05157ff1 nt!HvpGetCellContextInitialize+0x15
fffff804`0515be21 nt!CmpCompareInIndex+0x211
fffff804`05157fcf nt!HvpReleaseCellPaged+0x2f
fffff804`04cc684c nt!KiSetAddressPolicy+0xc
fffff804`04cc6b6d nt!KiStackAttachProcess+0x24d
fffff804`04d2cd97 nt!wil_details_FeatureReporting_ReportUsageToServiceDirect+0xd7
fffff804`05157ff1 nt!HvpGetCellContextInitialize+0x15
fffff804`05157fcf nt!HvpReleaseCellPaged+0x2f
fffff804`04cc684c nt!KiSetAddressPolicy+0xc
fffff804`04c842f7 nt!wil_details_FeatureReporting_ReportUsageToService+0x37
fffff804`04cc6de5 nt!KiSwapProcess+0x75
fffff804`04cc6faa nt!KiUnstackDetachProcess+0x17a
fffff804`054b132b nt!CmpDetachFromRegistryProcess+0xb
fffff804`0517eee1 nt!CmpDoParseKey+0x2f11
fffff804`096e8d01 Ntfs!NtfsCompleteCleanupRequest+0x51
fffff804`04d40000 nt!MiFreeWsleList+0x130
fffff804`05654fc0 nt!MiSystemPartition
fffff804`095e71be WdFilter+0x571be
fffff804`095c8c5f WdFilter+0x38c5f
fffff804`04d2cd97 nt!wil_details_FeatureReporting_ReportUsageToServiceDirect+0xd7
fffff804`051b1ac1 nt!VrpRegistryCallback+0xc1
fffff804`0517f9c5 nt!CmpCallCallBacksEx+0x3f5
fffff804`04d2ce3f nt!CmpIsRegistryLockAcquired+0x2f
fffff804`0517bd15 nt!CmpParseKey+0x445
fffff804`04d28a55 nt!MiFastLockLeafPageTable+0x175
fffff804`04d24578 nt!MiGetPageProtection+0x408
fffff804`04d23a2e nt!MiQueryAddressState+0x6ee
fffff804`095e0000 WdFilter+0x50000
fffff804`04d1abe6 nt!MiQueryAddressSpan+0x1e6
fffff804`04d1a862 nt!MiUnlockAndDereferenceVadShared+0x62
fffff804`0517785c nt!MmQueryVirtualMemory+0x6bc
fffff804`0896d280 FLTMGR!FltpFastIoWrite+0x190
fffff804`0516dfc1 nt!ObpReferenceObjectByHandleWithTag+0x231
fffff804`0516dd41 nt!ObReferenceObjectByHandleWithTag+0x31
fffff804`0516ac7b nt!ObWaitForSingleObject+0xdb
fffff804`0516ab8a nt!NtWaitForSingleObject+0x6a
fffff804`04e28775 nt!KiSystemServiceCopyEnd+0x25
00007ffe`4d2637d4 ntdll!NtWaitForSingleObject+0x14

This output appears to be from the dpS (display words and symbols) debugger command, which is listing memory contents and associated symbols within a specified range (from ffffa7848e4c5000 to ffffa7848e4cb000). The listing shows addresses in memory alongside their corresponding symbol names, indicating various kernel and system functions being referenced in this memory range.

• Functions from nt! (the NT kernel) dominate the list, suggesting this memory range is heavily involved in core operating system operations. This includes interrupt handling (HalpApicRequestInterrupt), memory management (MiAllocateWsle, MiGetPageChain), process and thread management (KiSwapProcess, KiUnstackDetachProcess), and others.
• Specific actions related to memory management and page table entries are frequent, such as MiFlushEntireTbDueToAttributeChange, indicating operations that involve modifying the Translation Lookaside Buffer (TLB) as part of memory attribute changes.
• There are references to file system operations and filter manager functions (e.g., Ntfs!NtfsOpenAttribute, FLTMGR!FltpPerformPostCallbacksWorker), pointing to disk I/O and file system activities within this memory range.
• Several entries related to security and access control (e.g., SepAccessCheck, SeAccessCheckWithHint), showing that some operations in this range involve security checks.
• The presence of symbols like WdFilter suggests Windows Defender operations, possibly indicating anti-malware activities happening or logged within this memory segment.
• The repeated appearance of certain base addresses (MiSystemPartition) and operations (e.g., ExReleaseAutoExpandPushLockShared, KeSetEvent) highlights system-level management tasks, including synchronization and event signaling.
• Additionally, there are references to Registry operations (e.g., CmpCallCallBacksEx, CmpParseKey), indicating some part of this memory is used for Registry access and manipulation.

Overall, the memory range contains a mix of low-level kernel operations, security checks, file system interactions, and system state management tasks, reflecting the complex and interwoven nature of operating system activities. This kind of data is typically used for deep debugging and analysis of system behavior, performance tuning, or troubleshooting specific issues.

Explain:
0: kd> dpp rsp
00000033`d2d7c1d8 00007ffe`1c9e705c 78c08500`00441f0f
00000033`d2d7c1e0 00007ffe`1ca0e818 00000000`00666544
00000033`d2d7c1e8 00000000`00001434
00000033`d2d7c1f0 0000015f`3fed7680 6f46203a`6c707041
00000033`d2d7c1f8 00007ffe`1ca07bea ccccccc3`28c48348
00000033`d2d7c200 00000000`000023b4
00000033`d2d7c208 0000015f`3db4c7b0 00000073`006c0043
00000033`d2d7c210 00000000`00000000
00000033`d2d7c218 00000000`00000000
00000033`d2d7c220 00000033`d2d7c2c8 00000000`04000000
00000033`d2d7c228 00007ffe`1ca02fb6 00000218`36ac8946
00000033`d2d7c230 00000033`d2d7c2c8 00000000`04000000
00000033`d2d7c238 00000000`00000000
00000033`d2d7c240 00007ffe`1ca1578c 00000000`00530025
00000033`d2d7c248 00007ffe`1ba95124 63656e6f`00000044
00000033`d2d7c250 00000000`00000000

The dpp command in the Windows Debugger (WinDbg) displays memory contents at the address specified by the stack pointer register (rsp) and attempts to resolve any pointers to their symbolic names, essentially showing a double word pointer list from the specified location.

Here’s a breakdown of the information provided by the output:

• Each line shows two memory addresses. The left side shows the address being inspected, and the right side shows the content at that address, which may be a value or a pointer to another memory location. If the content is a pointer and a symbol is available, it will show the symbol name next to it.
• For instance, the first line shows the memory address 00000033d2d7c1d8 contains the pointer 00007ffe1c9e705c, which doesn’t have an associated symbolic name provided in this snippet. This could be a function pointer, object pointer, or data pointer depending on the context which isn’t fully given here.
• The output includes pointers to various memory locations, and some lines display what appears to be function pointers (e.g., 00007ffe1c9e705c) and possibly some constants or flags right next to them (e.g., 78c08500`00441f0f). Without more context or symbol information, it’s difficult to specify exactly what each value represents.
• The snippet mentions several pointers that seem related to executable modules (indicated by the 7ffe segment in the addresses, which is common for user-mode addresses on a 64-bit system). These could point to functions or data structures within those modules.
• Addresses like 0000015f3fed7680 or 0000015f3db4c7b0 appear to be heap or dynamically allocated memory addresses due to their range, which differs from the typical ranges used for executable modules or stack memory.

Without the full context, such as the associated source code, loaded modules list, or symbols, it’s challenging to derive a meaningful interpretation of what each pointer or value represents in this scenario. Typically, this command is used by developers or analysts to inspect the call stack, arguments to functions, or specific data structures in memory during debugging sessions to understand the state of an application or diagnose issues.

Please note, symbolic addresses may be Coincidental. Raw stack regions may also be treated as Rough Stack Trace with the corresponding Annotated Stack Traces.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -