Quick answer: System interrupts isn’t a program. It’s how Task Manager shows the CPU time spent handling hardware interrupts and the deferred work drivers queue after them. When it stays high, a device driver or a piece of hardware is almost always responsible. Restart first, then unplug USB devices and disable devices like Wi-Fi, Bluetooth and audio one at a time until the number drops, and install that device’s driver from your PC maker. To name the exact driver, record a trace with Windows Performance Recorder or use LatencyMon.
In this guide

What System interrupts is
Hardware such as network cards, USB controllers, disks and sound chips sends the processor an interrupt when it needs attention. Windows pauses what it’s doing, runs the driver’s short interrupt routine, and that routine usually queues the rest of the work as a deferred procedure call (DPC). Microsoft’s performance documentation notes that while a processor is running DPCs and interrupt routines, no normal threads can run on it, which is why heavy interrupt activity makes a PC stutter and can cause audio crackles.
Task Manager groups that time into one row, System interrupts, under Windows processes. Microsoft’s Sysinternals Process Explorer shows the same thing as two “artificial processes”, Interrupts and DPCs, and its help says high CPU use by them can indicate a hardware problem or a device driver bug. Because there’s no real process behind the row, you can’t end it, and you shouldn’t try to remove anything called System interrupts.
How much is too much?
Short spikes are normal, for example when you copy files, start a download or plug in a device. Many guides say anything over 5 or 10% is a problem, but those figures aren’t from Microsoft. The only yardstick Microsoft has published is in an older performance troubleshooting post, which treats interrupt or DPC time above about 20% of the processor as high.
To see the real numbers, open Performance Monitor (perfmon), add counters, and under Processor choose % Interrupt Time and % DPC Time. If either sits well above 20% while the PC is idle, keep going.
Fix it: find the device that’s causing it
Work through these in order and watch Task Manager after each step. Stop when the number drops; the last thing you changed points to the culprit.
- Restart, don’t shut down. With Fast Startup on, shutting down doesn’t fully reset drivers, but a restart does.
- Unplug USB and external devices one at a time: docks, webcams, external drives, game controllers, USB audio interfaces and hubs. Leave the keyboard and mouse until last.
- Disable devices one at a time in Device Manager. Right-click Start, open Device Manager, and start with Network adapters (Wi-Fi, Ethernet, Bluetooth), then Sound, video and game controllers. Right-click a device, choose Disable device, wait a minute, then enable it again. Don’t disable disk controllers, system devices or the keyboard and mouse you’re using.
- Update or reinstall the driver you found. Get it from your PC or motherboard maker’s support page, especially for chipset, network, audio and storage drivers. In Device Manager you can also right-click the device and choose Update driver, or Uninstall device and restart to reinstall it. If the problem began after a driver update, try Roll Back Driver on the device’s Driver tab.
- Turn off audio enhancements if the sound device was the trigger. In Windows 11 go to Settings > System > Sound, select your output device and set Audio enhancements to Off under Advanced settings.
- Turn off Fast Startup if the problem only appears after the PC has been shut down rather than restarted. See how to disable Fast Startup.
- Update the BIOS or UEFI firmware as a last step, using only your PC maker’s instructions and tool. Don’t let the PC lose power during the update.
If disabling a device fixes it and a fresh driver doesn’t, the hardware itself may be failing. Microsoft’s guidance for this kind of DPC and interrupt problem is to upgrade the driver to a fixed version or replace the hardware.
Pinpoint the driver with a trace
Rather than guessing, you can record exactly which driver is using the time. Windows Performance Recorder (WPR) and Windows Performance Analyzer (WPA) are free Microsoft tools: WPR is included in current versions of Windows, and WPA comes with the Windows Performance Toolkit in the Windows Assessment and Deployment Kit (ADK). In Command Prompt as administrator, start a CPU trace, let the high usage happen for 30 to 60 seconds, then stop it:
wpr -start CPU
wpr -stop C:\interrupts.etl
Open the file in WPA and look at the DPC/ISR graph. The Duration by Module, Function view lists the drivers (.sys files) that spent the most time handling interrupts and DPCs. Microsoft recommends that a single DPC run no longer than 100 microseconds and an interrupt routine no longer than 25, so drivers far above that stand out. Search the driver’s file name to see which device it belongs to; for example, network drivers often show up through ndis.sys and USB through USBXHCI.sys.
If that feels heavy, the free LatencyMon tool from Resplendence gives a simpler view. Run it for a few minutes and check its Drivers tab, sorted by highest execution time. It’s third-party, so download it only from the developer’s site.
Very long DPCs can also crash Windows with a blue screen. If that’s happening too, see DPC Watchdog Violation.
Could it be malware?
The real System interrupts row has no file behind it, so it can’t be a virus in itself. Be suspicious of anything else, such as a file called System Interrupts.exe or an entry that offers Open file location. Also be wary if the CPU load vanishes as soon as you open Task Manager and comes back when you close it; some crypto-mining malware does that. In either case, run a full scan with Microsoft Defender, and an offline scan if the full scan finds nothing.
Related guides
- DPC Watchdog Violation on Windows 11 and 10: How to Fix It
- How to disable Fast Startup in Windows 11 and 10
- Desktop Window Manager high memory: why it happens and 5 fixes
- How to open Command Prompt as administrator in Windows 11 and 10
Official sources:
Leave a Reply