High CPU usage caused by System Interrupts and System

[vladm1994]

Hello,

I have read couple of threads about this System Interrupts thing and none of them really helped me. I think you can check the specs somewhere, I am not sure since I am new to the forum.

Basically when I start my laptop everything is good for a while when suddenly the CPU usage goes high because of System Interrupts (~25%) and System (~12%). I have tried using LatencyMon to track down the problem and it used to give me alerting messages but now it gives me messages that are all green and nice ("Your system appears to be handling(...)").

Can you guys help me figure out this thing please? Thanks in advance.

NOTE: My drivers ARE up-to-date, but I am not sure my BIOS is. I don't really know how to update the BIOS though, it's a really weird model I have here, that has become obsolete.

*update1* Upon thinking that it might be the wireless driver or the network driver I disabled both, but it didn't drop the CPU usage
*update2*Now I get disconnected from the internet randomly... it may be the wi-fi driver after all

 

[vladm1994]

oh there we go

CONCLUSION
_________________________________________________________________________________________________________
Your system appears to be having trouble handling real-time audio and other tasks. You are likely to experience buffer underruns appearing as drop outs, clicks or pops. One or more DPC routines that belong to a driver running in your system appear to be executing for too long. At least one detected problem appears to be network related. In case you are using a WLAN adapter, try disabling it to get better results. One problem may be related to power management, disable CPU throttling settings in Control Panel and BIOS setup. Check for BIOS updates.
LatencyMon has been analyzing your system for 0:21:10 (h:mm:ss) on all processors.


_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name: VLAD-PC
OS version: Windows 8 , 6.2, build: 9200 (x64)
Hardware: K53SC, ASUSTeK Computer Inc.
CPU: GenuineIntel Intel(R) Pentium(R) CPU B950 @ 2.10GHz
Logical processors: 2
Processor groups: 1
RAM: 8102 MB total


_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed: 2095,0 MHz
Measured CPU speed: 1363,0 MHz (approx.)

Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.


_________________________________________________________________________________________________________
MEASURED INTERRUPT TO USER PROCESS LATENCIES
_________________________________________________________________________________________________________
The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.

Highest measured interrupt to process latency (µs): 13158,486354
Average measured interrupt to process latency (µs): 9,494310

Highest measured interrupt to DPC latency (µs): 657,826572
Average measured interrupt to DPC latency (µs): 4,285202


_________________________________________________________________________________________________________
MEASURED SMI, IPI AND CPU STALLS
_________________________________________________________________________________________________________
The SMI, IPI and CPU stalls value represents the highest measured interval that a CPU did not respond while having its maskable interrupts disabled.

Highest measured SMI or CPU stall (µs) 0,977454


_________________________________________________________________________________________________________
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): 185,939857
Driver with highest ISR routine execution time: storport.sys - Microsoft Storage Port Driver, Microsoft Corporation

Highest reported total ISR routine time (%): 7,455186
Driver with highest ISR total time: ACPI.sys - ACPI Driver for NT, Microsoft Corporation

Total time spent in ISRs (%) 7,550983

ISR count (execution time <250 µs): 20626921
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-999 µs): 0
ISR count (execution time 1000-1999 µs): 0
ISR count (execution time 2000-3999 µs): 0
ISR count (execution time >=4000 µs): 0


_________________________________________________________________________________________________________
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): 1783,641050
Driver with highest DPC routine execution time: ndis.sys - Network Driver Interface Specification (NDIS), Microsoft Corporation

Highest reported total DPC routine time (%): 21,470926
Driver with highest DPC total execution time: ACPI.sys - ACPI Driver for NT, Microsoft Corporation

Total time spent in DPCs (%) 29,879470

DPC count (execution time <250 µs): 66036724
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-999 µs): 2602
DPC count (execution time 1000-1999 µs): 1
DPC count (execution time 2000-3999 µs): 0
DPC count (execution time >=4000 µs): 0


_________________________________________________________________________________________________________
REPORTED HARD PAGEFAULTS
_________________________________________________________________________________________________________
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.

NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.

Process with highest pagefault count: settingsynchost.exe

Total number of hard pagefaults 1985
Hard pagefault count of hardest hit process: 946
Highest hard pagefault resolution time (µs): 2496852,446301
Total time spent in hard pagefaults (%): 18,500866
Number of processes hit: 21


_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s): 789,580596
CPU 0 ISR highest execution time (µs): 185,939857
CPU 0 ISR total execution time (s): 191,799798
CPU 0 ISR count: 20626921
CPU 0 DPC highest execution time (µs): 1783,641050
CPU 0 DPC total execution time (s): 694,778440
CPU 0 DPC count: 58958519
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s): 80,089793
CPU 1 ISR highest execution time (µs): 0,0
CPU 1 ISR total execution time (s): 0,0
CPU 1 ISR count: 0
CPU 1 DPC highest execution time (µs): 627,579952
CPU 1 DPC total execution time (s): 64,179229
CPU 1 DPC count: 7080808
_________________________________________________________________________________________________________

 

[Larf]

I have the same problem on my HP laptop i just updated today for the 10 March 15 update, i think its my usb port cuz if i replug it goes away but comes back after a while ..... HELP !!!

 

[saumguy]

Got the same problem here since the updates of March 12th : when I start the computer, it runs fine, but after about 15 min, it starts to lag a lot since the system interrupt usage spikes a lot when I move the mouse (about 40-50%), but if I unplug, it the system interrupt usage goes back to normal for about 15 min again.

It's a USB mouse, so I suspected it's either because of the mouse drivers or the USB ports, but I've tried all the USB ports on the laptop and the same problem comes up. I've also tried 2 other USB mouses and it's no better, so I'm pretty much fresh out of options.

I've also tried to update all the drivers of the mouse and the USB ports, but everything is up to date.

And ideas?

 

[Hybrid Vigor]

This can be tricky. I had these high interrupts on USB ports, too. But it turned out to be a faulty graphics driver causing the system interrupts to go havoc. It can be caused by pretty much everything you don't expect. Programs like process explorer can help to figure out what process forces this behaviour. They are kinda painful to use, but I don't know any other way to figure things out. Screwing all possible screws doesn't help either, specific troubleshooting goes the longer way.

 

[Hybrid Vigor]

I don't really know how to update the BIOS though, it's a really weird model I have here, that has become obsolete.

Go here https://www.asus.com/support/Download/3/295/0/7/3mxEvf3TFaWwIvxq/36/ and either download and install the Windows flash utility, this is the most comfortable but not the most recommended way to flash the Bios. It's a no-brainer.

The recommended way is to download the Bios file, put it on a USB stick. Go into the BIOS and search for "update" or something. It will flash the Bios from the file on the stick.

 

[saumguy]

Thanks, but it seems it came from Windows Defender : there was a new update and now everything is back to normal.

Really seems like it's the previous update that made a mess...