Since I've been started getting bit by the "30% idle CPU usage", I've started to try to diagnose the problem. The symptoms of this "issue" are more or less well-known and defined, from what I read on these forums: on some boots, the "System" plus the "System Interrupts" item on task manager will be stuck to a combined ~30% CPU usage, and thus the CPU will never idle to 0%, as it does on "normal boots". This results in a system that is quite warm to the touch even if it's been used only to browse Bing News. "System" often has a slightly larger CPU use than "System interrupts", but the two combined always use around 25-30% CPU. No other processes are involved. All Surface Pro 2 models affected (4300U, 4200U included). A reboot, sleep or hibernate is often enough to get back to normal. The issue seems to only appear after a cold power-on. Possible causes: I use mostly Gentoo on my Surface so my Windows partition is "as is", except that I run all the updates as they come in. Thus none of my experiences can be blamed on "3rd party programs". Also, Gentoo never shows these symptoms: therefore this is not a hardware problem. Lots of people mention it is related to whether a SD card has been inserted or not. Personally I doubt SD card hardware has any relation (SD card reader is basically a simple USB device). See following discussion for more details. Audio may be related. In my experience, starting playing audio using e.g. Windows Media Player makes the problem go away. CPU usage only goes back to 30% when I close Windows Media Player. [HR][/HR] So today I ran LatencyMon while affected by the problem. This problem is designed to estimate "average" latency of system timers, and it does this by measuring how much time is spent processing interrupts or DPCs, which may delay system timers. Obviously, for the issue at hand, I was more interested in the second aspect of the tool: measuring time spent processing interrupts. Here are some interesting tidbits from the results. But first, my hardware specs: Code: OS version: Windows 8 , 6.2, build: 9200 (x64) Hardware: Surface Pro 2, Microsoft Corporation CPU: GenuineIntel Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz RAM: 8112 MB total Code: REPORTED ISRs Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal. Highest ISR routine execution time (µs): 78,728148 Driver with highest ISR routine execution time: ACPI.sys Highest reported total ISR routine time (%): 5,166394 Driver with highest ISR total time: ACPI.sys Total time spent in ISRs (%) 5,199141 ISR count (execution time <250 µs): 328173 ISR count (execution time 250-500 µs): 0 ... 5% of CPU time is spent on a ISR from one driver: ACPI.sys. While the system is idle. Ergo, this is where the problem is. Also, 300k interrupts during 1min while idle. Code: REPORTED DPCs DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution. Highest DPC routine execution time (µs): 154,694868 Driver with highest DPC routine execution time: Wdf01000.sys Highest reported total DPC routine time (%): 6,835592 Driver with highest DPC total execution time: ACPI.sys Total time spent in DPCs (%) 15,016029 DPC count (execution time <250 µs): 1318446 DPC count (execution time 250-500 µs): 0 ... Again, 6.8% of CPU time spent on DPCs from ACPI.sys Unfortunately, I don't know enough about Windows kernel debugging to go any further. My intuition says some ACPI DSDT code is livelocked. Does anyone know any Windows ACPI "tracers" or debuggers? Maybe I can try getting the issue reproduced under Gentoo..