Just to show what I'm looking at during analysis.
Attached is a screenshot of what I believe are the relevant graphs in MXA. The top graph shows ISR/DPC storms and the green lines show points in time where a group of ISRs and DPCs ran long enough to cause audible interruptions in the audio output stream - a green vertical line going above the red horizontal line and into the red area at the top.
The middle graph is the Windows scheduler and I've filtered it to show only activity on core 0 which is the core running the audio output stream.
The bottom graph is the callstack graph which I believe are samples of the callstack of the thread running on a core taken at regular intervals. It's not precise but the samples are taken frequently enough to where it can catch a relevant callstack. There's some luck involved, though.
If I zoom in on one of the green spikes in the top graph (2nd attached picture) the pink box in the middle graph shows an ndis.sys DPC running for almost 3 milliseconds which is far longer than any other ISR/DPC for that 10 millisecond period. The third picture is the same screenshot with all ISR/DPCs showing.
Focusing on the ndis DPC, I look through the callstacks on core 0 in the bottom graph shortly before and during the time that DPC is running. The spike I focused on in the screenshots is an example where the sampling didn't catch the call, unfortunately.
Zooming in on other spikes in the ISR/DPC storm graph, though, I do see some callstacks using ndis.sys which are leaving me confused. For example:
[CODE]0 / 1
Callstack at time 3898770500 - Not matched - Forzahorizon5 <ForzaHorizon5.exe> (PID-5808) - Thread-1168 (ForzaHorizon5.exe!0x7FF7E4302AC0) - Unit:# 7676
ntoskrnl.exe!KiExitDispatcher
ntoskrnl.exe!KeSetEvent
afd.sys!AfdReceiveDatagramEventCommonHandler
afd.sys!AfdTLDgramReceiveEventHandler
tcpip.sys!UdpDeliverDatagrams
tcpip.sys!UdpReceiveDatagrams
tcpip.sys!UdpNlClientReceiveDatagrams
tcpip.sys!IpFlcReceivePreValidatedPackets
tcpip.sys!FlReceiveNetBufferListChainCalloutRoutine
ntoskrnl.exe!KeExpandKernelStackAndCalloutInternal
ntoskrnl.exe!KeExpandKernelStackAndCalloutEx
tcpip.sys!NetioExpandKernelStackAndCallout
tcpip.sys!FlReceiveNetBufferListChain
ndis.sys!ndisMIndicateNetBufferListsToOpen
ndis.sys!ndisMTopReceiveNetBufferLists
ndis.sys!ndisCallReceiveHandler
ndis.sys!ndisInvokeNextReceiveHandler
ndis.sys!NdisMIndicateReceiveNetBufferLists
e1d.sys!0xFFFFF802A48F9BAB
e1d.sys!0xFFFFF802A48FAEB0
e1d.sys!0xFFFFF802A4900EE0
e1d.sys!0xFFFFF802A4903272
e1d.sys!0xFFFFF802A49026C2
ndis.sys!ndisMiniportDpc
ndis.sys!ndisQueuedMiniportDpcWorkItem
ndis.sys!ndisPeriodicReceivesTimer
ntoskrnl.exe!KiExecuteAllDpcs
ntoskrnl.exe!KiRetireDpcList
ntoskrnl.exe!KxRetireDpcList
ntoskrnl.exe!KiDispatchInterruptContinue
ntoskrnl.exe!KiDpcInterruptBypass
ntoskrnl.exe!KiInterruptDispatchNoLockNoEtw
[/CODE]
That it's a Forzahorizon5.exe thread is irrelevant. The thread was taken over by the scheduler and it could have picked any thread. The relevant part (I think) is the callstack shows a driver with the filename e1d.sys which is making use of ndis.sys. But searches don't seem to show what I would consider reliable information about that driver. Can you do a search for that driver on your C: drive and see if you can identify what might have installed it? I can't find that driver anywhere on the two systems I have.
edit: Actually, I just noticed e1d.sys shows up as a miniport driver for the Ethernet adapter in your latest screenshot so I'm guessing it's a legitimate driver from Intel.
