BAD_POOL_HEADER 0x00000019 and BAD_POOL_CALLER 0x000000C2 explained

Fix it now

0x00000019 means a pool header is corrupt, and 0x000000C2 means the current thread made a bad pool request. Both carry a parameter 1 subtype that says exactly which kind of mistake was found, and that value is the fastest triage available on either code.

fltmc
driverquery /si /fo table

1. Get parameter 1 from the BugCheck event in the System log or from !analyze -v on the newest dump in %SystemRoot%\Minidump.
2. On 0x00000019, subtype 0x21 means the block was overrun by its consumer and 0x22 means an address was freed that has no tracking entry – both name the caller on the stack. Subtypes 0xD, 0xE, 0xF, 0x23, 0x24 and 0x25 mean a freed block’s header was modified afterwards, which usually means the preceding block was overrun.
3. On 0x000000C2, subtypes 0x06 and 0x07 are double frees, 0x08 and 0x09 are allocating or freeing at an invalid IRQL, and 0x0A is freeing with the wrong pool tag.
4. Check fltmc for filters belonging to products that are no longer installed, and remove them with the vendor’s own removal utility.
5. Update the remaining third-party drivers, then re-run the workload that crashed.

Neither code proves the thread on the stack is guilty. Microsoft says of 0x00000019 that the pool was already corrupt at the time of the request, and that this may or may not be down to the caller.

If the machine is stable with the stack tidied and drivers current, stop here. The next section explains what the subtypes mean and how to find the writer.

Why it happens

Kernel pool allocations are laid out with a small header in front of each block recording its size, its tag and the size of the block before it, and free blocks are threaded onto lists. That metadata is what lets the allocator find and coalesce blocks, and it sits immediately next to data that drivers write to. A driver that writes a few bytes too many does not damage its own allocation – it damages the header of the block after it.

0x00000019 is the allocator noticing. Its parameter 1 subtypes read like a list of ways that can happen: the freelist is corrupt (0x3), adjacent block headers contradict each other (0x5), a header’s recorded previous size is too large (0x6), a header size is corrupt or zero (0x7, 0x8, 0x9, 0xA, 0x20), the data after a block being freed is corrupt because the consumer overran it (0x21), or an address is being freed with no tracking entry at all, because it has already been freed or was never allocated (0x22).

0x000000C2 is the other side of the same coin: rather than the metadata being wrong, the request itself is. Its subtypes cover freeing pool twice, allocating or freeing at an IRQL where that is not allowed, freeing with a tag that does not match the one used to allocate, and freeing addresses that were never allocated. Where 0x19 says the pool is damaged, 0xC2 says the caller on the stack asked for something illegal – which makes it the more directly attributable of the two.

0x00000041 gets grouped with these and should not be treated as a leak. Its published cause is that no driver is permitted to request must-succeed pool at all, and the documented fix is to replace or rewrite the driver making the request rather than to free up memory. Microsoft does allow that a second component may have depleted the pool, and gives !vm 1 and !poolused 2 for finding it – but the first reading is a driver doing something it is not allowed to do.

Full reference

0x00000019 parameter 1 subtypes

0x000000C2 parameter 1 subtypes worth knowing

Finding the writer rather than the reporter

Both codes tend to fire in whichever component next touched the damaged metadata, so the module named in the dump is frequently innocent. Special pool is the tool that removes the delay: every allocation gets its own page with an inaccessible guard page after it, so an overrun faults immediately with the offender on the stack. Microsoft’s documented sequence is to walk the pool links in the debugger to get a candidate tag, then use special pool for that tag, or Driver Verifier’s special pool option against the suspect driver.

Driver Verifier deliberately crashes machines and Microsoft states it should be run only on computers used for testing and debugging. Enable it with verifier /bootmode resetonbootfail so a failed start clears it, and never leave it enabled on a machine in service.

0x00000021, and why it is not a counter to watch

QUOTA_UNDERFLOW means quota charges have been mishandled by returning more quota to a block than was previously charged. Parameter 1 is the process initially charged, parameter 2 the quota type, parameter 3 the amount to return, and parameter 4 the amount that was not returned. It describes an accounting error inside a component, not a system running short of anything, and there is nothing to tune in response to it.

Ruling out the cheap causes first

• Test memory. Failing RAM imitates pool corruption closely, and Windows Memory Diagnostics with the extended test mix costs a night.
• Check fltmc against the list of products you believe are installed.
• Look for two real-time scanners on one machine. It is not a documented cause of these codes, but it is a pattern worth ruling out before an investigation.
• Run sfc /scannow and, if it reports files it could not repair, DISM /Online /Cleanup-Image /RestoreHealth.
• Compare several dumps. A stable subtype with a changing module is a corruption hunt; a stable module with subtype 0xC2 0x06 or 0x0A is a driver defect you can report today.

Every code this article covers

Confirm the fix worked

1. fltmc lists only filters belonging to products that are installed and supported on this Windows build.
2. verifier /querysettings reports no active verification before the machine returns to service.
3. Windows Memory Diagnostics passes an extended run with the result recorded in the System log.
4. The workload that crashed the machine runs to completion twice with no new dump files.
5. If a driver was replaced, the subtype that used to appear no longer does.

Questions people ask about this