Fix ERROR_DRIVERS_LEAKING_LOCKED_PAGES (0x2D9)

Windows flags a driver that's hogging locked I/O pages, slowing your system. Usually a buggy NIC, storage, or GPU driver. Update or rollback drivers, or check for memory leaks.

You're gaming or running a heavy workload on Windows 10 or 11, and suddenly the screen freezes for a second, then you get a BSOD with ERROR_DRIVERS_LEAKING_LOCKED_PAGES and the code 0x000002D9. Or maybe you don't get a crash—you open Task Manager and see the nonpaged pool is sitting at 2 GB, and your RAM is pinned. This isn't a random failure. It's the kernel telling you that a device driver locked memory pages for I/O operations and never released them.

What's actually happening here is a memory leak in kernel mode. When a driver does DMA (Direct Memory Access) to a device—say, a network card moving packets or a storage controller writing to disk—it locks the physical pages so they won't be paged out. That's normal. What's not normal is when the driver forgets to unlock them after the I/O completes. Every leak eats a bit of your nonpaged pool, and the pool has a hard ceiling. Once it's exhausted, the system throws this exact bugcheck.

The leak doesn't just appear out of nowhere. It's usually triggered by a specific condition: resuming from sleep, repeated connect/disconnect of a USB device, or a high packet rate on a flaky NIC. A buggy driver that mishandles error paths will leak a few pages every time that condition trips. Over hours or days, it accumulates.

Find the Culprit Driver

Before you start uninstalling things, you need to know which driver is leaking. Windows gives you a few ways to track this down.

1. Check the Live Kernel Report

Run this in an elevated Command Prompt:

verifier /query

If Driver Verifier is already running, it'll list the drivers and their status. But if you haven't set it up yet, this won't tell you much. The better starting point is the bugcheck data itself.

When the crash happens, Windows writes a minidump to C:\Windows\Minidump. Use WinDbg (from the Microsoft Store) to open the most recent .dmp file and run:

!analyze -v

That command often points directly to the leaking driver's name. On a fresh dump, it'll say something like Probably caused by : ndis.sys or dxgkrnl.sys. Those are generic, but they tell you the subsystem—network or graphics.

The Fix: Update or Roll Back the Driver

Once you've got a likely suspect, the fix is almost always a driver update or rollback. Here's the order I'd do things in.

Update the driver through Windows Update. Go to Settings > Windows Update > Advanced options > Optional updates. Look for driver updates. Install any that match your NIC, storage controller, or GPU. Reboot.
Download the driver directly from the hardware vendor. Don't trust Windows Update to have the latest. If it's a Realtek NIC, go to Realtek's site (or your motherboard vendor's page). If it's an NVIDIA GPU, get the driver from NVIDIA. Install it as an upgrade or clean install.
If the problem started after a recent driver update, roll back. Open Device Manager, right-click the device, go to Properties > Driver > Roll Back Driver. This is your move if the leak showed up right after you updated something.
Disable the device temporarily. If you have another NIC in the machine (like a USB Wi-Fi adapter), disable the onboard one in Device Manager and see if the leak stops. That's a solid test before you commit to a driver change.

For storage-related leaks, check if your NVMe or SATA controller has a firmware update. Storage controllers are a common source because their drivers interact with the storage stack in complex ways, especially with power management.

If You Can't Identify the Driver

Sometimes the minidump doesn't give a clear answer. In that case, use Driver Verifier to force the system to catch the leak. Here's how:

Open an elevated Command Prompt.
Run verifier /standard /all. This enables standard verification on all drivers. It will slow your system a bit, and it might cause a BSOD sooner—that's the point. The crash will name the guilty driver.
Reboot and reproduce your workload. When it crashes, open the new minidump in WinDbg and look at the argument for DRIVER_LEFT_LOCKED_PAGES_IN_PROCESS or similar. The dump should list the driver.
Once you have the name, disable or update that driver. Then run verifier /reset to turn off verification.

Running Verifier on all drivers is heavy-handed. If you have a hunch it's a specific vendor (say, your Wi-Fi card), use verifier /standard /driver rt640x64.sys instead. That limits the impact.

What If It Still Fails?

If you've updated or rolled back drivers and the leak persists, check the following:

BIOS/UEFI firmware. Motherboard vendors ship updates that fix the way the BIOS exposes DMA remapping. An outdated BIOS can cause weird interactions with storage and network drivers. Check your board's support page.
Memory integrity (VBS) settings. On Windows 11, if you have Memory Integrity enabled in Windows Security, try turning it off temporarily. It changes the memory pool behavior and can expose driver bugs. Don't leave it off forever—it's a security feature—but it's a diagnostic step.
Third-party antivirus or security software. These install kernel drivers that can leak pages. Uninstall (not disable) the software and see if the problem goes away. Reinstall if it does.

The core issue is always a driver that doesn't clean up after itself. There's no user-mode fix for that. The only real solution is to get a driver version that doesn't leak. And if the vendor hasn't fixed it, your only options are to disable the hardware or switch to a different device.

One last thing: don't waste time with memory cleaners or registry tweaks. They don't touch the nonpaged pool. This is a driver problem, and it needs a driver-level fix.