Thanks.
The trace looks really interesting:
The image above (the lower part) represents one of the DPC spikes (there are quite many of these) on your system. As LatencyMon already pointed to you, the DPC is related to
storahci.sys driver. Now the interesting part is the stack trace (the upper half of the image) for this:
HTML:
|- ntoskrnl.exe!KiIdleLoop
| |- ntoskrnl.exe!KiRetireDpcList
| | ntoskrnl.exe!KiExecuteAllDpcs
| | |- storahci.sys!AhciPortBusChangeDpcRoutine
| | | storahci.sys!PortBusChangeProcess // If link speed was limited, restores the supported value, kicks off the Start Channel state machine, requests rescan on this port
| | | storahci.sys!AhciPortReset // Performs COMRESET along with completing commands to be retried and restoring settings that may be be persistent across a COMRESET
| | | storahci.sys!AhciCOMRESET // Performs interface communication initialization sequence to establish communication. This is functionally equivalent to a hard reset and results in the interface being reset and communications reinitialized
| | | hal.dll!KeStallExecutionProcessor
| | | |- hal.dll!KeStallExecutionProcessor<itself>
The interesting things here are:
- We have controller port resetting itself
- The above (resulting into these DPC spikes) is happening in the Idle loop and are not being triggered by some third party process or driver
For starters, could you please try installing
Intel® Rapid Storage Technology driver? If I am not mistaken, after installation Intel driver (iaStorA.sys) should take over operations from default Microsoft driver (storahci.sys) or at least add additional layer above it. Since the Intel driver should probably be able to deal with Intel controller better, there's a chance it might solve the issues.
In case the issues persist, please generate a new CPU.etl trace.
