0x00000120: What It Means and How to Fix It in Windows

For stop code 0x00000120, I start by checking what changed before the crash: a recent driver or BIOS update points to a driver fault, random reboots under load point to memory or storage, and repeated boot-time crashes after file issues point to corruption. My first move is to record the crash time, then check Event Viewer and any dump file before changing hardware or reinstalling anything.

0x00000120: what the stop code means

0x00000120 is BITLOCKER_FATAL_ERROR in Windows bug check terms (per Microsoft support). A bug check is the numeric code shown on the blue screen to classify the crash, but it is not the full diagnosis by itself. (Microsoft Learn)

That matters because the same stop code can still come from different paths: a bad kernel module, unstable RAM, storage errors, or a system-file problem that surfaces while BitLocker, boot, or resume code is running.

One oddity in search results: unrelated cryptography pages also use 0x00000120 in non-Windows contexts. Xoodoo is described as a set of cryptographic permutations; the round function works on 12 words of 32 bits; it is used at the core of Xoodyak and Xoofff; the number of rounds is a parameter called nr; and RC[-7] is listed with a hexadecimal value. Those facts are unrelated to a Windows blue screen.

What this code can and cannot tell you yet

It tells you that Windows hit a fatal path tied to BitLocker or a related low-level condition. It does not tell you whether the root cause is a driver, disk, RAM, firmware, or corruption event.

That is why crash timing, recent changes, and dump files matter more than guessing from the code alone.

According to Keccak Team — RC[-7] is listed as 0x00000120.

What 0x00000120 usually points to

Most often, this kind of crash tracks back to a driver or kernel module change. Less commonly, it follows memory instability, storage faults, or update and firmware conflicts that affect the boot or encryption path.

Driver or kernel module issues

Recent installs, unsigned drivers, outdated storage or chipset drivers, GPU utilities, VPN clients, and vendor overlays can all sit in the path before the crash. If the system started failing right after one of those changed, treat that as the first branch.

Memory faults and unstable RAM behavior

Intermittent crashes, especially under load, after waking from sleep, or during encryption-heavy tasks, can point to flaky RAM or unstable memory settings. A single pass may miss it.

Storage problems and file corruption

Bad sectors, failing SSD firmware, or file-system errors can trigger repeat blue screens if Windows cannot read the files it needs during boot or resume. Crashes that cluster around startup or disk-heavy activity belong here.

Update, firmware, or compatibility conflicts

A Windows update can expose a driver mismatch, and BIOS or chipset changes can do the same. If the crash appeared right after an update, do not guess; match the timing against Event Viewer and the update history first.

How do I narrow the cause in minutes?

Use a short checklist and write down each result. The goal is to separate driver, RAM, storage, and corruption paths fast enough that you do not chase all four at once.

1. Record the exact stop code shown on the blue screen.
2. Write down the crash time and whether it happened at boot, on sign-in, under load, or after sleep.
3. Note the last change: driver, BIOS, Windows update, VPN, storage tool, or encryption change.
4. Check whether Windows saved a dump file in C:\Windows\Minidump or C:\Windows\MEMORY.DMP.
5. Boot Safe Mode and see whether the same crash repeats.
6. Mark the result of each step before trying the next fix.

Decision checklist to isolate the fault in under 15 minutes

What logs and dump files should I check?

Start with the System log in Event Viewer, then open any dump file in WinDbg. That gives you the crash timestamp, the BugCheck entry, and the module or parameter clues that often separate a bad driver from a hardware or storage fault.

Find minidump and full dump locations

Check C:\Windows\Minidump for minidumps and C:\Windows\MEMORY.DMP for a full dump. Minidumps are quicker to collect and often enough for driver triage; a full dump is larger and usually gives more context.

Read BugCheck entries in Event Viewer

Open Event Viewer > Windows Logs > System and look for BugCheck entries around the crash time. Also check kernel crash timestamps and any disk, driver, or BitLocker events that happened a minute or two before the blue screen.

Open the dump in WinDbg

Use WinDbg, the Microsoft debugger, to open the dump with symbols. The bugcheck parameters and the stack trace can point to a module name, a driver class, or a storage path worth testing next.

Match bugcheck parameters to the failing module

If WinDbg names a kernel module or driver, treat that as the lead. If it points into storage or encryption code, the next checks should be disk health, BitLocker state, and recent firmware or chipset changes.

Fix driver and kernel module causes first

Because driver faults are the most common software path, start here if the crash followed an install, update, or new device utility. Work from rollback to clean boot, not the other way around.

1. Open Device Manager, find the recently changed device, and choose Properties > Driver > Roll Back Driver if available.
2. If rollback is unavailable, use Uninstall device, then restart and let Windows reload the basic driver.
3. Install the current driver from the device maker, not a random updater.
4. Remove vendor utilities, overlays, VPN clients, and storage tools added before the crash.
5. Run a clean boot: press Win + R, type msconfig, open Services, hide Microsoft services, disable the rest, then restart.

What to do after a driver rollback fails

If the crash returns after rollback, uninstall the device software completely, restart, and test again. If a system service or filter driver is involved, clean boot is the faster isolation step than chasing random app settings.

Could RAM or storage be causing the crash?

Yes. If Safe Mode still crashes, if the machine fails under load, or if the blue screen appears during boot or resume, move to RAM and disk checks before assuming corruption alone.

1. Open Windows Memory Diagnostic and run the standard restart test.
2. If errors repeat, use a MemTest-style check overnight and test one stick at a time if possible.
3. Open an elevated Command Prompt and run chkdsk /f on the system drive.
4. Run sfc /scannow to repair system files.
5. If SFC finds issues it cannot fix, run DISM /Online /Cleanup-Image /RestoreHealth, then rerun SFC. (Microsoft Support)

How to read the pattern

RAM problems often show up as random behavior, different stop codes, or crashes that move around after each reboot. Storage problems usually cluster around boot, resume, or file-access work. Corruption tends to show up after updates or failed shutdowns.

Can Safe Mode help fix a 0x00000120 BSOD?

Yes. Safe Mode removes most third-party drivers and startup items, so it helps separate a software fault from a deeper hardware or firmware issue. If Safe Mode is stable, the problem is usually in the loaded driver stack or a startup service.

Use Safe Mode to separate software from hardware

Boot into Safe Mode and watch for the same crash pattern. If the system stays up, focus on drivers, vendor software, and clean boot. If it still crashes, move harder toward RAM, storage, BIOS, or firmware.

1. Go to Settings > System > Recovery > Advanced startup and restart into recovery.
2. Choose Startup Settings, then Safe Mode.
3. Test the same action that caused the blue screen.
4. If Safe Mode is stable, return to normal boot and use msconfig for a clean boot.
5. Check for recent BIOS, chipset, or storage firmware changes if the crash still happens.

If Safe Mode still crashes

That is a stronger sign of a hardware, firmware, or low-level disk issue. At that point, dump analysis, memory tests, and storage checks matter more than software cleanup.

What should I do after a 0x00000120 crash?

After the first crash, protect the evidence. Do not jump straight to resets. Capture the stop code, the time, the last change, and whether a dump file exists so you can keep the failure path narrow.

1. Photograph the blue screen or write down the stop code exactly.
2. Open Event Viewer and note the matching BugCheck entry.
3. Copy any file from C:\Windows\Minidump.
4. Document the most recent driver, BIOS, VPN, or Windows update.
5. Only after that, test rollback, Safe Mode, or disk and memory checks.

Prevention: keep a restore point before driver, chipset, BIOS, and VPN changes so you have a quick rollback target if the crash returns.

Still not working?

If Safe Mode, dump files, Event Viewer, and basic repairs still do not isolate the fault, move to a repair install only after the evidence points away from a single driver. If the machine still blue screens after that, the next step is hardware testing or vendor support.

1. Run the memory test again with one RAM stick installed at a time.
2. Check SSD health with the vendor tool if available, then rerun chkdsk.
3. Undo the most recent BIOS or firmware update if the timing matches.
4. Use Reset This PC only after dumps and logs fail to narrow the cause and file backup is complete.
5. Escalate to the device maker if crashes repeat on a clean install path.

Frequently asked questions

What does 0x00000120 mean on Windows?

It is the BITLOCKER_FATAL_ERROR bug check. Use Event Viewer and any dump file to tell whether the crash comes from a driver, storage path, memory instability, or a corrupted system component.

How do I find the exact cause of a stop code in Windows?

Check C:\Windows\Minidump, open Event Viewer > Windows Logs > System, and analyze the dump in WinDbg with symbols. Match the crash time to the BugCheck entry and note the driver or module named in the stack.

Is 0x00000120 a driver, disk, or memory problem?

It can be any of the three. Start with recent driver and software changes, then move to Windows Memory Diagnostic and chkdsk if Safe Mode is still unstable or the crash happens during boot, resume, or heavy disk use.

Can Safe Mode help fix a 0x00000120 BSOD?

Yes. If Safe Mode is stable, disable third-party startup items with msconfig and roll back the last driver or utility that changed. If Safe Mode also crashes, move toward RAM, storage, BIOS, and firmware testing instead.

What logs should I check for bugcheck 0x00000120?

Check the System log in Event Viewer for BugCheck entries, plus any driver, disk, or BitLocker events near the crash time. Pair that with the minidump or full dump in WinDbg to see the failing module or parameter pattern.

Does 0x00000120 mean hardware failure?

Not always. It can come from software, firmware, or hardware. If the crash repeats in Safe Mode and after driver rollback, then memory and storage testing become the stronger next step before any repair install or replacement decision.