0x00000109 CRITICAL_STRUCTURE_CORRUPTION
On 64-bit Windows, patching the kernel is not allowed. A protection mechanism periodically verifies that critical kernel code and data structures are unmodified, and when it finds one that has been changed it stops the machine immediately. That check cannot distinguish a driver deliberately patching the kernel from a memory fault flipping a bit in it - which is why this stop code has two completely different explanations.
What you are looking at
Your PC ran into a problem and needs to restart.
Stop code: CRITICAL_STRUCTURE_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: 0x00000109 (0xa3a01f58f4a1b2c3, 0xb3b72be3f5c2d1e4, 0xfffff8036c1a5180, 0x0000000000000004).What the error actually means
Historically, security software and rootkits alike worked by patching the kernel - hooking system service tables, modifying dispatch routines, rewriting function prologues. It was effective and it made the operating system impossible to secure or to keep stable.
From Windows Server 2003 SP1 onward on x64, Microsoft prohibited it. The kernel may only be patched through authorised Microsoft-originated hot patches. A protection mechanism periodically checks that critical structures still match what they should be, and bugchecks if they do not.
So this stop code means something changed kernel code or data that had no business changing. Microsoft documents three causes: a driver modifying critical kernel code or data, a developer setting a kernel breakpoint without a debugger attached at boot, or hardware corruption - memory that failed while holding kernel code.
For an ordinary user, that reduces to two: software that patches the kernel, or bad RAM.
Reading the parameters
Unusually, parameters 1 to 3 are all reserved. Everything is in parameter 4, which names the structure that was found modified. Around thirty-five values are documented; these are the ones worth recognising.
| Parameter | What it holds |
|---|---|
| 4 = 0x0 or 0x20 | A generic data region. The least specific values and the hardest to act on. |
| 4 = 0x1 | A function modification - kernel code itself was altered. Strongly suggests something patching the kernel rather than a random bit flip. |
| 4 = 0x2 | A processor interrupt dispatch table (IDT). Classic hooking target. |
| 4 = 0x3 | A processor global descriptor table (GDT). |
| 4 = 0x4, 0x5, 0x1A, 0x1B | Process list corruption, types 1 through 4. Frequently seen and often memory-related. |
| 4 = 0x7 | A critical MSR modification - a model-specific register was changed. Overclocking and tuning utilities write MSRs, which makes this one worth noting if the machine is tuned. |
| 4 = 0xA | Modification of a system service function - the historic hooking technique that PatchGuard was built to stop. |
| 4 = 0xD or 0xE | Modification of an import table, or of a session import table. Another classic hooking approach. |
| 4 = 0x19 | Loaded module list modification. |
| 4 = 0x21 or 0x22 | A page hash mismatch. The contents of a page no longer match its expected hash - which is exactly what a memory fault produces, and a strong pointer toward hardware. |
| 4 = 0x27, 0x28, 0x29, 0x101 | Pool corruption, types 1 to 3 and general. Overlaps with the territory of BAD_POOL_HEADER. |
| 4 = 0x102 | Modification of win32k.sys - the graphics and window management kernel component. |
What actually triggers it
Two broad families, and parameter 4 helps tell them apart.
| Cause | How often | Detail |
|---|---|---|
| Anti-cheat and game protection software | Common | Kernel-level anti-cheat operates in exactly the territory this protection guards. Conflicts between two anti-cheat drivers, or between anti-cheat and a Windows update, produce this reliably. If the crashes cluster around launching a particular game, this is where to look. |
| Third-party security software | Common | Older or poorly maintained anti-virus products still attempt kernel hooking, and some virtualisation-based security tools sit close enough to trigger it. |
| Failing RAM | Common | Microsoft names hardware corruption directly - kernel code or data stored in memory that failed. A bit flip in a protected region is indistinguishable from deliberate modification. Page hash mismatch values are particularly suggestive of this. |
| Unstable overclock, undervolt or memory profile | Occasional | Corruption in transit rather than in storage, with the same result. Tuning utilities also write MSRs directly, which can trigger the critical MSR modification value on its own. |
| Cheating and modification tools | Occasional | Worth stating plainly since it is a genuine cause: software designed to modify a running game or the kernel is doing precisely what this mechanism exists to stop. So are some older driver-patching utilities and unsigned driver loaders. |
| Rootkits | Rare | The original reason the protection exists. Rare on a modern, patched system, but a scan is reasonable diligence given what the stop code describes. |
Narrowing it down
Parameter 4 and timing between them narrow this quickly.
Read parameter 4
Take it from the bugcheck event or from !analyze -v. It is the only parameter carrying information.
Values describing modification of code, functions, import tables or system service functions point at software patching the kernel. Values describing corruption - page hash mismatches, process list corruption, pool corruption - are more consistent with memory faults. It is a tendency rather than a rule, but it is the best signal available.
Check what the crashes correlate with
Note whether they cluster around launching a specific game, starting particular software, or happen with no pattern at all.
A tight correlation with one application - especially a game with kernel anti-cheat - identifies the cause without further work. No pattern at all leans toward hardware.
Inventory what runs at kernel level
List third-party kernel drivers currently loaded:
Get-CimInstance Win32_SystemDriver |
Where-Object { $_.State -eq 'Running' -and $_.PathName -notmatch 'system32\\(drivers\\)?[a-z]+\.sys' } |
Select-Object Name, PathName |
Sort-Object Name |
Format-Table -AutoSizeAlso check Get-Service for anti-cheat services - EasyAntiCheat, BattlEye, Vanguard and similar.
Two kernel-level anti-cheat systems installed simultaneously is a recognised source of conflict. So is anti-cheat alongside aggressive third-party anti-virus.
Test memory before concluding it is software
Disable XMP or EXPO and run MemTest86 from USB for at least four passes.
Microsoft lists hardware corruption as one of only three causes, so this is not a formality. Errors end the investigation. A clean run at stock lets you pursue the software angle with confidence.
Fixes, cheapest first
Which comes first depends on whether parameter 4 and the timing point at software or hardware.
Remove or update anti-cheat software
If the crashes correlate with a game, uninstall its anti-cheat component and reinstall it fresh - these ship as separate installable services and can be repaired independently of the game.
- Check Programs and Features for EasyAntiCheat, BattlEye, Vanguard and similar entries.
- Uninstall the one belonging to the game that triggers the crashes.
- Reinstall it from the game's own installation folder, or verify the game files through its launcher.
- If two different anti-cheat systems are installed, remove the one for a game you are not currently playing.
Remove third-party security software
Uninstall third-party anti-virus using the vendor's dedicated removal tool and run on Windows Defender for a few days. Older products that still hook kernel structures are a direct cause here.
Test and stabilise memory
Disable XMP or EXPO, then run MemTest86 from USB for at least four passes. If errors appear, test each module individually in the same slot. See the memory testing guide.
Return the machine to stock
Clear any CPU overclock, undervolt, curve optimiser offset and memory profile. Also uninstall tuning utilities rather than just disabling them - Ryzen Master, Intel XTU, ThrottleStop and vendor overclocking software write MSRs directly, which can trigger the critical MSR modification value by itself.
Remove kernel-patching utilities
Uninstall anything that loads unsigned drivers, patches system files, or modifies running processes - including older system tweaking utilities, driver signature enforcement bypasses, and game modification tools. These do exactly what this protection exists to prevent.
Verify system files and scan for malware
Run
sfc /scannow, thenDISM /Online /Cleanup-Image /RestoreHealth, thensfc /scannowagain. Follow with a Microsoft Defender Offline scan, which runs before Windows loads and can see things a normal scan cannot.Given that the mechanism exists to catch kernel modification, a scan is proportionate diligence rather than paranoia - though a driver conflict remains far more likely than a rootkit.
When it is the hardware, not Windows
Signals that memory rather than software is modifying the protected structures:
- Parameter 4 indicates a page hash mismatch (
0x21or0x22). - MemTest86 reports errors at stock settings.
- The crashes have no correlation with any application or activity.
- Parameter 4 differs between crashes rather than staying consistent.
- Other corruption codes appear alongside -
0x1A,0x19,0x139. - Crashes continue after removing all third-party kernel software.
The last one is close to decisive. If every anti-cheat, security product and tuning utility has been removed, the machine is at stock settings, and it still reports critical structures modified, then nothing in software is doing the modifying. At that point memory is the remaining explanation and it should test as such.
Frequently asked
Does this mean I have a rootkit?
Almost certainly not, despite what the mechanism was built for. In practice the overwhelming majority of these come from legitimate kernel-level software - anti-cheat and security products - or from failing memory. Run an offline scan as reasonable diligence, but do not let the alarming framing send you down that path first. Check what kernel software is installed and test the RAM.
It only happens when I play one specific game. Is the game at fault?
The game's anti-cheat driver is the likely trigger, though not necessarily the thing that is broken. Anti-cheat operates in exactly the territory this protection guards, and conflicts arise between two anti-cheat systems, or between anti-cheat and third-party anti-virus, or after a Windows update changes something underneath. Reinstalling the anti-cheat component and removing any other kernel-level security software usually resolves it.
Why is parameter 4 the only useful one?
Because the protection mechanism deliberately reveals little about itself. Parameters 1 to 3 are documented as reserved. If it published exactly what it checks and where, that information would be immediately useful to anyone trying to evade it - so the bugcheck reports the category of structure that failed verification and nothing more.
Can I disable the protection so it stops crashing?
No, and the methods that claim to are worse than the problem - they generally involve disabling driver signature enforcement or running in test signing mode, which removes protections and does not stop whatever is modifying the kernel. The bugcheck is not the fault; it is the detection. Something is genuinely altering critical kernel structures, and the answer is to find out what.
Related errors
- 0x00000019BAD_POOL_HEADERA pool header was corrupt. The blamed driver is usually the one next door.
- 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.