0x0000009C MACHINE_CHECK_EXCEPTION
The processor's own error detection found a fault it could not recover from. On Windows Vista and later this was largely replaced by bugcheck 0x124 - so if you are seeing 0x9C on a current system, that itself is a clue. Microsoft documents exactly two circumstances in which it still fires, and they point in different directions.
What you are looking at
Your PC ran into a problem and needs to restart.
Stop code: MACHINE_CHECK_EXCEPTION
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: 0x0000009c (0x0000000000000004, 0xfffff8036c1a5180, 0x00000000be000000, 0x0000000000800400).What the error actually means
Processors carry error detection throughout - caches are parity-protected, buses are checked, memory paths are validated. When one of those mechanisms finds an uncorrectable fault it raises a machine check exception, a hardware interrupt saying the processor has detected something it cannot fix.
Historically Windows reported that as bugcheck 0x9C. From Vista onward, the Windows Hardware Error Architecture takes over and reports the same class of fault as bugcheck 0x124, with richer information attached.
Microsoft documents 0x9C as still occurring in only two circumstances: when WHEA is not fully initialised, or when all processors that rendezvous have no errors in their registers. Everything else goes to 0x124.
That is unusually useful. The first case means the fault happened very early - before WHEA came up during boot. The second means a machine check fired, the processors synchronised to report it, and none of them actually had error information to give. Both are narrow conditions, and knowing which one you are in genuinely narrows the diagnosis.
Reading the parameters
The parameters differ by processor architecture. On any modern x64 machine the second table applies.
| Parameter | What it holds |
|---|---|
| 1 (modern x64 / MCA) | The bank number - which machine check bank reported the error. Different banks correspond to different parts of the processor, so a consistent bank number across crashes indicates a consistent subsystem. |
| 2 | The address of the MCA_EXCEPTION structure describing the fault. |
| 3 | The high 32 bits of the MCi_STATUS register for the machine check bank that had the error. |
| 4 | The low 32 bits of the same MCi_STATUS register. Together with parameter 3 this encodes what the processor recorded about the fault, though decoding it requires the vendor's architecture documentation. |
| Older x86 (MCE without MCA) | On old Pentium-class hardware the layout differs: parameter 1 is the low 32 bits of the P5_MC_TYPE register, parameter 2 the MCA_EXCEPTION address, and parameters 3 and 4 the high and low halves of P5_MC_ADDR. You are unlikely to meet this. |
What actually triggers it
Hardware, the same territory as 0x124. The ordering reflects what actually resolves cases.
| Cause | How often | Detail |
|---|---|---|
| Unstable overclock, undervolt or memory profile | Common | The leading cause on any tuned machine, and free to eliminate. Includes XMP and EXPO, Precision Boost Overdrive, curve optimiser offsets and undervolts - all of them, not just deliberate frequency overclocks. |
| Thermal problems | Common | A cooler that has come loose, dried thermal paste, blocked airflow or a failed fan. Check temperatures under load before suspecting a defective part. |
| Power delivery | Occasional | An ageing or overloaded supply, or board VRMs that cannot hold voltage under transient load. Produces machine checks when a core momentarily loses adequate voltage. |
| Failing memory | Occasional | Uncorrectable memory errors surface through the machine check path. Testable, and worth testing. |
| Firmware and microcode | Occasional | Microcode updates delivered through UEFI have fixed machine check errors on specific processor steppings. Check the board vendor's changelog before concluding a part is defective. |
| A failing processor or motherboard | Occasional | Where the diagnosis lands when settings are stock, temperatures are fine, and the power supply is good. |
Narrowing it down
Start by working out which of the two documented circumstances you are in, because it changes what to look at.
Note when in the boot process it happens
Does it crash during startup, before you reach the desktop? Or during normal use after Windows has been running?
A crash very early in boot fits the first documented circumstance - WHEA not yet initialised - and points at a fault present from power-on: memory that fails immediately, an unstable profile applied by firmware, or marginal voltage at boot. A crash during normal use fits the second circumstance, where no processor had error data to report, which is a stranger and often more marginal condition.
Return everything to stock
Load optimised defaults in UEFI, then verify individually: XMP and EXPO off, no CPU multiplier or voltage offset, PBO and curve optimiser disabled, no undervolt. Check Windows too - vendor utilities can reapply an undervolt at startup independently of firmware.
If the crashes stop, the hardware is fine and the settings were not achievable on your particular silicon. This resolves a large share of cases and costs nothing but a little performance.
Record the bank number
Parameter 1 on a modern system is the machine check bank that reported the error. Note it across several crashes.
A consistent bank number means a consistent subsystem is failing, which is a coherent fault worth documenting for a warranty conversation. Varying bank numbers suggest something system-wide - power delivery or thermals rather than one defective unit.
Check for WHEA entries and 0x124 crashes
Filter the System log for WHEA-Logger, and check whether any 0x124 crashes appear alongside:
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'} |
Group-Object Id | Sort-Object Count -Descending |
Format-Table Name, Count -AutoSizeA mix of 0x9C and 0x124 on the same machine is the same underlying hardware fault reported through two paths depending on how far along the boot was and what the processors could report. Treat them as one problem, and use the 0x124 dumps for diagnosis since !errrec works on those.
Fixes, cheapest first
Effectively identical to 0x124, because it is the same class of fault.
Clear all overclocking and tuning
Load optimised defaults, then confirm each item separately since defaults do not always clear everything.
- Disable XMP, EXPO and any manual memory timings.
- Clear any CPU multiplier, voltage offset or adaptive voltage setting.
- Disable Precision Boost Overdrive and curve optimiser offsets.
- Uninstall vendor tuning software - Ryzen Master, Intel XTU, ThrottleStop - rather than just disabling it.
- Run at stock for several days before drawing conclusions.
Watch outAn overclock stable for years can stop being stable. Silicon ages, and the voltage a core needs for a given frequency drifts upward over time - so a long track record is not a reason to leave the setting untested.
Fix cooling
Clear dust from heatsinks, radiators and filters. Confirm every fan spins. Check the case genuinely exhausts air rather than only drawing it in.
On a machine more than a few years old, or one where temperatures climb unusually fast under load, reseating the cooler with fresh paste is cheap and frequently effective.
Update firmware
Check the board vendor's changelog for anything mentioning microcode, stability or AGESA. Microcode updates through UEFI have genuinely resolved machine check errors on particular steppings.
Watch outIf the drive is protected by BitLocker or Device Encryption, a firmware update can change TPM measurements and trigger a recovery-key prompt on the next boot. Check with
manage-bde -statusand save your key from account.microsoft.com/devices/recoverykey first - Windows 11 enables Device Encryption by default on much consumer hardware.Run the update on mains power and do not interrupt it.
Test memory at stock
With profiles disabled, run MemTest86 from USB for at least four passes. See the memory testing guide - and note that testing with a profile enabled conflates a defective module with an over-ambitious setting.
Rule out the power supply
Borrow a known-good supply with adequate headroom and run on it for a week if you can. As a cheaper diagnostic, cap CPU power limits in firmware - if the crashes stop at reduced power, the fault is in delivery rather than in the processor.
When it is the hardware, not Windows
This code starts from hardware, so the question is which part:
- Crashes continue at completely stock settings with good temperatures.
- The bank number in parameter 1 is consistent across crashes.
WHEA-Loggerentries or 0x124 crashes appear in the same period.- A clean Windows install makes no difference.
- 0x101 CLOCK_WATCHDOG_TIMEOUT crashes appear too.
- The failure rate is increasing week over week.
Once stock settings, cooling and power are eliminated, this is a component replacement rather than a repair. Keep the dumps and export the WHEA history first - the combination of machine check exceptions, WHEA records and an increasing rate is about as strong as consumer-level hardware evidence gets, and it survives a vendor diagnostic coming back clean.
Frequently asked
Why am I getting 0x9C instead of 0x124?
Microsoft documents two circumstances. Either WHEA was not fully initialised when the fault occurred - which means it happened very early in boot, before that subsystem came up - or all the processors that rendezvoused to report the error had no errors in their registers. Everything else is reported as 0x124 on Vista and later. If your crash happens during startup, the first explanation is likely. If it happens during normal use, the second is, and that is the more unusual case.
What does 'no errors in their registers' actually mean?
A machine check exception fired, the processors synchronised to report what happened, and when Windows read their machine check registers none of them held error information. So a fault was signalled but nothing could be attributed to it. That tends to accompany genuinely marginal conditions - voltage dips, transient electrical problems - rather than a cleanly failed component, which is part of why the overclocking and power supply checks matter so much on this code.
Can I decode parameters 3 and 4 myself?
In principle - they are the two halves of the MCi_STATUS register, and Intel and AMD publish the bit layouts in their architecture manuals. In practice it is heavy going for limited benefit. If you can get a 0x124 dump from the same machine, !errrec on its parameter 2 gives you the reporting component in plain language, which is the same information without the decoding.
My overclock has been stable for years. Why now?
Silicon ages. Electromigration gradually shifts the voltage a processor needs to hold a given frequency, so a setting with adequate margin when new can fall below it years later. The overclock did not change; the part did. It is one of the most common patterns behind machine check errors, and it is why returning to stock is worth doing even when the settings have a long history.
Related errors
- 0x00000124WHEA_UNCORRECTABLE_ERRORThe hardware reported a fatal error directly. The most hardware-specific stop code there is.
- 0x00000101CLOCK_WATCHDOG_TIMEOUTOne CPU core stopped answering. Overclocks and undervolts cause most of these.
- WHEA-Logger 17A corrected hardware error has occurredHardware reported an error and recovered. One is noise. A burst of them is a warning.