Fix BAD_POOL_HEADER BSOD (0x00000019) in Windows 11

BAD_POOL_HEADER, or stop code 0x00000019, means that a block of kernel memory has a damaged bookkeeping header. Windows uses an allocator called the pool to hand memory to drivers, and every allocation carries a small header recording its size and its place in a list. When that header no longer makes sense, Windows stops rather than let the damage spread.

This stop code has a reputation for being hard to fix, and there is a good reason. The driver named in the crash is usually not the one that caused the damage. This guide explains why, what parameter 1 tells you, and how to catch the real culprit.

PAGE CONTENT

• What a Pool Header Is and What 0x19 Means
• Read Parameter 1 to See How the Block Was Damaged
• Why the Driver in the Crash Is Usually Wrong
• Fix 1: Use Driver Verifier with Special Pool
• Fix 2: Test the Memory
• Fix 3: Audit Recently Added and Duplicated Drivers
• Fix 4: Repair System Files and Update
• FAQs About BAD_POOL_HEADER
• Back Up and Restore Windows with Qiling Disk Master

What a Pool Header Is and What 0x19 Means

Drivers do not allocate memory one byte at a time. They ask the kernel pool for a block of a given size, and the allocator returns a pointer to the usable area. Immediately in front of that area sits the header, which stores the size of the block and the links that connect it to the free list or to the neighbouring blocks.

When the allocator next inspects a block and finds a size that cannot be correct, links that do not match each other, or a freed block whose contents changed, it raises this stop code. In every case the message is the same: pool memory has been corrupted.

The realistic causes are narrow, and they are worth separating early:

• A driver wrote past the end of its own allocation and damaged the header of the neighbouring block
• A driver freed the same block twice, or freed a pointer it never allocated
• The memory hardware itself returned wrong data, which the allocator then recorded as a valid-looking header

The third possibility is easy to overlook, so Microsoft states it plainly: if this error check is inconsistent, meaning it appears intermittently rather than on a repeatable action, it may be related to a physical memory fault. That is why memory testing belongs in this repair, not only driver work.

Read Parameter 1 to See How the Block Was Damaged

Parameter 1 identifies the type of violation, and the remaining parameters depend on it. The values fall into four useful families.

Header size or structure is impossible. Values 0x6, 0x7, 0x8, 0x9, 0xA and 0x20 all describe a block whose recorded size cannot be right, whether it is absurdly large or zero. A stored size that no longer matches reality is the classic fingerprint of something having written over the header.

Something overran the end of a block. Value 0x21 means that the data immediately after the block being freed is corrupted, and Microsoft notes that this usually means the caller overran the block. The family 0xD, 0xE, 0xF, 0x23, 0x24 and 0x25 covers a freed block that was modified after being freed, and here the documentation makes a point that saves a lot of wasted effort: this is usually not the fault of the block's previous owner, but of the block allocated just before it having overflowed.

A free was invalid. Value 0x22 means the address being released has no tracking entry at all, which normally means the code tried to free a pointer that was already freed or never allocated in the first place.

Lists or neighbours disagree. Value 0x3 means the free list is corrupted, and in a healthy list the second, third and fourth parameters should be identical, so a mismatch is itself the evidence. Value 0x5 means two adjacent block headers contradict each other, so at least one of them is damaged.

Why the Driver in the Crash Is Usually Wrong

Corruption happens silently. A driver writes a few bytes past the end of its own buffer, and those bytes land in the header of the block next to it. Nothing goes wrong at that moment. The machine carries on, possibly for hours, until the allocator touches the damaged block and finds a size or a link that cannot be true.

By then, the driver that caused the damage has finished and left the stack. The driver on the stack is the one that happened to use the damaged block, so it is the victim, not the attacker. This is why updating the driver named in the crash so often changes nothing, and why people end up replacing perfectly good hardware.

Microsoft's guidance follows the same logic: the analysis extension may help point at a suspect driver, but it points at the consumer of the corrupt memory rather than the corruptor. To find the corruptor you have to catch it in the act, which is exactly what the special pool option of Driver Verifier is designed to do.

Fix 1: Use Driver Verifier with Special Pool

Step 1. Open Command Prompt as administrator and run verifier to start the Driver Verifier Manager. You can also launch it from the Start menu by typing the same word.

Step 2. Choose the option to create custom settings, then select individual drivers rather than all of them. Verify only the drivers you suspect, because verification adds real overhead and verifying everything can make the machine unusable.

Step 3. Enable the special pool option. Special pool places an allocation at the very end of a memory page and leaves an unmapped page immediately after it, so the moment a driver writes even one byte past the end of its buffer, the processor faults at that instruction. That converts a silent corruption into an immediate, correctly attributed crash.

Step 4. Restart and use the machine normally. When the new stop code appears, the stack now shows the driver that performed the illegal write, which is the information you needed.

Step 5. Record your verification settings before you start, and turn verification off when you are finished with verifier /reset. If the machine enters a boot loop instead of starting, our guide on DRIVER_VERIFIER_DETECTED_VIOLATION explains how to reset the settings from the recovery environment.

Fix 2: Test the Memory

Step 1. Run the built-in checker first. Press Windows and R, type mdsched.exe, and choose to restart and check now. Windows records the result in Event Viewer under the memory diagnostics entry, so you can read it after the machine restarts.

Step 2. Follow up with a thorough test. A bootable memory tester that completes four or more full passes, ideally overnight, catches faults the built-in check misses.

Step 3. Disable the memory profile in BIOS or UEFI, whether it is labelled XMP or EXPO, and remove any processor or graphics overclock. Those settings run memory outside the timings the platform guarantees, and the resulting corruption is indistinguishable from a failing module.

Step 4. If errors appear, reseat the modules, clean the contacts, and test one module at a time to isolate the faulty stick. Replace it, because no driver change will compensate for unreliable memory.

Fix 3: Audit Recently Added and Duplicated Drivers

Step 1. Establish the timeline. If the stop code began after you installed a product or attached a device, that change is the best lead you have, and the timing matters more than the driver named on screen.

Step 2. Look for two products doing the same job. Two antivirus suites, an old backup tool alongside a new one, a disk encryption product plus a virtual private network client: each installs a filter driver, and duplicate filters routinely write into memory that belongs to the other one.

Step 3. Remove the product you no longer need and restart. Disabling it is not enough, because a disabled filter driver can still be loaded and can still corrupt memory.

Step 4. Update the drivers of newly added hardware from the manufacturer rather than from Windows Update, and repeat the workload that used to crash.

Fix 4: Repair System Files and Update

Step 1. Open Command Prompt as administrator and repair the component store, then the protected system files:

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

Step 2. Install all pending Windows updates, including optional driver updates, since Microsoft fixes pool handling bugs in both Windows and its own drivers over time.

Step 3. Update the system firmware and the chipset drivers. Both control how memory is initialised at boot, and an older firmware release can contain memory handling defects that later versions correct.

Step 4. Check the health of the system drive. Read the SMART attributes and look at the reallocated sector count and the remaining life value, because a failing drive can return corrupted data that reaches kernel memory.

FAQs About BAD_POOL_HEADER

Why does the crash name a driver that has worked for years?

Because corruption is silent. The driver on the stack is whoever touched the damaged block afterwards, which is often a stable, blameless driver. The real cause is the driver that wrote past its buffer, and it may have done so hours earlier.

What does parameter 0x21 mean?

The data immediately after the block being freed is corrupted, and Microsoft attributes this to the caller having overrun the block. In plain terms, someone wrote past the end of their own allocation.

What does parameter 0x22 mean?

The address being released has no tracking entry, which normally means a double free or an attempt to free a pointer that was never allocated.

Can faulty memory really cause this?

Yes. Microsoft notes that when this error check is inconsistent it may be related to a physical memory fault. If the crash appears at random rather than on a repeatable action, test the memory before you spend more time on drivers.

Will resetting Windows fix it?

Only if the corrupting component is removed by the reset. If the cause is a product you reinstall afterwards, or faulty memory, the stop code returns.

How do I know the problem is solved?

Run the machine normally for several days after removing the suspect component. This stop code is intermittent by nature, so one clean boot says very little.

Back Up and Restore Windows with Qiling Disk Master

Chasing pool corruption means Safe Mode sessions, Driver Verifier experiments, and driver removals, and any of those can leave a machine that will not start. Create a full system backup before you begin. Qiling Disk Master handles both the backup and the restore.

• Free Download
• Windows 11/10/8/7, 100% Secure

Part 1: Create a Full System Backup

Step 1. Install and open Qiling Disk Master. On the home screen, open "Backup and Recovery" and choose "System Backup". This option automatically includes Windows and the hidden boot partitions, so you do not have to select them one by one.

Step 2. Check the source. The disk where Windows is installed and its system partitions are already ticked for you. If you only need your personal documents, run a separate "File Backup" task instead.

Step 3. Click the destination box and choose where the image should be saved. Use an external HDD or SSD, a NAS, or any drive other than the one Windows is installed on, and make sure it has enough free space.

Step 4. Review the task summary and click "Proceed". Wait until the progress bar reaches 100%. Do not unplug the drive or turn off the PC while the backup is running.

Part 2: Restore Windows from the Backup

Step 1. Open Qiling Disk Master again, go to "Backup and Recovery", and select the recovery option. Your backup images are listed, so pick the one you created before the changes began.

Step 2. Choose the target disk or partition. Normally you restore to the original system disk. If the drive was replaced, select the new disk instead, and the restore rebuilds Windows together with its boot partitions.

Step 3. Preview the restore plan, click "Proceed", and confirm the warning. The PC restarts to finish the job, and Windows comes back exactly as it was on the day the image was created, with your files and programs intact.

Conclusion

BAD_POOL_HEADER means a kernel memory block header was damaged, and the crucial detail is that the driver named in the crash is usually the victim rather than the cause. Parameter 1 tells you how the block was damaged: values such as 0x21 and the 0xD family point at a buffer overrun by a neighbouring block, while 0x22 points at an invalid or repeated free. Because the corruptor has already left the stack by the time Windows notices, use Driver Verifier with the special pool option on suspect drivers to catch the illegal write at the moment it happens, and test the memory thoroughly, since Microsoft notes that intermittent reports may come from a physical memory fault. Finish by removing duplicate filter drivers and repairing the system files.

Protect your PC with Qiling Backup—create a system image before your next troubleshooting step.

Related Articles

• Fix BAD_POOL_CALLER BSOD in Windows 11
  The close relative of this stop code. A driver violating the pooling rules is the theme running through both.
• Fix PFN_LIST_CORRUPT BSOD (0x0000004E) in Windows 11
  Another memory bookkeeping structure that fails the same way, and the parameter values that separate a driver from bad RAM.
• Fix DRIVER_VERIFIER_DETECTED_VIOLATION (0xC4) in Windows 11
  Special pool and the other verification options explained, including how to escape a boot loop if verification goes wrong.
• MEMORY_MANAGEMENT Blue Screen in Windows 11: How to Fix It
• The PAGE_FAULT_IN_NONPAGED_AREA Error: Causes and Fixes
• Fix DRIVER_OVERRAN_STACK_BUFFER (0xF7) in Windows 11