Good news: the nature of the "midnight" freeze is easy to see in the logs.
Bad news: Insufficient info (in Xperf) to tell which driver is responsible
Suggestion: do the "midnight" capture once more please, but this time crash the box on purpose afterwards so that a BSOD minidump is generated (once you've saved your data). Here's how...
1) Add the "CrashOnCtrlScroll" registry value as per this MSDN article: Forcing a System Crash from the Keyboard
2) Reboot at least once. Test that your machine then bugchecks (BSODs) whenever you press ctrl+ScrLk+ScrLk, and that it produces a minidump in \Windows\Minidump. (The minidump is the important part.)
3) For the next "midnight run", use: xperf -on PROC_THREAD+LOADER+INTERRUPT+DPC+PROFILE+DISPATCHER+DRIVERS+CSWITCH -stackwalk profile
4) A few minutes after you finish and save the Xperf logging, use ctrl+ScrLk+ScrLk to crash the machine and produce a minidump.
that the Xperf log and minidump be from the same boot. In other words, the crash has to occur after you run Xperf, but before
you reboot. The combination of Xperf log and minidump may reveal more.
Longer version: you can see in the attached graph, which is a composite of several overlaid quantities, that everything else seems to cease during that phallic-looking "DPC" spike (in red). Think of a DPC as a very primitive and high-priority task that temporarily suspends everything else on the system. They normally occur somewhere between 200 and 500 times per second on your machine, but during the 1sec interval around that spike there are in excess of 98 thousand DPCs. Their combined effect is the temporary lockup that you experience - the system is so busy servicing DPCs that all other activity is basically suspended.
The table I attached shows the address of the function responsible as 0x8e4536c0. That's outside of the kernel range, and very probably a driver. The problem is that I can't tell which
driver because of a randomisation feature that moves those addresses around on each boot (partially for security reasons). That's why the combination of Xperf log plus minidump may reveal which driver is involved - the minidump can be used to correlate the address to a particular driver name.
I have no idea whether this will lead to a practical solution, but hell, it's fun (at least for me
), and it may even pinpoint the hardware/driver combo that's doing weird stuff at midnight.