⚠ CrashDecoder

0x000000C2 BAD_POOL_CALLER

Kernel drivers request memory from shared pools and are expected to return it correctly. This bugcheck fires when one of them breaks the rules - freeing the same block twice, releasing memory it does not own, or asking for an allocation at an interrupt level where that is not permitted. It is one of the few stop codes where Microsoft names the diagnostic tool outright, and that tool works.

Updated 2026-07-28Stop errorAlso written: 0xC2, BAD POOL CALLER, bad_pool_caller, bad pool header

What you are looking at

:(

Your PC ran into a problem and needs to restart.

Stop code: BAD_POOL_CALLER

In Event Viewer the matching entries look like this:

Log Name:      System
Source:        BugCheck
Event ID:      1001
Level:         Error

The computer has rebooted from a bugcheck.  The bugcheck was: 0x000000c2 (0x0000000000000007, 0x0000000000001204, 0xffffb80f2c1a4530, 0xffffb80f2c1a3d70).

What the error actually means

Windows keeps two pools of kernel memory: nonpaged pool, which is always resident, and paged pool, which can be written out to disk. Drivers allocate from these and are responsible for returning what they take, with the same tag they used, at an appropriate interrupt level.

The pool manager checks these things. When a request violates the rules it stops the machine rather than corrupt the allocation structures - because a pool that has been corrupted will damage something unrelated later, and the resulting crash would be far harder to trace.

So this bugcheck is a driver being caught in the act, which is unusually convenient. The violation type in parameter 1 tells you exactly what the driver did wrong, and Driver Verifier can reliably identify which driver did it.

Reading the parameters

Parameter 1 is the violation type and there are around two dozen documented values. These are the ones that actually appear. Parameters 2 to 4 mean different things for each value.

ParameterWhat it holds
0x07The thread attempted to free pool that was already freed - a double free, and the most common value here. Parameter 3 holds the pool header contents, parameter 4 the address of the block being freed.
0x06Also a double free, detected at a different point. Parameter 3 points at the pool header, parameter 4 holds its contents.
0x0AThe thread tried to free pool memory using the wrong tag - meaning the memory probably belongs to another component. Parameter 2 is the pool address, parameter 3 the allocator's tag, parameter 4 the tag used in the attempted free. Comparing those two tags identifies both parties.
0x01 / 0x02 / 0x04The pool header has been corrupted. Parameter 2 points at the pool header and parameter 3 holds the first part of its contents. Corruption rather than a rule violation - which means memory or a driver overrunning a neighbouring allocation.
0x08An allocation was attempted at an invalid IRQL. Parameter 2 is the current IRQL, parameter 3 the pool type, parameter 4 the size requested.
0x09A free was attempted at an invalid IRQL. Parameter 2 is the current IRQL, parameter 3 the pool type, parameter 4 the pool address.
0x99A free was attempted with an invalid address. Microsoft notes this can also indicate corruption in the pool header. Parameter 2 is the address being freed.
0x40The thread tried to free kernel pool at a user-mode address - a clear pointer error in a driver.
0x41 / 0x44 / 0x47 / 0x48 / 0x50The thread tried to free a non-allocated pool address, in nonpaged or paged pool depending on the value. Parameter 2 is the starting address.
0x00The thread requested a zero-byte allocation. Parameter 3 is the pool type, parameter 4 the pool tag.
Pool type valuesWhere a parameter holds a pool type, 0 means nonpaged pool and 1 means paged pool.

What actually triggers it

This is a driver bug by definition. The question is only which driver, and whether memory corruption is making an innocent one look guilty.

CauseHow oftenDetail
A specific third-party driverCommonThe direct cause in most cases. Anti-virus filter drivers, VPN clients, virtual drive software, RGB and peripheral utilities, and older network drivers are the recurring names.
Anti-virus and security softwareCommonThese allocate and free pool memory aggressively while scanning file and network operations. A version mismatch after a Windows update produces double frees reliably.
Failing RAMOccasionalCorruption in a pool header - values 0x01, 0x02, 0x04 and sometimes 0x99 - can come from memory rather than from a driver. Microsoft's own resolution guidance for this bugcheck specifically recommends running a memory diagnostic for pool corruption cases.
A driver overrunning its allocationOccasionalA driver writing past the end of its own block damages the header of the block next to it. The driver that later frees that neighbouring block gets blamed, despite doing nothing wrong.
Unstable memory settingsOccasionalAn XMP or EXPO profile beyond what the memory controller sustains produces the same corruption signature as failing modules.

Narrowing it down

The violation type splits this into two very different investigations, so read it first.

Classify the violation type

Take parameter 1 from the bugcheck event or from !analyze -v.

What it tells you

Values like 0x07, 0x0A, 0x08 and 0x09 are rule violations - a driver did something specific and wrong, and Verifier will find it. Values 0x01, 0x02, 0x04 and often 0x99 are corruption - the pool structures themselves are damaged, which puts memory and neighbouring-allocation overruns in scope alongside drivers.

Compare the tags when parameter 1 is 0x0A

This value gives you unusually direct evidence. Parameter 3 holds the tag of whichever component allocated the memory, and parameter 4 holds the tag the offending driver tried to free it with. Pool tags are four-character identifiers and are often recognisable.

What it tells you

Two different tags tells you which component owns the memory and which one is mishandling it. That is close to a named culprit without further work.

Check whether the named module is consistent

Open several dumps and compare MODULE_NAME from !analyze -v.

What it tells you

The same driver each time is a genuine bug in that driver. Different drivers each time points at corruption, and the investigation shifts to memory.

Fixes, cheapest first

Microsoft's recommended resolution for this bugcheck is Driver Verifier with pool options, and unusually, that advice is worth following early rather than last.

  1. Run Driver Verifier with pool options

    Effort: Several hours · Risk: Medium

    This is the tool built for this exact failure. Special Pool places each allocation so that an overrun or a use-after-free faults immediately and identifiably, rather than corrupting a neighbour and surfacing somewhere unrelated. Pool Tracking catches drivers that leak or mismanage allocations.

    1. Create a restore point, and confirm you can reach Safe Mode before starting.
    2. Run verifier as administrator, choose Create custom settings, then Select individual settings from a full list.
    3. Enable Special Pool, Pool Tracking, Force IRQL checking and I/O Verification.
    4. Choose Select driver names from a list and tick only drivers not provided by Microsoft.
    5. Use the machine until it bugchecks. The dump will name the offending driver directly.
    6. Turn it off with verifier /reset and reboot.
    Watch out

    Verifier deliberately increases crashes and can cause a boot loop. Run verifier /bootmode resetonbootfail before enabling any checks - it makes Verifier disable itself automatically if the machine fails to start, which removes most of the risk. Your manual exit is Safe Mode followed by verifier /reset. Full settings and the escape route are in the Driver Verifier guide.

  2. Remove third-party security software

    Effort: 20 minutes · Risk: Low

    Given how often anti-virus filter drivers are responsible, uninstall third-party security products first and run on Windows Defender for a few days. Use the vendor's dedicated removal tool rather than the standard uninstaller - these products routinely leave kernel drivers behind that the uninstaller misses.

  3. Update or remove the named driver

    Effort: 20 minutes · Risk: Low

    If the dumps consistently name one module, install the vendor's current version. If the crashes began after a driver update, install the previous release instead. If it belongs to software you do not use, uninstall it entirely - a driver you do not need is a driver that cannot crash you.

  4. Test memory when the parameter indicates corruption

    Effort: Overnight · Risk: None

    For parameter 1 values of 0x01, 0x02, 0x04 or 0x99, memory is genuinely in scope. Disable XMP or EXPO, then run MemTest86 from USB for at least four passes.

    Microsoft's guidance for pool corruption specifically suggests running a memory diagnostic - though the built-in Windows tool is far less sensitive than MemTest86, so do not treat a pass from it as meaningful.

  5. Strip back kernel-level software

    Effort: 30 minutes · Risk: Low

    Uninstall anything running at kernel level that you do not actively need: RGB and fan utilities, VPN clients, virtual drive software, old printer packages, anti-cheat services from games you no longer play. Then run a clean boot with msconfig for a day.

When it is the hardware, not Windows

Mostly software, so hardware signals need to be clear:

That fifth item is worth weighting. Driver Verifier is aggressive and thorough - if it runs for several days across every non-Microsoft driver and never catches anything, that is meaningful evidence that no driver is misbehaving, and attention should move to memory.

Frequently asked

What is a pool tag and why does it matter?

A four-character label a driver attaches to each allocation so the system can track who owns what. When parameter 1 is 0x0A, the bugcheck gives you both the tag the memory was allocated with and the tag it was being freed with - which identifies the owning component and the offending one at the same time. Tags are often recognisable strings, and searching one frequently identifies the driver directly.

Is BAD_POOL_CALLER the same as BAD_POOL_HEADER?

Related but distinct. BAD_POOL_CALLER (0xC2) means the caller made an invalid request. BAD_POOL_HEADER (0x19) means the pool structures were found already damaged. In practice they overlap heavily - several 0xC2 parameter values indicate header corruption too - and the troubleshooting converges on the same place: Driver Verifier first, memory testing if Verifier finds nothing.

Verifier put me in a boot loop. How do I get out?

Interrupt the boot three times with the power button to reach the recovery environment, then Troubleshoot, Advanced options, Startup Settings, Restart, and choose Safe Mode. From there run verifier /reset in an administrator prompt and reboot normally. This is why the instructions say to confirm you can reach Safe Mode before enabling it - the escape route is simple, but only if you know it in advance.

Why does the crash blame a driver that has been installed for years?

Two reasons. Either something changed around it - a Windows update altered kernel behaviour, or another driver started overrunning into its allocations - or the driver is a victim of corruption originating elsewhere. A long-standing driver suddenly appearing in dumps is more often a symptom than a cause. Check whether the named module is consistent across several crashes before uninstalling something that worked fine for years.