DRIVER_CORRUPTED_MMPOOL 0x000000D0 and driver pool corruption bugchecks

Fix it now

0x000000D0 is the system touching invalid memory at an IRQL that was too high, and Microsoft attributes it almost certainly to a driver that has corrupted the system pool. The module named in the dump is usually the one that read the damaged memory, not the one that wrote it, which is why replacing it rarely helps.

verifier /standard /driver suspect1.sys suspect2.sys
verifier /bootmode resetonbootfail
verifier /querysettings

1. Collect several dumps rather than one. Open each from %SystemRoot%\Minidump with !analyze -v and note whether the named module changes between crashes.
2. If it changes, stop treating the named driver as the culprit and go looking for the writer instead.
3. Update every third-party driver from its hardware vendor, and remove security, backup or utility software you no longer use.
4. Enable Driver Verifier’s standard set – which includes special pool – against named third-party drivers on a machine you can afford to crash, then use it until it bug checks.
5. The next dump should name the guilty driver directly. Clear Verifier with verifier /reset, restart, then update or remove that driver.

Rule out memory first. Failing RAM imitates pool corruption closely, and an overnight run of Windows Memory Diagnostics costs nothing.

If the machine is stable with the identified driver replaced, you are finished. The next section explains why the crash lands somewhere other than the fault.

Why it happens

Kernel pool is a shared heap. A driver that asks for memory gets a block from a pool holding allocations belonging to every other component, with no guard page between neighbours – the cost across every allocation on the system would be unacceptable. A driver that writes a few bytes past the end of its buffer therefore writes into whatever happens to sit next to it.

Nothing fails at that moment. The corruption sits there until the owner of the damaged block reads it and acts on the wrong values, which might be a second later or an hour later, under a different workload entirely. When the crash finally arrives, the stack shows the victim. This is why people replace the named driver, see no change, and conclude the machine is haunted.

The size of the corrupted allocation decides which code you get, and this is the single most useful fact in the family. A corrupted allocation of PAGE_SIZE or larger produces 0x000000D0; anything smaller produces 0x000000C5 instead. Both have the same published description – the system accessed invalid memory at a process IRQL that was too high – and the same attribution to a driver that corrupted the system pool. They are one fault with two numbers.

Special pool is the answer to the delay. When Driver Verifier enables it for a driver, each allocation gets its own page with an inaccessible guard page immediately after it, so an overrun faults at the moment it happens with the guilty driver on the stack. 0x000000CC and 0x000000CD are what that looks like when it works: the first is a reference to memory that was freed, the second is an access beyond the end of an allocation – the driver asked for n bytes and more than n were referenced.

Full reference

Which code you get, and what it tells you

Reading a run of crashes rather than one

Special pool, and the alternative when it finds nothing

verifier /standard /driver name.sys enables the standard option set, which includes special pool, against named drivers. If that does not reveal the driver, Microsoft’s documented next step is the Global Flags utility, which can enable special pool by pool tag rather than by driver – useful when the dumps keep naming a tag you can see but cannot attribute.

There is also a blunter diagnostic on the 0xD0 page itself. Creating ProtectNonPagedPool as DWORD 1 under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management makes the system unmap all freed nonpaged pool after a restart, which stops drivers corrupting it. Microsoft’s own caveat is that it does not protect the pool from DMA hardware, so a device writing where it should not still gets through.

Debugger commands that earn their keep here

Driver Verifier with special pool enabled will crash the machine deliberately, repeatedly, and possibly during start-up. Microsoft states it should only be run on computers used for testing and debugging. Take a backup, enable it with verifier /bootmode resetonbootfail, and never leave it on a machine somebody depends on.

When it is memory rather than a driver

• Run Windows Memory Diagnostics – type its name at Start – and read the MemoryDiagnostics-Results entry in the System log afterwards.
• A single clean pass proves very little. Run a full overnight test before ruling memory out.
• With more than one module fitted, test one at a time to isolate a failing stick.
• Check whether the machine has been overclocked or has memory profiles enabled in firmware, and return it to stock while you test.
• If 0x0000012B appears alongside these codes, the memory manager has detected corruption that could only have come from a component accessing memory by physical address, which shifts the weight firmly towards RAM, DMA or firmware.

Every code this article covers

Confirm the fix worked

1. verifier /querysettings reports no active verification before the machine goes back into service.
2. The machine runs its full normal workload for several days with no new dumps.
3. fltmc shows only the filters you intend, all from products their vendors currently support on this Windows build.
4. Windows Memory Diagnostics completes with no errors reported in the System log.
5. If you replaced a driver, Device Manager shows the version you installed rather than the one that crashed.

Questions people ask about this