What's new

The "30% CPU at idle because of System + Interrupts" issue

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.




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..
 
Last edited:
I can't help you with debugging, but I CAN tell you, if you have the 30% at idle issue, playing audio will cause the issue to vanish until you stop the audio. I gave up, bought a 128 GB Flash drive, and threw my Sd card in the DS.
 
What's strange is that I don't remember previously having the problem with "System" process consuming CPU while idle.

But I finally inserted a micro SD card (the new 128GB) for the first time in my current SP2. And since then, I started noticing the "System" process spike happening from time to time. The kicker is that it's still happening even though I no longer have a card in there!
 
What's strange is that I don't remember previously having the problem with "System" process consuming CPU while idle.

But I finally inserted a micro SD card (the new 128GB) for the first time in my current SP2. And since then, I started noticing the "System" process spike happening from time to time. The kicker is that it's still happening even though I no longer have a card in there!

If you remove the microSD card and restart, does it happen again? I think the moment you put in the card, even if it's ejected after, the system jams somewhere (probably a driver)
 
I can't help you with debugging, but I CAN tell you, if you have the 30% at idle issue, playing audio will cause the issue to vanish until you stop the audio.
Oh, I will test this the next time I notice the issue. I am not sure why it would be related to audio so maybe if I can reproduce that would give me a hint.

On the other hand,
beq said:
But I finally inserted a micro SD card (the new 128GB) for the first time in my current SP2. And since then, I started noticing the "System" process spike happening from time to time. The kicker is that it's still happening even though I no longer have a card in there!
I am going to elaborate. Basically, this issue cannot be related to the hardware SD card reader. The SD card reader is just a USB3 card reader nothing more. It doesn't have any specific mention on the ACPI firmware.
Whatever may be caused by the internal card reader would also be caused by ANY other USB3 mass storage device connected such as a USB HDD, pen drive, or another card reader. They're NO different at all from a hardware, logical, or OS point of view.

From a software point of view, the internal card reader uses a different driver.. but since the protocol is standard Mass Storage, I bet all this driver does is to set the SD(HC/XC) card icon. If you were to suspect it, you could remove it without any major side effects.

Also, I wouldn't be saying this if it weren't for the fact that I have reproduced the issue many times without any SD card whatsoever.
 
Last edited:
Just a 'me too' post. I see this issue and it doesn't seem to be related to audio playing (i.e., I'm experiencing it right now and there is not audio playing)
 
Ok, today I was bitten again by The Issue, and I found the following:
- After starting up, during the first few seconds after I could get into desktop an the task manager, the system was idling at 0-2%. A few seconds afterwards the problem manifested, getting 8% CPU usage in Interrupts. That was, however, before the "delayed startup" Windows items started appearing, which happened nearly a minute afterwards.
I can't help you with debugging, but I CAN tell you, if you have the 30% at idle issue, playing audio will cause the issue to vanish until you stop the audio. I gave up, bought a 128 GB Flash drive, and threw my Sd card in the DS.


- I could reproduce the above. With the CPU at 25%, I opened wmplayer, started playing a song and watched CPU usage drop to 2% for the entirety of the song. After the song ended, it started idling at 0%. It was only after I closed wmplayer that the CPU went back to 25%. I could do this as many times as I wanted.

So it may be related to sound, but dunno how. Anyone else seen the above?
 
On mine, it seems unrelated to mSD... I thought it was, but I get the problem even when a mSD card hasn't been inserted for days after several reboots and shutdowns. So, I now keep my 64GB card inserted and get the problem about the same as without a card.

Also, mine doesn't seem audio related, but I will try the above test next time I see it.

Only other thing I would add, mine doesn't always do it directly after a boot. Sometimes it will be hours later of office usage and will then start and continue until I sleep or reboot. Other times it happens immediately at bootup.

I have noticed this much less frequently the past month. I keep task manager open all the time on the desktop and see this 20-30% usage only about 1/3 of the time I used to before March updates. This is with my 64gb card inserted all the time and accessed daily.
 
On mine, it seems unrelated to mSD... I thought it was, but I get the problem even when a mSD card hasn't been inserted for days after several reboots and shutdowns. So, I now keep my 64GB card inserted and get the problem about the same as without a card.

Also, mine doesn't seem audio related, but I will try the above test next time I see it.
I concur. I've reproduced it several times with no SD card whatsoever, and as mentioned, there's even a logical reasoning for why it can't actually be SD card related.

As for audio, have you tried what I mentioned on the above post? Make a mental note for the next time it happens to you ;)

"Delay after boot" seems interesting.
 
I'm gonna throw this out there JUUST to put it out there. I don't know who manufactures the SD card reader on the SP2, but I don't THINK it's Realtek. That said, I know that Realtek DOES make SD cards, and I have a sneaking suspicion that they may have some kind of unified driver architecture going on that's causing a conflict with the ACTUAL driver for the SD card. That's the best I can do on this one.
 
I'm gonna throw this out there JUUST to put it out there. I don't know who manufactures the SD card reader on the SP2, but I don't THINK it's Realtek. That said, I know that Realtek DOES make SD cards, and I have a sneaking suspicion that they may have some kind of unified driver architecture going on that's causing a conflict with the ACTUAL driver for the SD card. That's the best I can do on this one.
I disagree. The manufacturer is clearly specified as Realtek Semiconductor Corp. in the USB device descriptors, which are independent from whatever driver is loaded.

Also, if you suspect Realtek's driver, I reiterate that (IMO) all it does is just put the SD card icon on Explorer, because the card reader speaks a standard protocol that Linux (for example) has no problems talking with.

So basically you could just uninstall the driver if you want, and you'd find your SD card still working.

To uninstall the driver (which doesn't seem to appear in Programs & Features) just go to Device Manager, find "Realtek USB 3.0 Card Reader", hit "Remove device". When asked about whether to uninstall the driver say "yes". Reboot. The device should now be redetected as a "USB Mass Storage device".
Alternatively: On the "Realtek USB 3.0 Card Reader" properties page, Hit "Update driver...", click on the "Select from a list" option, and choose USB Mass Storage when prompted. This may be more convenient as it doesn't remove the driver files from disk.

But I personally haven't tried the above because, as said, I don't see how it could even be related to the SD card reader. To dispel any doubt, I even have reproduced The Issue multiple times without any card in the slot.
 
Last edited:
Back
Top