BAD_POOL_HEADER Blue Screen 0x19: 17 Parameter 1 Values Explained

BAD_POOL_HEADER is Windows stop code 0x00000019 (0x19). Microsoft's reference says it indicates "that a pool header is corrupt." The pool is the memory Windows uses for its own data. Each block of it begins with a small header, and when the header is damaged the system stops.

Microsoft is candid about the difficulty. Its Cause section says "the pool is already corrupted at the time of the current request. This may or may not be due to the caller." The page then spends most of its length on a table that decodes the first parameter.

This page is built from the Microsoft Learn article "Bug Check 0x19: BAD_POOL_HEADER" and, where noted, Microsoft's general page on analysing blue screen data, both read on 13 October 2026 and checked against the Microsoft Docs source files. Microsoft marks the 0x19 page as written for programmers and directs customers to https://www.windows.com/stopcode. Anything taken from the general page rather than the 0x19 page is labelled as such.

What does parameter 1 tell you?

Parameter 1 indicates the type of violation, and the meaning of the other parameters depends on it. The values in Microsoft's table:

Parameter 1	Cause of error, as Microsoft words it
0x2	The special pool pattern check failed; the owner has likely corrupted the pool block
0x3	The pool freelist is corrupt; in a healthy list, parameters 2, 3 and 4 should be identical
0x5	A pair of adjacent pool entries have headers that contradict each other; at least one of them is corrupt
0x6	The pool block header's previous size is too large
0x7	The pool block header size is corrupt
0x8	The pool block header size is zero
0x9	The pool block header size is corrupted (it is too large)
0xA	The pool block header size is corrupt
0x20	The pool block header size is corrupt (the pool entry that should have been found, and the next pool entry)
0x21	The data following the pool block being freed is corrupt; typically the consumer has overrun the block
0x22	An address being freed does not have a tracking entry, usually because the call stack is freeing a pointer already freed or never allocated
0xD, 0xE, 0xF, 0x23, 0x24, 0x25	The pool header of a freed block has been modified after it was freed; usually due to the block preceding the freed block being overrun

That is the whole table: 12 rows covering 17 values. Notice how many entries are about a header size being wrong. A header that says a block is too large, zero, or inconsistent with its neighbour is the usual signature of something having written past the end of a nearby block.

Is the driver that appears on the screen the culprit?

Not necessarily, and Microsoft says why. Its Resolution section notes that the !analyze extension "may be of help in pinpointing the suspect driver, but this is frequently not the case with pool corrupters." The damage is done by one piece of code and noticed later by another, so the code running when the system stops is often only the witness.

The 0xD to 0x25 row of the table makes the same point from the other side: the header of a freed block was modified after it was freed, and Microsoft says this is "not typically the fault of the prior owner of the freed block" but "usually (but not always) due to the block preceding the freed block being overrun."

Which tools does Microsoft name?

For developers, the page recommends walking the internal pool links in the kernel debugger, then using special pool for the suspect pool tags or the Driver Verifier Special Pool option on the suspect driver.

For everyone else it describes two built-in tools in short sections.

Driver Verifier. A tool that runs in real time to examine the behaviour of drivers. If it sees errors in the execution of driver code, it proactively creates an exception so that part of the code can be scrutinised. You start it by typing Verifier at a command prompt and can choose which drivers to verify. Verification adds overhead, so Microsoft says to verify as few drivers as possible.

Windows Memory Diagnostics. If this bug check appears inconsistently, Microsoft says it could be related to faulty physical memory. In the control panel search box, type Memory and select "Diagnose your computer's memory problems." After the test, use Event Viewer to read the result in the System log, under the entry named MemoryDiagnostics-Results.

What does "inconsistently" tell you?

The Memory Diagnostics advice is attached to a condition: the bug check appearing inconsistently. If the same code crashes the same way each time, a driver bug is the more natural suspect; if the failures are random, Microsoft points toward physical memory. The page does not give a rule for telling the two apart beyond that sentence, and this page does not invent one.

What Microsoft tells non-programmers to do

The 0x19 page does not contain a numbered list for customers. What it gives, in the order it appears, is:

• Use the steps in Microsoft's Analyze Bug Check Blue Screen Data page to gather the four parameters (the System Log in Event Viewer lists them).
• Use parameter 1 to work out the type of corruption.
• Run Driver Verifier on as few drivers as possible, with the Special Pool option on a suspect driver.
• If the bug check is intermittent, run Windows Memory Diagnostics and read the result in the System log.

This page presents these as the tools Microsoft names; it does not claim they will find a corrupter, and Microsoft itself says pool corrupters are hard to pinpoint.

Checklist before changing anything

• The four parameters from the System Log, especially parameter 1
• Whether the crash is consistent or intermittent
• Result of Windows Memory Diagnostics (MemoryDiagnostics-Results in the System log)
• Which drivers, if any, Driver Verifier flagged
• Drivers installed or updated just before the first crash

How to work through a 0x19 blue screen

• Copy the four parameters from the System Log
• Decide whether the crash is consistent or intermittent
• If intermittent, run Windows Memory Diagnostics and read the result
• If consistent, use Driver Verifier on as few drivers as possible

Registry edits and paid tools. Microsoft's page does not mention them, so neither does this one.

What does Microsoft say to collect first?

Before any of the pool work, the Resolution section points back to Microsoft's general page, "Analyze Bug Check Blue Screen Data", to gather the stop code parameters, and says to use those parameters to determine the specific type of code behaviour you are trying to track down. In other words the parameter 1 value is the branch point, and it is read before a tool is chosen.

Every stop code covered here is listed in our Windows blue screen stop code index.

Sources and how to check

• Microsoft Learn, "Bug Check 0x19: BAD_POOL_HEADER" — https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x19--bad-pool-header. Source file in the MicrosoftDocs/windows-driver-docs repository.
• Microsoft Learn, "Analyze bug check (stop code error) data" — https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/blue-screen-data (general guide).
• Bug check code reference, Microsoft Learn: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-code-reference2
• Troubleshoot blue screen errors (for regular users): https://www.windows.com/stopcode
• Licence and credit: Microsoft Learn documentation is published under CC BY 4.0. This page selects, rewords and reorders it, adds a plain-language reading, and is not endorsed by Microsoft. The original is linked above.
• Checked as of 13 October 2026.