0X00000310

ERROR_MCA_EXCEPTION (0x00000310) — Machine Check Fix, Step by Step

A machine check exception (MCA) is a CPU-level hardware fault. Here's how to find the bad component and stop the reboots.

You're staring at a blue screen or a kernel log full of MCA_EXCEPTION chatter, and the machine just rebooted on its own. Maybe it happened while compiling, maybe it happened at 3 AM on a server doing nothing. The error code is 0x00000310. That's not a Windows bug. That's not a driver. That's your CPU telling the operating system "I detected a hardware fault and I'm stopping before data corruption spreads."

MCA stands for Machine Check Architecture. Intel introduced it with the Pentium Pro, AMD has an equivalent, and every modern x86 chip uses it. When the CPU's built-in self-check circuits catch a parity error in cache, a bus failure, or an uncorrectable memory error, they fire an MCA exception. On Windows you see a BSOD with WHEA_UNCORRECTABLE_ERROR. On Linux you get a kernel panic or a line in dmesg that looks like Machine check: CPU 0: Corrected error. In a hypervisor log you might see it as an MCE injection error.

The real fix is never "reinstall Windows." It's figuring out which piece of silicon is lying to you. Let's do that in three passes.

Step 1 — The 30-second check: stop overclocking

If you've touched your BIOS, this is almost certainly your problem. Unstable memory profiles, aggressive PBO curves, and manual voltage bumps all cause MCA exceptions under load. AMD Ryzen 7000 series is notorious for it — a memory kit rated for 6000 MT/s on a 7950X can trigger WHEA errors that show up as 0x00000310 in the crash dump.

  1. Reboot and hammer Delete or F2 to enter BIOS/UEFI.
  2. Find Load Optimized Defaults (ASUS calls it "Load Optimized Defaults," MSI calls it "Load Defaults," Gigabyte hides it under Save & Exit).
  3. Save and exit. After the reboot you should see the memory training screen flash and then boot normally.
  4. Run whatever workload triggered the crash. If it survives an hour, you found it.

If the only thing you changed was XMP/EXPO (the memory overclock profile), you can try re-enabling it at a lower speed. Drop from 6000 to 5600 MT/s on Ryzen, or from DDR5-6400 to 6000 on Intel 13th/14th gen. That alone fixes a huge percentage of consumer MCA errors.

One note: on servers, "stop overclocking" doesn't apply. Skip to Step 3 if this is a rack unit, VM host, or cloud instance.

Step 2 — The 5-minute check: read the actual dump

If you're not overclocking, you need to know what the CPU complained about. A raw 0x00000310 tells you nothing. The bank and status registers do.

On Windows

Open Event Viewer (eventvwr.msc) and look at:

  • Windows Logs → System — filter for Source: Microsoft-Windows-WHEA-Logger
  • Look for Event ID 18 (corrected hardware error) or Event ID 1 (uncorrectable)

Click the event, hit the Details tab, and find these fields:

ErrorSource: 3 (Generic Machine Check Exception)
Bank: 5
ApicId: 0
MciStatus: 0xbe00000000800400

The MciStatus value tells you which subsystem failed. Top 16 bits 0xbe00 means an uncorrectable error. If the low bits point to a cache bank (bank 1-4 on most Intel, bank 0-3 on AMD) it's the CPU itself. If they point to a memory controller bank, it's RAM or the motherboard trace.

On Linux

Run these two commands after a crash:

sudo dmesg | grep -i -E 'mce|machine check'
sudo ras-mc-ctl --errors

You want to see the bank number and the MCI_STATUS. If you see Corrected error repeatedly on the same bank, that component is on its way out. If you see Uncorrected once and the machine rebooted, that's a hard fault.

On macOS

Check /Library/Logs/DiagnosticReports for a .panic file. Search for Machine Check or MCA. Apple Silicon doesn't use the same MCA registers, so 0x00000310 on an M-series Mac is extremely rare — if you're seeing it, you're probably in a VM.

Step 3 — The 15-minute fix: isolate the faulty hardware

Now you know it's real. Time to find the part. Do these in order — they go from cheapest to worst.

3a. Test the RAM first (because it's usually the RAM)

Uncorrectable memory errors are the number one cause of MCA exceptions in systems that aren't overclocked. Run MemTest86 from a USB stick for at least two full passes — overnight is better. A single error is a failure; there's no "mostly stable."

For ECC memory on servers, run edac-util -v and check the CE (corrected error) and UE (uncorrectable error) counts per DIMM. A DIMM with rising CE counts is dying. Replace it before it starts producing UEs that take the whole box down.

3b. Reseat and clean

Pull every DIMM, blow out the slots with compressed air, and reseat them firmly until both clips click. Also pull the CPU cooler, clean off the old paste, and reapply. I've seen a slightly loose cooler mount cause thermal-related MCA errors on Xeon systems because one corner of the IHS was running 8°C hotter than the others. Not common, but it happens.

3c. Check thermals and power

Use HWiNFO64 on Windows or sensors on Linux. Watch:

  • CPU package temp under load (anything sustained over 95°C is trouble)
  • VRM temperatures if your board reports them
  • 12V rail voltage — dips below 11.4V under load mean a failing PSU

A cheap PSU that worked fine for two years can sag under a new GPU load and start producing MCA errors that look random. If you added hardware recently and the crashes started, suspect the power supply.

3d. Update BIOS and microcode

Intel and AMD both push microcode fixes that address errata causing spurious machine checks. Intel's 13th/14th gen instability saga in 2024 was handled partly through microcode updates — if you're on an affected chip, check your motherboard vendor's support page for the 0x12B or newer microcode revision. On Linux, install intel-microcode or amd64-microcode and reboot:

sudo apt install intel-microcode
sudo update-initramfs -u
sudo reboot

Then verify with grep microcode /proc/cpuinfo. The revision value should match what the vendor published.

3e. Swap parts if you have spares

This is where it gets expensive. In order of likelihood for a persistent MCA error with no obvious cause:

ComponentLikelihoodHow to confirm
RAM / XMP profileHighMemTest86, single-DIMM boot
PSUMediumSwap for a known-good unit
CPULow but realSwap into a known-good board
Motherboard (VRM, traces)LowSwap CPU + RAM into a new board

If you're under warranty on a 13th or 14th gen Intel chip and you've done all the BIOS/microcode updates and still get WHEA errors, RMA the CPU. Intel extended warranties for the affected batches, and they're replacing chips without much argument.

When to stop and what to expect

If after Step 1 your crashes are gone, you're done. If Step 2 shows corrected errors only, and they're not increasing, you can often keep running — corrected errors are the CPU's way of saying "I fixed it, but keep an eye on me." If Step 3 finds a bad DIMM or a sagging PSU, replace it and re-test for a week before you trust the machine with anything important.

One thing I want to be clear about: MCA errors don't get better on their own, and they never lie. If a CPU says it detected an uncorrectable error, it did. Your job is just to figure out which component fed it the bad data.

Related Errors in Programming & Dev Tools
ModuleNotFoundError: No module named 'pip' Fix 'No module named pip' After Python Upgrade curl 92 Fix Git RPC failed: curl 92 HTTP/2 PROTOCOL_ERROR on push java.lang.OutOfMemoryError: Java heap space Fixing Java OutOfMemoryError: Java heap space Uncaught TypeError: Cannot read properties of undefined (reading 'map') React TypeError: Cannot read 'map' of undefined — The Real Fix

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.