This is what happens when I leave the computer idle for a while and the Windows automatic maintenance starts:

Driver file      Description               ISR count  DPC count  Highest execution (ms)  Total execution (ms)
------------------------------------------------------------------------------------------------------------------
ntoskrnl.exe  NT Kernel & System   0              50764        0,235854                      332,950426

A DPC spike is generated by ntoskrnl.exe causing drop outs in real-time streams.

Hi Fjtorsol,

We hope your issue has been resolved, if you've found solution by yourself. you could share with us and we will mark it as answer.

This high Deferred Procedure Call (DPC) latencies are usually caused by certain drivers, if it is caused by automatic maintenance, please re-check your task schedule which is marked as when computer is idle. As what has been suggested by MVP ZigZag, please use the Microsoft Windows Performance Analyzer from the Windows Assessment and Deployment Kit (ADK) to identify the cause of any DPC latency spikes.

https://www.microsoft.com/en-gb/download/details.aspx?id=39982

DPC CPU Usage Summary Table will open containing a list of drivers/program. This list is already correctly sorted (by the Actual Duration column). The process on the very top of the list is therefore likely to be the cause of your problem.

Regards

D. Wu

FJ

There is too little data to come to a definitive conclusion.

Both storport and NDIS are showing SLIGHT DPC latency but if you are concerned about the drop outs the real culprit is the Microsoft immersive control panel (systemsettings.exe).  It is driving both the system and svchost.exe (system 23% & svchost %20).  This would seem to make sense given your description of the spike at auto maintenance kickoff.

Quite a few hits on a Google of immersive control panel and high dpc and the most frequently seen course of action is to run a system file check & DISM.

The NDIS spike always happens whenever I start a recording (as you can see it is coincident with the beginning of the recording). STORPORT is another story in this dump it matches exactly with the MSMPENG scheduled system analysis but also happens with MSIEXEC interactions such as starting MSI or MSP based installations. Apparently both MSMPENG and MSIEXEC make some high priority calls to STORPORT causing the spike. I have been able to reproduce this behavior in every machine I have tested since Windows 7.

It has to be this because it started to happen systematically just after I enabled Windows Defender and in the previous Windows 7 installations I was using MSE. Anyway I have to upload a dump reflecting the same issue for MS