BAD_POOL_CALLER Blue Screen 0xC2: What Microsoft's 28 Violation Values Mean

BAD_POOL_CALLER is Windows stop code 0x000000C2 (0xC2). Microsoft's reference says it indicates "that the current thread is making a bad pool request." Where BAD_POOL_HEADER (0x19) is about damage found in the pool, this code is about the request itself: asking for memory, or giving memory back, in a way that is not allowed.

The cause is summarised in one sentence: an invalid pool request "typically at a bad IRQL level or double freeing the same memory allocation." The first parameter then says which kind of violation it was.

This page is built from the Microsoft Learn article "Bug Check 0xC2: BAD_POOL_CALLER" 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 0xC2 page as written for programmers and directs customers to https://www.windows.com/stopcode. Anything taken from the general page rather than the 0xC2 page is labelled as such.

What does parameter 1 tell you?

Parameter 1 indicates the type of violation. A selection of the values in Microsoft's table, grouped by what the thread did wrong:

Parameter 1	What the current thread did wrong (Microsoft's wording)
0x00	Requested a zero-byte pool allocation
0x01, 0x02, 0x04	The pool header has been corrupted
0x06 and 0x07	Attempted to free pool that was already freed
0x08	Attempted to allocate pool at an invalid IRQL
0x09	Attempted to free pool at an invalid IRQL
0x0A	Attempted to free pool memory by using the wrong tag; the memory might belong to another component
0x40	Attempted to free kernel pool at a user-mode address
0x41, 0x44, 0x47	Attempted to free a non-allocated nonpaged pool address
0x42 or 0x43	Attempted to free a virtual address that was never in any pool
0x48 and 0x50	Attempted to free a non-allocated paged pool address
0x99	Attempted to free pool with an invalid address; can also indicate pool header corruption
0x9A	Marked an allocation request MUST_SUCCEED, a pool type no longer supported
0x9B	Attempted to allocate pool with a tag of 0
0x9D	Attempted to allocate pool with a tag that contains no letters or digits

The table in Microsoft's page has more rows than these. Together they show the shape of the code: most values describe freeing something wrongly (already freed, never allocated, wrong tag, wrong IRQL), and a smaller group describes allocating wrongly (zero bytes, MUST_SUCCEED, bad tags). Microsoft adds that the pool type codes are in Ntddk.h, with 0 meaning nonpaged pool and 1 meaning paged pool.

What is the difference between 0xC2 and 0x19?

Both involve the pool, and Microsoft's two pages are written in the same style. Side by side:

Question	0x19 BAD_POOL_HEADER	0xC2 BAD_POOL_CALLER
What Microsoft says it indicates	A pool header is corrupt	The current thread is making a bad pool request
Cause in one sentence	The pool is already corrupted at the time of the current request; may or may not be due to the caller	An invalid pool request, typically at a bad IRQL level or double freeing the same memory allocation
Is the running code the culprit?	Often not, Microsoft says	The thread making the request is the one that violated the rules
Tools Microsoft names	Driver Verifier with Special Pool, Windows Memory Diagnostics	Driver Verifier with memory pool options, Windows Memory Diagnostics

The difference in the third row is the useful one. A 0xC2 points at the thread that made the bad request. A 0x19 points at damage that may have been done earlier by someone else.

What does Microsoft recommend as the resolution?

The Resolution section is two short paragraphs. First: "Activate Driver Verifier with memory pool options enabled, to obtain more information about these errors and to locate the faulting driver." Driver Verifier is the Windows tool that examines driver behaviour in real time, started by typing Verifier at a command prompt. Microsoft warns that it adds overhead and says to verify as few drivers as possible.

Second: "In particular, for situations with memory pool corruption, run the Windows Memory Diagnostics tool, to try and isolate the physical memory as a cause." The steps are the same as on the 0x19 page: type Memory in the control panel search box, select "Diagnose your computer's memory problems," and afterwards read the MemoryDiagnostics-Results entry in the System log.

Why does a tag matter so much?

Several of the values in the table are about pool tags, the short labels that mark which component owns an allocation. Microsoft's table says that freeing with the wrong tag (0x0A) may mean the memory belongs to another component, that a tag of 0 (0x9B) would be untrackable and could corrupt existing tag tables, and that a tag with no letters or digits (0x9D) makes pool issues difficult to track. These are developer rules, and the practical reading for others is that the stop code is usually about a driver breaking bookkeeping rules, not about the amount of memory installed.

What Microsoft tells non-programmers to do

The 0xC2 page contains no separate list for customers. The two actions it names are:

• Run Driver Verifier with the memory pool options enabled, verifying as few drivers as possible.
• For pool corruption, run Windows Memory Diagnostics and read the MemoryDiagnostics-Results entry in the System log.

That is everything the 0xC2 page offers for non-programmers. The parameter table is the part that tells a developer which rule was broken.

Checklist before changing anything

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

How to work through a 0xC2 blue screen

• Copy parameter 1 and match it to the violation table
• Run Driver Verifier with memory pool options on as few drivers as possible
• Run Windows Memory Diagnostics if corruption is suspected
• Read the result under MemoryDiagnostics-Results in the System log

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

Where are the pool types defined, and what is 0x60 about?

Two details sit at the edges of Microsoft's parameter table. The _POOL_TYPE codes are enumerated in *Ntddk.h*, and Microsoft spells out the two that matter when reading a parameter: 0 indicates nonpaged pool and 1 indicates paged pool. So a "pool type" column on the blue screen is a small number, not a word. The other detail is parameter 1 = 0x60, the attempt to free an invalid contiguous memory address. Microsoft adds a parenthetical for that row alone: the caller of MmFreeContiguousMemory is passing a bad pointer. That is the one row of the table that names the function being misused rather than describing the condition.

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

Sources and how to check

• Microsoft Learn, "Bug Check 0xC2: BAD_POOL_CALLER" — https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0xc2--bad-pool-caller. 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.