0x00000019 BAD_POOL_HEADER Fixes and Common Causes

If the system can still boot, start in Safe Mode and check the most recent minidump in C:\Windows\Minidump before you change anything. I check recent software changes first, then memory-related changes, then storage and system file checks. This guide sorts the fault by crash pattern, boot state, driver evidence, and minidumps on current Windows versions and older builds.

This guide is part of our Windows BSOD stop codes: full list and fixes series.

Evidence checklist: Use WinDbg, WinDbg Preview, or another Windows minidump viewer on the newest file in C:\Windows\Minidump. Look for the bug check parameters, MODULE_NAME, IMAGE_NAME, and whether the same third-party driver repeats across dumps. Decision rule: if Safe Mode is stable and normal mode crashes, move third-party drivers and security software to the top; if Safe Mode also crashes, move memory testing and storage checks up immediately.

What does 0x00000019 mean in Windows?

0x00000019 is BAD_POOL_HEADER. Microsoft lists that bug check name for this stop code in its bug check reference. (official source)

What evidence matters first

Start with the pattern, not random fixes. A crash at boot, one only during shutdown, one while a backup runs, and one that shows up only in normal mode do not belong in one bucket.

In practice, the clues that pay off fastest are whether Safe Mode works, whether a minidump names a driver, and whether the crash returns during the same task after one targeted change. If you need a refresher on the broader workflow, see this BSOD troubleshooting checklist.

Where to find evidence on Windows 11 and 10

1. Open File Explorer and check C:\Windows\Minidump for recent .dmp files.
2. Open Control Panel > Security and Maintenance > Reliability Monitor and look for the red X at the crash time.
3. Open Event Viewer > Windows Logs > System and review errors around the same minute.
4. On Windows 11, if normal boot fails, go to Settings > System > Recovery > Advanced startup > Restart now, then Troubleshoot > Advanced options > Startup Settings > Restart and choose Safe Mode.
5. On Windows 10, use Settings > Update & Security > Recovery > Advanced startup > Restart now, then the same Startup Settings path.

Which causes are most likely for 0x00000019?

Most often, this stop code leads back to third-party drivers or security software conflicts, then RAM faults, then storage or file-system trouble. If the system is stable in Safe Mode, I move third-party software higher on the list. If Safe Mode also crashes, I move RAM and disk checks higher.

Ranked likely causes

Third-party drivers and software: dumps that name a vendor driver are the strongest practical lead, especially if Safe Mode is stable.

Security suites: BleepingComputer reported that possible culprits can include conflicting security programs or incorrect Comodo settings, or Comodo being installed incorrectly. It also reported that Comodo Internet Security had not been updated for at least the last three years and that the last release was in March 2020.

RAM: memory faults can corrupt kernel memory, especially when crashes continue in Safe Mode or dumps vary from one crash to the next. I use Windows Memory Diagnostic and deeper RAM testing after the obvious software branch.

Storage or file-system trouble: if the crash appears during heavy file activity or system repairs do not finish cleanly, move disk checks and system file checks higher.

How Safe Mode changes the ranking

If Safe Mode is stable, move drivers and security software to the top of the list. If Safe Mode also crashes, RAM and deeper storage damage move up fast.

A named driver is a lead, not a verdict. It still gives you the best next move: remove or roll back the software that installs it, then test the exact same task that used to trigger the crash.

How do I fix 0x00000019 on Windows 11?

On Windows 11, the fastest clean path is: boot into Safe Mode if possible, collect the latest minidump from C:\Windows\Minidump, check whether a third-party driver is named, then remove or roll back the related software before moving on to memory testing and storage checks.

One-page triage matrix

Windows 11 repair ladder

1. Boot to Settings > System > Recovery > Advanced startup and enter Safe Mode.
2. Open Device Manager, find the device tied to the named driver, then use Properties > Driver > Roll Back Driver or Uninstall Device.
3. Open Windows Security from Settings > Privacy & security > Windows Security and keep Microsoft Defender active while testing without the third-party suite.
4. Run Windows Memory Diagnostic from the Start menu.
5. Open Command Prompt as administrator and run sfc /scannow, then DISM /Online /Cleanup-Image /RestoreHealth, then chkdsk.

Can bad drivers cause a 0x00000019 blue screen?

Yes. Driver conflicts and outdated drivers are a common branch for this stop code, especially when the system is stable in Safe Mode or the dump names a third-party file. I act on the named driver first rather than updating every device blindly.

When the dump names a driver

1. Check the newest file in C:\Windows\Minidump and note the driver name shown by your dump reader.
2. Open Device Manager, locate the related device, and use Properties > Driver > Roll Back Driver if the issue started after an update.
3. If rollback is unavailable, use Device Manager > right-click device > Uninstall device, then reboot and reinstall the vendor driver.
4. If the driver belongs to software, remove that app through Settings > Apps > Installed apps, reboot, and repeat the exact same task that used to trigger the crash.

Driver Verifier: use carefully

Driver Verifier is an advanced Windows tool for stressing drivers so a bad one fails more clearly in a dump. It can be useful after basic rollback and uninstall steps fail, but I still reserve it for controlled testing. If you want the setup and exit steps in one place, use this Driver Verifier guide.

1. Only use it after Safe Mode checks, dump review, and a normal uninstall or rollback have failed.
2. If Verifier triggers a boot loop, return to Advanced startup > Troubleshoot > Advanced options > Startup Settings and boot Safe Mode.
3. From there, remove the flagged driver in Device Manager or uninstall the related app in Settings > Apps.

Should I uninstall antivirus for 0x00000019?

Uninstall antivirus only when the evidence points there: Safe Mode is stable, the dump names a security driver, or the crashes began right after a suite install or update. That is a targeted test, and in practice it often beats random driver churn.

When a security suite is the main suspect

BleepingComputer reported that conflicting security programs, incorrect Comodo settings, or an incorrect Comodo installation can be possible culprits. It also reported that Comodo Internet Security had not been updated for at least the last three years and that the last release was in March 2020. Old security software is worth testing carefully because it installs low-level drivers.

Exact removal and retest steps

1. If the named driver belongs to a security suite, remove the suite from Settings > Apps > Installed apps.
2. If the product is Comodo, run the Comodo uninstall tool, because that was the removal method recommended in support guidance reported by bleepingcomputer.com.
3. Restart Windows and leave Windows Security active temporarily on Windows 11 or Windows 10.
4. Install all available Windows updates, then install any pending updates for the programs you normally use.
5. Repeat the exact task that used to trigger the blue screen, such as the same app launch, file copy, or login path.
6. If the system stays stable through that same task, the security software conflict is the likely path. If you still need Comodo, BleepingComputer reported the best sequence as uninstalling Comodo, doing Windows and program updates, and only then installing Comodo again.

Does faulty RAM cause BAD_POOL_HEADER?

Yes, faulty RAM can cause it, but I move RAM to the top only when crashes continue in Safe Mode, dumps point nowhere consistent, or driver removal changes nothing. Use Windows Memory Diagnostic first, then test sticks and settings before you blame the board or SSD.

Memory-focused fix steps

1. Run Windows Memory Diagnostic from the Start menu and restart when prompted.
2. If you recently added RAM, enabled an XMP/EXPO memory profile, changed memory speed, voltage, or timing settings, enter firmware setup and return the memory settings to the previous known-stable values or the board defaults before more testing.
3. If your PC has more than one memory module and you can safely access them, power the PC off, disconnect power, remove all but one stick, then boot Windows with that single module installed. Shut down and repeat the test with each stick and, if needed, each slot.
4. After each memory change, run the same app, game, file copy, or other workload that used to trigger the crash so you can tell quickly whether that exact change mattered.

What RAM evidence looks like

RAM trouble tends to produce inconsistent dumps, crashes in Safe Mode, and failures that are hard to tie to one app or one driver. Filter-driver trouble looks different: stable Safe Mode, repeatable crashes under one task, and dumps that keep circling the same vendor file. For a fuller workflow, I use this memory test guide alongside minidump review.

What if the crash happens during shutdown, backup, or imaging?

If the system blue screens only during shutdown, treat it as a separate branch and review the dump and event timing around shutdown. If the crash appears during backup or imaging, verify whether it returns during that same task after one targeted software change.

Shutdown-only branch

A shutdown-only crash is easiest to verify when you keep the trigger narrow and repeatable.

1. Open the newest file in C:\Windows\Minidump and check whether the same third-party driver appears across shutdown crashes.
2. Open Event Viewer > Windows Logs > System and compare the errors and warnings logged in the same minute as the shutdown blue screen.
3. If the dump points to a recently added device or driver, remove or roll back that item in Device Manager before more testing.
4. Retest by doing several full shutdowns in a row, then powering back on each time, so you can confirm whether the same shutdown path still crashes.

Backup, imaging, VSS, and UpperFilters

If a crash repeats during backup, snapshot, or imaging, keep the test narrow and repeat the exact same job after one change. That makes it much easier to tell whether a software conflict is still present.

1. Remove or disable the backup or imaging software that was active during the crash.
2. Run the same backup, snapshot, or imaging job again instead of waiting for a random crash, and note whether the blue screen returns during that exact task.
3. Open Event Viewer > Windows Logs > System and review storage-related events from that run.
4. Only if the evidence points to a storage software conflict, leave that software removed while you complete the same job again to confirm the result.

Still not working? Use this escalation ladder and verify the fix

If the obvious driver, security-software, memory, and storage branches do not fix it, move to system repair and hardware-adjacent checks in order. Change one thing, repeat the old trigger, and confirm that no new dump appears before you call it fixed.

If that didn’t work, try this next

1. Open Command Prompt as administrator and run sfc /scannow.
2. Then run DISM /Online /Cleanup-Image /RestoreHealth.
3. Run chkdsk and review the result after restart.
4. Perform a clean boot with msconfig and test the same trigger with non-Microsoft startup items disabled.
5. If Windows remains unstable on Windows 11, open Settings > System > Recovery and select Reset this PC. On Windows 10, open Settings > Update & Security > Recovery and select Reset this PC.

How to confirm the fix

A fix is real when the same trigger no longer causes a bugcheck, the system completes repeated clean boots and shutdowns, C:\Windows\Minidump stops getting new files, and Reliability Monitor shows a clean trend.

Prevention: avoid stacking security suites, and be cautious with older security software that may no longer receive meaningful updates.

Frequently asked questions

What causes BAD_POOL_HEADER 0x00000019?

Most cases trace to third-party drivers, security software conflicts, RAM faults, or storage and file-system trouble. Use the pattern first: if Safe Mode works, remove the named driver or suite; if Safe Mode also crashes, run Windows Memory Diagnostic and then chkdsk before chasing edge cases.

How do I check whether a specific driver caused the crash?

Open C:\Windows\Minidump, inspect the newest dump with your preferred reader, and note any repeated third-party file name. Treat that as a lead. Then roll back or uninstall the related device or app in Device Manager or Settings > Apps and retest the same trigger. If you need help reading the dump fields, start with this minidump guide.

Is 0x00000019 the same as BAD_POOL_HEADER?

Yes. They are the stop code value and bug check name for the same crash.

What if Windows only blue screens during shutdown?

Keep a shutdown-only crash in its own branch. Review the newest dump, compare it with Event Viewer > Windows Logs > System at the same time stamp, remove or roll back any recently added driver the dump points to, and then test with several full shutdowns in a row.

Can backup or imaging software trigger 0x00000019?

It can be part of the path when the crash is repeatable during the same backup, snapshot, or imaging job. Remove or disable the software that was active, rerun that same job, and then review Event Viewer > Windows Logs > System for matching errors.

What if 0x00000019 keeps happening?

Go back to a strict one-change-at-a-time test order: Safe Mode check, minidump review, removal of the most likely recent driver or security software, memory testing, then sfc, DISM, and chkdsk. If it still returns after those steps, use Reset this PC from Windows Recovery settings.

Why does 0x00000019 surface during the same task every time?

That pattern usually means one specific software path is triggering it. Repeat the exact same app launch, backup job, file copy, or shutdown path after each change so you can tell which driver or program removal actually stopped the crash.

Why this answer is worth an account

Because the useful split is upfront: Safe Mode stable or not, shutdown-only or not, and whether the minidump names a driver. That diagnosis tree avoids wasted part swaps, cuts repeat crashes, and gives a clear next action with evidence to collect at each branch.