“System Interrupts” at 10%, 20%, or 30% CPU confuses everyone the first time — you can’t end it, you can’t find its file, and forum advice ranges from useless to dangerous. Here’s the key reframe: it’s not a thing that’s broken, it’s a measurement of brokenness elsewhere. High System Interrupts means some hardware device is screaming for attention thousands of times per second, or a driver is doing far too much work each time it’s asked. Your job is to find the screamer.
The diagnostic tool for this is DPC latency analysis — it names the driver doing the excessive work. For the closely related kernel-process variant see fixing ntoskrnl.exe high CPU and the Windows 10 ntoskrnl guide .
Why this happens
- Faulty or outdated device driver: Doing excessive DPC work per interrupt — the top cause.
- Failing hardware: A dying drive, NIC, or USB device generating interrupt storms.
- USB device misbehaving: A flaky peripheral interrupting thousands of times per second.
- Network driver issues: Wi-Fi/Ethernet drivers with interrupt moderation misconfigured.
- Storage driver problems: AHCI/NVMe driver doing heavy DPC work on every I/O.
- Audio driver DPC latency: Realtek/Conexant audio drivers infamous for DPC spikes.
- BIOS/firmware bugs: Interrupt routing issues fixed by BIOS updates.
How to fix it
Work through these in order — diagnose first, then act.
Fix 1: Measure DPC latency to name the driver
Get the evidence.
- Download LatencyMon (Resplendence, free) and run it — click the green play button and let it monitor for 5–10 minutes of typical use.
- Check the Drivers tab sorted by DPC count and highest execution — the driver with massive DPC counts or execution times is your culprit. Common names:
ndis.sys(network),storport.sys/stornvme.sys(storage),HDAudBus.sys/audio drivers, USB drivers. - Note whether the spikes correlate with activity — LatencyMon’s main tab shows current latency; trigger the high-Interrupts state and watch which driver spikes.
- As a cross-check, open Windows Performance Recorder, capture 60 seconds during the problem, and view DPC/ISR duration by module in Windows Performance Analyzer — same answer, more detail.
- You now have a driver filename — everything below targets it specifically.
Fix 2: Disconnect USB devices one by one
The fastest physical test.
- Unplug every USB device except keyboard/mouse — watch System Interrupts in Task Manager for a full minute after each removal.
- USB audio interfaces, webcams, external drives, docks, and cheap hubs are the classic interrupt storm sources.
- If removing a device drops Interrupts to normal, you’ve found it — update its driver/firmware, try a different port (USB 2.0 ports are more forgiving than 3.x for flaky devices), or replace it.
- For docks: update the dock firmware from the manufacturer — dock USB controllers with old firmware are notorious DPC offenders.
- Reconnect devices one at a time, confirming Interrupts stays low after each — sometimes it’s the combination (bandwidth contention) rather than one device.
Fix 3: Update the identified driver
Target the LatencyMon-named driver.
- Network (
ndis.sys, Wi-Fi/Ethernet driver): update from the laptop vendor’s support page first, then the chip maker (Intel/Realtek) — and in the adapter’s Advanced properties, ensure Interrupt Moderation is Enabled. - Storage (
storport.sys,stornvme.sys): update the chipset driver from the vendor, update SSD firmware with the maker’s tool, and verify the SATA mode matches the install (AHCI vs RAID). - Audio (
HDAudBus.sys, Realtek): update from the vendor support page — or as a test, disable audio enhancements (Sound settings > device Properties > Enhancements > Disable all enhancements) and disable unused audio devices in Device Manager. - GPU drivers: update from Intel , NVIDIA , or AMD — GPU drivers do DPC work too.
- After each driver update, re-run LatencyMon for 5 minutes — confirm the driver’s DPC numbers actually dropped before moving on.
Fix 4: Disable the misbehaving device
When the driver can’t be fixed, sideline the hardware.
- In Device Manager, find the device behind the bad driver (View > Devices by connection helps map drivers to hardware).
- Right-click > Disable device as a test — if System Interrupts normalizes, the device is confirmed as the source.
- Decide: is the device essential? A flaky fingerprint reader or unused SD card reader can stay disabled permanently with zero loss.
- For essential devices (Wi-Fi, storage controller), disabling is diagnostic only — the real fix is a driver version that behaves, a BIOS update, or hardware replacement.
- Check for hidden ghost devices (View > Show hidden devices) — grayed-out remnants of removed hardware can still generate interrupts; uninstall them.
Fix 5: Update BIOS and chipset
Fix the interrupt routing underneath.
- Update the BIOS from the laptop vendor’s support page — interrupt routing and ACPI tables live in firmware, and vendors fix DPC issues in BIOS updates.
- Install the latest chipset driver package — it includes the interrupt controller and bus drivers.
- Reset BIOS to optimized defaults after updating — stale settings from old BIOS versions can misroute interrupts.
- Re-run LatencyMon after the BIOS update — firmware-level DPC fixes show up as across-the-board latency drops.
- If the vendor’s changelog mentions “DPC latency,” “interrupt,” or “stability,” that BIOS was made for exactly your problem.
Fix 6: Check for failing hardware
Interrupt storms are how dying hardware cries for help.
- Run the drive maker’s SMART check plus
chkdsk C: /scan— a drive retrying bad sectors generates enormous interrupt/DPC load. - Test RAM with
mdsched.exe— memory errors cause interrupt-adjacent weirdness and DPC spikes. - If LatencyMon implicates the network driver and updates don’t help, the NIC itself may be failing — test with a USB network adapter as a substitute.
- Check Event Viewer > Windows Logs > System for hardware error events (WHEA, disk errors) timestamped near the high-Interrupts periods.
- Hardware-caused interrupt storms don’t respond to any software fix — once confirmed, it’s a repair-shop matter. Microsoft’s Windows support covers the software diagnostics officially.
Closing
System Interrupts high CPU is a symptom with a hardware accent: some device interrupting too much, some driver working too hard per interrupt. LatencyMon names the driver in ten minutes; USB isolation, driver updates, and BIOS fixes resolve the large majority of cases. Stop trying to “end” the pseudo-process — find the screamer, and the interrupts go quiet on their own.
Frequently asked questions
What are System Interrupts in Task Manager?
System Interrupts isn’t a real process — it’s Task Manager’s label for CPU time spent handling hardware interrupts and Deferred Procedure Calls (DPCs). When hardware needs attention (a packet arrives, a disk read completes), it interrupts the CPU; the driver then does follow-up work as a DPC. High ‘System Interrupts’ CPU means some hardware device is interrupting excessively or its driver is doing too much work per interrupt.
Is System Interrupts a virus?
No. It’s a pseudo-process representing kernel interrupt handling — there’s no executable to infect. Malware can’t ‘be’ System Interrupts, though malware’s activity (heavy disk/network I/O) can increase interrupt load indirectly. If someone tells you to delete a System Interrupts file, they’re describing something that doesn’t exist.
Can I end System Interrupts in Task Manager?
No — there’s nothing to end. The End Task option is disabled for it because it’s not a process. The fix is finding which hardware device or driver is generating the interrupt storm and addressing that: updating, disabling, or replacing the device or its driver.
What level of System Interrupts CPU is normal?
Under 1–2% at idle, with brief spikes during heavy I/O (large file copies, gigabit network transfers). Sustained usage above 5–10% at idle indicates a problem — usually a misbehaving driver. Spikes that correlate with specific activity (plugging in USB, Wi-Fi scanning) point directly at the involved device.
