| Previous | Next |
| ERROR_INVALID_DEVICE_OBJECT_PARAMETER | ERROR_DRIVER_DATABASE_ERROR |
ERROR_MCA_OCCURED
What ERROR_MCA_OCCURED means
Windows uses this status when the hardware error architecture reports a machine-check condition. It points below the application layer: CPU, memory, interconnect, firmware, power delivery, or another platform component detected a fault that software could not treat as an ordinary I/O error.
Where it appears
- WHEA records written to the System event log
- unexpected reboot, bug check, or service interruption under load
- hardware diagnostics, firmware validation, or virtualization hosts surfacing a guest-visible machine check
Likely causes
- uncorrectable memory or cache errors
- CPU, motherboard, PCIe, or power instability
- outdated BIOS or microcode
- thermal events or aggressive overclocking
Evidence to collect
- WHEA-Logger event IDs and the complete event XML
- bug-check code and dump, if a crash occurred
- hardware model, BIOS version, CPU microcode, and recent component changes
- temperature, power, memory-test, and vendor diagnostic results
How to respond
Do not hide repeated events with retries. Return the system to supported clocks, update firmware, reseat or test replaceable hardware, and correlate the first WHEA record with the affected bank or device. Escalate persistent uncorrectable reports to the hardware vendor.
Diagnostic interpretation
For this particular status, the decisive evidence is WHEA-Logger event IDs and the complete event XML, bug-check code and dump, if a crash occurred. Those details separate the documented condition from unrelated failures that happen to occur nearby.
Record the numeric code together with the symbolic name ERROR_MCA_OCCURED, the API or subsystem that produced it, and the first preceding failure. A later cleanup occurrence may describe a consequence instead of the initiating defect.
Example
A diagnostic trace records this result after an operation changes subsystem state. The result investigation should follow the first state-changing call, validate its resulting state, and classify later cleanup messages as secondary evidence.
Implementation guidance
Code handling this result should distinguish a terminal failure from a warning, progress indication, or request to repeat after a defined state change. When handling it, preserve handles and output fields only where the originating API explicitly keeps them valid. The path needs bounded retries and cleanup that tolerates partial initialization.
Validation after remediation
Repeat one controlled operation that previously produced this result. Verify both disappearance of the status and completion of the specific state transition described above. Adjacent messages around it must also be reviewed so a fallback is not mistaken for a complete repair.
References
Looking for a different code? Search another status or error code.