0x0000013A KERNEL_MODE_HEAP_CORRUPTION
The kernel heap manager validates its structures as it uses them. When it finds one damaged it stops rather than continue allocating from a heap it can no longer trust. What makes this code useful is the precision of parameter 1: Microsoft documents around twenty values, and they distinguish a buffer overrun from an underrun from a use-after-free from a double free. That is a far sharper starting point than most stop codes give you.
What you are looking at
Your PC ran into a problem and needs to restart.
Stop code: KERNEL_MODE_HEAP_CORRUPTION
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: 0x0000013a (0x0000000000000006, 0xffffa50c1d2e0000, 0xffffa50c1e4b2100, 0x0000000000000000).What the error actually means
Kernel components allocate memory from heaps, and each allocation carries a header describing its size and state. Those headers sit next to the data they describe, which is efficient and also fragile - a driver writing one byte past the end of its buffer damages the header of whatever comes next.
The heap manager checks these headers on every operation. When it finds one that does not make sense, it stops the machine, because a heap whose bookkeeping is wrong will hand out overlapping allocations and corrupt unrelated data.
As with the other integrity checks, the detection point is not the damage point. A driver overruns its buffer, and the crash happens later when something else touches the damaged neighbour. The value of parameter 1 is that it describes the shape of the damage, which narrows what kind of mistake was made even when it cannot say who made it.
Reading the parameters
Parameter 2 is the heap that reported the problem, parameter 3 is where the corruption was found, and parameter 4 is reserved. Parameter 1 is the interesting one - these are the values that appear most.
| Parameter | What it holds |
|---|---|
| 0x6 | Corruption with features consistent with a buffer overrun. A driver wrote past the end of its allocation. One of the most common values, and exactly what Driver Verifier's Special Pool is built to catch. |
| 0x7 | Corruption with features consistent with a buffer underrun - a write before the start of an allocation. Rarer than an overrun and usually a pointer arithmetic error. |
| 0xB | Features consistent with using a block after freeing it. A classic use-after-free. |
| 0x3 / 0x4 / 0x5 | A corrupt entry header was detected - one, several, or one in a large allocation respectively. Generic header damage without a more specific signature. |
| 0xD | A corrupt free list. Microsoft notes this can result from a use-after-free or from a buffer overflow of an adjacent block. |
| 0xE | List corruption in a list other than the free list. |
| 0x11 | Invalid internal state, which Microsoft says can result from a double free or from heap corruption. |
| 0x12 | Invalid internal state consistent with a use-after-free or a buffer overflow of an adjacent block. |
| 0x17 | A block was corrupted in a delay free list - likely a use-after-free or an overflow of an adjacent block. |
| 0x8 / 0xF | An operation valid only for busy blocks was performed on a free block, or an operation illegal on a free block was attempted. Both indicate a driver losing track of what it has released. |
| 0x13 | A NULL heap handle was passed to the heap API. Microsoft's advice is to look at the call stack to see why a bad handle was supplied. |
| 0x14 / 0x15 | An allocation exceeded the current allocation limit, or a commit request would exceed the commit limit. Resource exhaustion rather than corruption. |
What actually triggers it
Almost always a driver mishandling memory. The subtype tells you which mistake, not which driver.
| Cause | How often | Detail |
|---|---|---|
| A third-party driver with a memory bug | Common | The direct cause in most cases. Buffer overruns and use-after-frees in drivers that were not tested rigorously. Anti-virus filters, VPN clients, peripheral utilities and virtual device software are the recurring names. |
| Anti-virus and security software | Common | These allocate and free heavily while inspecting file and network activity. A version mismatch after a Windows update produces heap corruption reliably. |
| Failing RAM | Occasional | A flipped bit in a heap header looks exactly like a driver overrun to the heap manager. The check fires correctly; the damage came from hardware. |
| Unstable memory settings | Occasional | An XMP or EXPO profile beyond what the memory controller sustains produces the same signature as failing modules, intermittently. |
| Graphics drivers | Occasional | Large, complex, and constantly allocating. Worth a clean reinstall if the dumps point that way. |
Narrowing it down
Record the subtype first, then establish whether you are chasing a driver or chasing memory.
Record parameter 1 across several crashes
Pull the full parameter set from the bugcheck events:
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1001} |
Where-Object { $_.Message -match '0x0000013a' } |
Select-Object TimeCreated, Message |
Format-ListA consistent subtype - always 0x6, say - is one driver making the same mistake repeatedly, and Verifier will find it. Subtypes that vary between crashes suggest general memory corruption rather than a specific bug.
Check whether the named module is stable
Open several dumps and compare MODULE_NAME from !analyze -v. Microsoft also documents the !heap extension for this bugcheck, which displays heap usage information and can search for and validate heap blocks.
The same module every time points at that driver. Different modules each time is the corruption signature, and driver work will not help.
Test memory before a long driver hunt
Disable XMP or EXPO and run MemTest86 from USB for at least four passes.
A clean run at stock lets you pursue drivers confidently. Errors end the investigation immediately and save you days of Verifier runs.
Fixes, cheapest first
Driver Verifier is the right tool here for the same reason it is on the pool bugchecks - it converts a delayed detection into an immediate one.
Remove third-party security software
Given how often filter drivers are involved, uninstall third-party anti-virus first and run on Windows Defender for a few days. Use the vendor's dedicated removal tool - these products routinely leave kernel drivers behind that the standard uninstaller misses.
Run Driver Verifier with Special Pool
Special Pool arranges allocations so that an overrun or a use-after-free faults at the moment it happens rather than when something else notices the damage. For subtypes
0x6,0x7,0xB,0x11and0x12this is precisely the right instrument.Full instructions, including the Safe Mode escape route, are in the Driver Verifier guide.
Watch outVerifier deliberately increases crashes and can cause a boot loop. Run
verifier /bootmode resetonbootfailbefore 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 byverifier /reset. Full settings and the escape route are in the Driver Verifier guide.Update or remove the named driver
If dumps consistently name one module, install the vendor's current version, or the previous release if the crashes started after an update. If it belongs to software you do not use, uninstall it - the simplest fix for a buggy driver is not having it.
Return memory to stock and test it
Disable XMP, EXPO and any manual tuning. Run MemTest86 for at least four passes. If the modules are clean at stock but fail with the profile enabled, the profile is the problem rather than the memory.
Verify system files
Quick to eliminate. Run
sfc /scannow, thenDISM /Online /Cleanup-Image /RestoreHealth, thensfc /scannowagain.
When it is the hardware, not Windows
Signals that memory rather than a driver is corrupting the heap:
- Parameter 1 varies between crashes rather than staying consistent.
- The named module differs each time.
- MemTest86 reports errors at stock settings.
- Other corruption-flavoured stop codes appear too -
0x1A,0x139,0xC2. - Driver Verifier runs for days without implicating anything.
- The machine is running an overclock, undervolt or memory profile.
The Verifier result carries real weight here. It is aggressive and it is specifically designed to catch the exact mistakes this bugcheck describes. If it runs across every non-Microsoft driver for several days and never fires, that is meaningful evidence that no driver is at fault - and attention should move to memory and the machine's stability settings.
Frequently asked
What is the difference between this and BAD_POOL_CALLER?
Different allocators. 0xC2 concerns the kernel pool - the nonpaged and paged pools drivers usually allocate from - and fires when a caller makes an invalid request. 0x13A concerns kernel-mode heaps and fires when the heap manager finds its structures already damaged. In practice they overlap heavily, both usually mean a driver mishandling memory, and the troubleshooting converges on Driver Verifier followed by memory testing.
Parameter 1 is 0x6. What am I actually looking for?
A buffer overrun - some driver wrote past the end of an allocation it owned, damaging the header of the block after it. You are not looking for the driver named in the dump, which is usually the one that later touched the damaged block. Special Pool in Driver Verifier is designed for exactly this: it positions each allocation so that writing past the end faults immediately, naming the driver that actually overran rather than the one that noticed.
Why does this seem more common on Windows 10 and 11 than it used to be?
Partly because the checks got stricter. Newer kernels validate heap structures more aggressively and in more places, so corruption that previously caused a vague crash somewhere unrelated now gets caught and named. That is an improvement even though it feels like a regression - the corruption was happening before, it was just surfacing as something harder to diagnose.
Can I keep using the machine while I diagnose this?
With a caveat. The bugcheck exists to prevent corrupted heap structures being used, so Windows is stopping before damage spreads - it is not silently mangling your files. But if the underlying cause is failing memory, other things are being corrupted too, some of which get written to disk. Back up important data before a long diagnostic process, and be more careful than usual about trusting anything the machine wrote around the time of a crash.
Related errors
- 0x000000C2BAD_POOL_CALLERA driver misused kernel memory allocation. Verifier with pool options finds it reliably.
- 0x00000139KERNEL_SECURITY_CHECK_FAILUREA kernel integrity check caught corruption and halted deliberately. Parameter 1 says which kind.
- 0x0000001AMEMORY_MANAGEMENTWindows' memory bookkeeping is corrupt. The first parameter tells you which kind, and that changes everything.