My system using Windows 10 (October release) with 2 SSDs and 6 Hard Drives, has been freezing for 10 or more seconds fairly randomly. Using Windows Performance Toolkit, I isolated this down to ACPI.sys.
Here is a picture showing the Video frames going to 0 for 15+ seconds:
Zooming into this area I see it calls ntoskrnl.exe!KiExecuteAllDpcs, which calls into iaStorAC.sys. Since I do not have symbols for iaStor.sys, I do not know what function is being called.
However, expanding the call I see iaStorAC.sys calling storport.sys!StorPortStallExecution, which in turn calls hal.dll!KeStallExecutionProcessor, which in turn calls itself and invokes KeStallExecutionProcessor. It does this over 9,000 times and apparently while under a rather global lock. When whatever iaStorAC.sys is waiting for completes, iaStorAC.sys returns to ACPI.sys, who eventually releases the lock, returns, and my video, sound, keyboard, mouse, and every other item on my computer spring back to life.
This has been horrible for my online experiences as competitive gaming does not bode well when one's computer is essentially locked-up delaying execution for multiple seconds at the expense of everything else the computer is doing.
When I went into Windows power policy and changed the power setting to NEVER power down the disk drives, this behavior stopped. But my point is, I shouldn't have to do that. This behavior is just wrong.
My version of iaStorAC.sys is 126.96.36.1990 last modified 12/6/2018 @ 4:48 PM
I have no idea how many others this affects, but the forums at NVidia surrounding stalls, stuttering, and freezes around the new GTX 20xx series are super abundant. That was where I went originally because my video froze solid, and as this was a new card, in a new build, and many others were having similar experiences, it took me longer than I had hoped to isolate down to root cause.
I urge you to investigate the iaStoreAC.sys driver, and find and fix this abhorrent behavior.
If you isolated it down to ACPI.sys, then the problem is likely in the ACPI tables - which are provided by the BIOS - and this is something that you need to be discussing with the support folks for your motherboard vendor, not Intel.
And that was my first thought after discovering ACPI.sys was involved, and prior to discovering iaStorAC.sys was involved. I disabled all power management in the BIOS. Went to a pure HIGH POWER plan in Windows. The only thing that I had enabled in the power plan was to turn off Hard disks after an hour of inactivity, and allow the keyboard and mouse to wake over USB. Other than that there should have been no power events coming from ACPI.sys. The time when the freeze would come was random in nature as one could never tell when the 1 hour for the disk timeout would expire. It could be 10 minutes from logging on, or a full 60 minutes from logging on. I did contact the motherboard manufacturer. They did not have a significant number of customers complaining about freezes. At that point it became impossible to distinguish if it was a motherboard hardware problem, a motherboard firmware problem, a Windows problem with ACPI.sys, or something else in the October update? That was when I started to examine what the heck ACPI.sys was doing and found the majority of the time during the pause was spent inside iaStoreAC.sys. When it was clear it was a power request for a hard drive, it became clear that the source of the request was not from the motherboard or the hardware; it was from the timer expiring in Windows.
At that time I disabled the sleep of all disks and the problem vanished. It could be possible that it is a single drive that is causing the driver grief during power down. But why would a driver, in the act of powering down a disk, need to spin on a condition for seconds at high IRQL? Thats what DPCs are for. Delay a bit and look again. Powering down a disk does not require microsecond timing. Come back and check later. When the drive has powered down, its job is complete and no more DPCs would be required for that event.