Thanks, it told me what I expected to see. If we look at the call stack in the dump, that's the return stack containing the functions called in the lead-up to the bugcheck, and which you read from the bottom up (it's a push-down stack)...
Code:
7: kd> k
# Child-SP RetAddr Call Site
00 ffffaa03`55ebc928 fffff800`72c2ae29 nt!KeBugCheckEx
01 ffffaa03`55ebc930 fffff800`72c26289 nt!KiBugCheckDispatch+0x69
02 ffffaa03`55ebca70 fffff800`72c1e94b nt!KiPageFault+0x489
03 ffffaa03`55ebcc00 fffff800`72c19ff6 nt!SwapContext+0xcb
04 ffffaa03`55ebcc40 00000000`00000000 nt!KiIdleLoop+0x176
You can see that the processor (#7) started in the idle state, it was running the nt!KiIdleLoop function which basically loops until new work arrives. We then get a context swap into the context of the work that has arrived via the nt!SwapContext function. Immediately we get a page fault (nt!KiPageFault) indicating that a memory page has been referenced which is invalid (not allocated, paged out, or bad) and that should not happen - this is all Microsoft code remember.
This is exactly what we normally see when a CPU has become tardy in switching from the low-power idle C-State to the high-power running C-State as we come out of the idle loop.
There is no fix for a CPU that is having power transition problems but there is a workaround which is also a test for whether this is indeed the cause of your BSODs. Go into the BIOS setup and find the CPU C-States settings. Disable ALL C-States for ALL processors. This will prevent the processors from transitioning to a low-power state when they become idle, and that will stop the power transition problem when they get new work to do.
There are two downsides to disabling C-States....
- The processors will consume more power in the idle state, but I doubt the extra electricity used is even measurable.
- The CPU will run hotter in the idle state, but a decent CPU cooler should have no difficulty in handling this heat.
Let us know whether disabling C-States stops the BSODs.