If you've already run LatencyMon and it's pointing the finger at either nvlddmkm.sys or ACPI.sys, generic driver update advice isn't going to cut it. These two are some of the most common repeat offenders in DPC latency reports, and they each spike for completely different, specific reasons. Let's get into what's actually happening under the hood and how to fix each one properly.
First, How ISR and DPC Execution Actually Works
To fix this correctly, you need to understand the handoff happening at the hardware level, because it explains why these specific spikes cause the symptoms they do.
When a piece of hardware, say your GPU or your audio interface, needs the CPU's attention, it fires a hardware interrupt. The CPU immediately jumps to an Interrupt Service Routine, or ISR, tied to that device. ISRs are designed to be extremely short. Their entire job is to acknowledge the interrupt and queue up the actual work as a Deferred Procedure Call, or DPC, which then runs slightly afterward at a lower priority level.
This two-stage system exists so that urgent hardware signals get acknowledged instantly without blocking the rest of the system while the heavier processing happens. Under normal conditions, this entire ISR to DPC handoff completes in a handful of microseconds and you never notice it.
The problem starts when a driver's DPC routine takes too long to execute. As a rough working threshold, once a driver's DPC execution time climbs past roughly 1000 microseconds, real-time audio and frame buffers start starving, because the system is too busy servicing that one delayed DPC to refill the buffer on schedule. For audio, that shows up as pops or crackling. For gaming, it shows up specifically as 1% low frame drops, meaning your average frame rate can look completely fine while your worst-case frame times spike, which is exactly the kind of stutter that feels way worse than the average FPS number suggests.
This is why two completely different symptoms, audio crackling and frame stutter, can trace back to the exact same root cause. It's not two separate problems, it's the same DPC delay affecting two different real-time buffers.
The nvlddmkm.sys Power State Transition Bug
nvlddmkm.sys is NVIDIA's core kernel-mode display driver, and it's one of the most frequently flagged drivers in DPC latency reports on both desktops and laptops with NVIDIA GPUs.
Why it happens
Modern NVIDIA GPUs aggressively manage power through a system of performance states, commonly called P-states. At idle on your desktop, the GPU can drop clocks all the way down, sometimes to a low idle clock in the low hundreds of megahertz range, to save power and reduce heat. The moment you open a browser tab with video, launch a game, or trigger any GPU-accelerated task, the driver needs to ramp the clock back up quickly.
That ramp is where the bug shows up. During the transition between P-states, the driver can briefly hang while renegotiating clocks and voltage, and that hang shows up as a DPC execution spike attributed directly to nvlddmkm.sys. It's especially noticeable on systems where the GPU is constantly bouncing between idle and active states, like during everyday desktop use with occasional video playback, rather than systems under sustained heavy load where the GPU just stays pinned at a high clock the whole time.
The fix
Open NVIDIA Control Panel and go to Manage 3D Settings. Set Power Management Mode to Prefer Maximum Performance rather than the default Optimal Power setting. This keeps the GPU parked at a higher performance state more consistently, which reduces how often it needs to renegotiate P-states in the first place, cutting down on the transition spikes.
Separately, some users also report improvement from setting Low Latency Mode to Ultra in the same 3D settings panel. Worth being precise about what this setting actually does though, it's primarily designed to reduce the pre-rendered frame queue for input latency in games, not to directly stabilize GPU clocks. It's worth testing alongside the Power Management Mode change, but don't treat it as a guaranteed fix for the P-state issue specifically, treat it as a secondary setting worth experimenting with.
If you're on a laptop with hybrid graphics (NVIDIA GPU plus integrated graphics), also check that your global profile isn't forcing unnecessary GPU switching for background applications, since every switch is another opportunity for a P-state transition spike.
The ACPI.sys Polling Loop
ACPI.sys handles power management, thermal monitoring, and various hardware event signaling at the system level. When this one shows up as your top DPC offender, the cause is usually different from the nvlddmkm.sys issue.
Why it happens
Two common root causes show up repeatedly here. The first is PCIe Active State Power Management, commonly called ASPM, which allows PCIe devices to drop into low power link states when idle. The transition in and out of these low power states can trigger ACPI-related DPC delays, especially on systems with multiple PCIe devices (GPU, NVMe drives, WiFi cards) all managing their link states somewhat independently.
The second common cause is buggy sensor polling, particularly battery and thermal sensors on laptops. Some manufacturer firmware implementations poll these sensors more aggressively or less efficiently than they should, and that polling loop shows up as sustained ACPI.sys DPC activity rather than a sharp spike.
The fix for PCIe ASPM
This setting is hidden by default in Windows 11's power plan advanced settings, so you need to unhide it first. Open an elevated Command Prompt or PowerShell window and run:
powercfg -attributes SUB_PCIEXPRESS ASPM -ATTRIB_HIDENow open Power Options, click Change plan settings on your active power plan, then Change advanced power settings. You'll find a new PCI Express category with a Link State Power Management setting. Set this to Off. This stops PCIe devices from dropping into and out of low power link states, which removes the transition trigger entirely.
Be aware this will slightly increase idle power draw, particularly noticeable on laptops running on battery. It's a real tradeoff, not a free fix, so if you're primarily troubleshooting this on a laptop, weigh whether the latency improvement is worth the battery impact for your specific use case.
The fix for sensor polling issues
This one is more hardware and firmware specific, so there's no single universal fix. Start by checking for a BIOS or firmware update from your motherboard or laptop manufacturer, since ACPI polling bugs are sometimes patched at the firmware level rather than something Windows itself can fix. If you're on a laptop, also check your manufacturer's power or system management utility for a setting related to sensor polling frequency or "quiet" thermal modes, some vendors expose this directly in their own software even when it's not accessible through Windows.
MSI Mode vs Line Based Interrupts
This is a deeper fix that applies to both nvlddmkm.sys and other DPC offenders, and it's rarely mentioned in mainstream troubleshooting guides because it requires understanding a layer most users never touch.
What this actually means
Traditionally, hardware devices signaled interrupts using shared physical IRQ lines, meaning multiple devices could be waiting on the same line and the system had to figure out which device actually triggered the interrupt. This adds overhead and can cause contention when multiple devices share a line.
Message Signaled Interrupts, or MSI, replace this with a more direct method where each device sends its interrupt as a small message directly, without sharing a physical line with other devices. Most modern hardware supports MSI mode, but Windows doesn't always default every device to use it, some still fall back to legacy line based interrupts.
How to check and fix it
A small utility commonly referred to as the MSI Utility, available from various driver and overclocking community resources, lets you inspect which devices on your system are currently using MSI mode versus legacy line based interrupts. Run it, and check specifically for your GPU and your audio controller, since these are the two device types most likely to benefit from forcing MSI mode when they're currently on legacy interrupts.
If a device is shown using line based interrupts, the utility allows you to switch it to MSI mode directly, which writes the appropriate value to that device's Interrupt Management settings in the registry. After switching, restart your system for the change to take effect, then re-run LatencyMon under the same conditions that originally triggered your spikes to confirm whether the change actually helped.
A word of caution here, this is a lower level change than a driver rollback or a power setting toggle. Change one device at a time, and confirm your system remains stable after each change before moving to the next device, rather than switching everything at once.
Putting It Together: A Sensible Fix Order
Given both drivers can be involved simultaneously, work through fixes in this order rather than changing everything at once:
- Confirm which driver LatencyMon is actually flagging as the primary offender, and by how much, before touching anything
- If nvlddmkm.sys is flagged, start with the Power Management Mode change, it's the lowest risk, most reversible fix
- If ACPI.sys is flagged, try the PCIe ASPM fix next, keeping the laptop battery tradeoff in mind
- Only move to MSI mode switching if the above fixes don't fully resolve your specific spikes, since it's the most technical and least reversible-feeling change of the group
- Re-run LatencyMon after every single change, not just at the end, so you know exactly which fix actually moved the needle
This guide explains the underlying mechanisms behind these two specific DPC culprits, which stay accurate across Windows 11 versions. Exact registry paths and utility versions can shift over minor Windows updates, always confirm compatibility with your current build before making system level changes.
