Windows Stop Code BAD_POOL_HEADER (0x00000019): Meaning, Parameters, and Troubleshooting
Quick Answer BAD_POOL_HEADER is Windows bug check 0x00000019. It means Windows detected a corrupt pool header in kernel memory. Parameter 1 identifies the ty...
Quick Answer
BAD_POOL_HEADER is Windows bug check 0x00000019. It means Windows detected a corrupt pool header in kernel memory. Parameter 1 identifies the type of corruption; the meanings of Parameters 2–4 change according to Parameter 1. Microsoft Learn
The crash may occur after the damaging write or invalid free. Microsoft warns that the pool is already corrupt when the current request detects it, and the code on the crash stack may or may not be responsible. Start with the dump and its parameters, then investigate the relevant pool block, driver, and allocation history. Microsoft Learn
What Is a Pool Header?
Windows uses kernel memory pools to satisfy allocations needed by the operating system and drivers. Information associated with an allocated block helps Windows manage that memory. A pool header is part of that bookkeeping.
If a driver writes beyond its allocation, uses an invalid pointer, frees a block incorrectly, or modifies memory after it has been freed, pool bookkeeping can become inconsistent. Those are possible mechanisms; the specific one in an individual crash depends on Parameter 1 and the dump evidence. Inconsistent crashes can also warrant a physical memory check. Microsoft Learn
Why the Driver on the Stack May Be Innocent
Suppose one driver corrupts a pool block and a different driver later requests or frees memory. Windows may detect the corrupt header during the later operation. The resulting stack identifies where corruption was found, which is not necessarily where it was introduced.
Microsoft explicitly states that the pool is already corrupt at the time of the current request and that the current caller may or may not be responsible. This is why a one-line “probably caused by” result should be tested against the pool evidence before blaming a driver. Microsoft Learn
BAD_POOL_HEADER Parameter 1 Values
Record all four arguments from the dump. Use Arg1 to choose the correct interpretation:
| Arg1 | What Microsoft says was detected | Main diagnostic lead |
|---|---|---|
0x2 |
A Special Pool pattern check failed. | The owner likely corrupted the pool block. |
0x3 |
The pool free list is corrupt. | In a healthy list, Arg2, Arg3, and Arg4 should match. |
0x5 |
Headers of two adjacent pool entries contradict each other. | At least one adjacent header is corrupt. |
0x6 |
A header’s previous size is too large. | Inspect the bad entry identified by Arg4. |
0x7 |
A pool block’s header size is corrupt. | Arg4 identifies the bad pool entry. |
0x8 |
A pool block’s header size is zero. | Arg4 identifies the bad pool entry. |
0x9 |
A pool block’s header size is too large. | Inspect the bad entry identified by Arg4. |
0xA |
A pool block’s header size is corrupt. | Arg4 is the page address that should contain the entry. |
0xD, 0xE, 0xF, 0x23, 0x24, 0x25 |
A freed block’s header changed after it was freed. | Microsoft says this is often an overrun from the preceding block, rather than a fault by the freed block’s previous owner. |
0x20 |
A pool block’s header size is corrupt. | Arg2 and Arg3 identify expected and next entries. |
0x21 |
Data following the block being freed is corrupt. | Often indicates that the block’s consumer overran it. |
0x22 |
An address being freed has no tracking entry. | Often points to a pointer already freed or never allocated. |
These descriptions are Microsoft’s documented classifications. The same argument position can mean different things for different Arg1 values, so do not interpret Arg2–Arg4 without first reading Arg1. Microsoft Learn
A closer look at 0x21 and 0x22
These two values give particularly useful investigative directions:
- With Arg1 =
0x21, Arg2 is the pool pointer being freed, Arg3 is the allocated byte count, and Arg4 is the corrupt value found after the block. Microsoft says an overrun by the consumer on the call stack is typical. - With Arg1 =
0x22, Arg2 is the address being freed. Microsoft says the missing tracking entry usually means code tried to free a pointer that had already been freed or had never been allocated. Microsoft Learn
How to Investigate BAD_POOL_HEADER in WinDbg
1. Preserve the dump and record its arguments
Keep the crash dump and note the precise four arguments. The blue-screen name alone cannot distinguish an overrun, an invalid free, or another pool-header inconsistency.
2. Run the initial analysis
Open the dump in WinDbg and enter:
!analyze -vRecord the Arg1 subtype, the stack, any pool addresses, and any suggested module. Microsoft recommends using !analyze, while cautioning that it frequently cannot pinpoint the driver that originally corrupted the pool. Microsoft Learn
3. Match the subtype to the documented parameter table
For example, an Arg1 of 0x3 calls for examination of the free-list values in Arg2–Arg4. An Arg1 of 0x22 directs attention to the address being freed and how it was allocated and released. Do not follow an 0x21 interpretation for an 0x22 crash.
4. Inspect pool links and allocation history
Microsoft says the internal pool links may need to be walked with the kernel debugger to find a possible cause. A developer can use the relevant pool addresses and tags from the dump to narrow the suspect allocation and the code that used it. This can require a richer dump or a reproducible test case. Microsoft Learn
5. Use Special Pool for a suspect driver
When the evidence points to a driver or pool tag, Special Pool can help catch an invalid access closer to the operation that causes it. Microsoft recommends Special Pool for suspect tags or Driver Verifier’s Special Pool option for a suspect driver. Verify the smallest practical set of drivers because Driver Verifier adds overhead and can deliberately cause crashes while exposing defects. Use it in a suitable test environment or maintenance window. Microsoft Learn
Troubleshooting on a Regular PC
If you are not developing a driver, work from evidence that is available to you:
- Note when the crashes began. Check whether a driver, device, security product, or other kernel-level software was installed or updated just before them.
- Keep the dumps. Repeated crashes with the same subtype and related stack may provide a stronger lead than one crash.
- Investigate a supported driver lead. Obtain an update or rollback from the device or software vendor when dump analysis points to that component.
- Check physical memory if crashes are inconsistent. Microsoft says inconsistent appearances of 0x19 could relate to faulty physical memory and recommends Windows Memory Diagnostic. Its results can be viewed in Event Viewer’s System log under MemoryDiagnostics-Results. Microsoft Learn
A memory test finding an error is important evidence. A clean test, however, does not prove that a driver could not have corrupted a pool block; continue to use the crash subtype and dumps to guide the investigation.
Guidance for Driver Developers
Review the code associated with the suspect allocation and its pool tag. Depending on Arg1, concentrate on:
- Writes beyond an allocation’s end.
- Writes into an adjacent block or a block that has already been freed.
- Double frees.
- Freeing pointers that were never valid pool allocations.
- Incorrect block size or pointer calculations.
- Concurrent use and cleanup of the same allocation.
Instrument a reproducible case with Special Pool or targeted Driver Verifier settings. The aim is to detect the first invalid operation, which may precede the eventual BAD_POOL_HEADER crash. Microsoft’s parameter table is the guide for selecting the most relevant hypothesis. Microsoft Learn
Frequently Asked Questions
What does BAD_POOL_HEADER mean?
Windows detected a corrupt kernel pool header. It reports this condition as bug check 0x00000019. Microsoft Learn
Does BAD_POOL_HEADER always mean faulty RAM?
No. Driver memory corruption is an important possibility. Microsoft suggests Windows Memory Diagnostic particularly when the bug check appears inconsistently. Microsoft Learn
Which argument matters most?
Start with Parameter 1 (Arg1). It identifies the violation type and determines how to interpret the remaining arguments. Microsoft Learn
Does Arg1 = 0x21 suggest a buffer overrun?
Often, yes. Microsoft says the data following a block being freed is corrupt and that its consumer, shown on the call stack, has typically overrun it. Confirm this against the dump. Microsoft Learn
What does Arg1 = 0x22 suggest?
An address being freed has no tracking entry. Microsoft says this usually occurs when code tries to free a pointer that was already freed or never allocated. Microsoft Learn
Is the driver named by !analyze -v definitely responsible?
No. Pool corruption can be discovered after it occurs, while another driver is running. Microsoft specifically cautions that !analyze frequently cannot pinpoint the pool corrupter. Microsoft Learn
Should I enable Driver Verifier for every driver?
Target a suspect driver or small set of drivers. Microsoft notes that verification adds overhead and recommends verifying as few drivers as practical. Driver Verifier can intentionally stop the system when it detects a fault. Microsoft Learn
Summary
BAD_POOL_HEADER (0x00000019) means Windows found corrupt pool bookkeeping. Its first parameter distinguishes several situations, including free-list corruption, adjacent header inconsistencies, writes beyond a block, and invalid frees. The code that detects the corruption may not be the code that caused it. Use the full dump, the subtype-specific parameter definitions, and targeted pool or driver checks to find the original fault. Microsoft Learn
Sources
Was this guide useful?
Your answer helps us keep BISONKB accurate and practical.