| Previous | Next |
| ERROR_BADSTARTPOSITION | ERROR_DISK_REPAIR_DISABLED |
ERROR_MEMORY_HARDWARE
the hardware has reported an uncorrectable memory error.
ERROR_MEMORY_HARDWARE means that this condition This code reports a machine-check or platform memory event that Windows could not correct transparently. It points below ordinary application allocation failures: the failing component may be a DIMM, memory channel, processor memory controller, motherboard trace, firmware configuration, or another part of the memory path.
Where the result appears
- Windows Error Reporting or Reliability Monitor records created after a corrected or fatal hardware event.
- system logs generated by WHEA, firmware, or a hardware monitoring service.
- applications that receive an I/O or memory failure after the operating system retires a damaged page.
- diagnostic tools reading the final Win32 status from a failed operation.
What the result tells you
The value identifies a specific Windows state, but it does not by itself identify the component that introduced that state. Preserve the original this result value, the API or subsystem that produced it, and the object being operated on. A wrapper that replaces it with a generic exception or Boolean failure removes the distinction needed to choose the correct recovery path.
Diagnostic evidence to collect
- the WHEA event ID, error source, bank, physical address, and error severity.
- server or workstation model, BIOS/UEFI version, and recent firmware changes.
- DIMM slot population, ECC counters, and vendor hardware diagnostics.
- whether failures recur on the same physical page, channel, or processor socket.
Correlate the result evidence on one timeline. The first event that changes the state associated with this result is usually more valuable than later retries returning the same code. Record process and thread identity, session, timestamp, API parameters, and the immediately preceding successful operation.
Handling and recovery
Treat repeated occurrences as a hardware reliability incident, not as an application retry problem. Preserve volatile diagnostic data, run the vendor memory test, verify seating and supported DIMM combinations, and replace the implicated component when the platform identifies one. A one-off event still deserves correlation with WHEA history because an uncorrectable report can precede a crash or silent service interruption.
Retry after this result only when the evidence shows that an external condition can change. When it is caused by malformed input, revoked authority, unsupported state, hardware damage, or an offline maintenance requirement, an unchanged retry adds noise and can overwrite the earliest useful diagnostics.
Common misinterpretation
Do not confuse this code with ERROR_NOT_ENOUGH_MEMORY. The latter describes unavailable virtual or physical resources; it says the platform reported defective or unreliable memory hardware.
Guidance for developers
Keep it in its Win32/LRESULT domain in structured telemetry. When converting it to an HRESULT, exception, RPC response, or JSON field, retain the source domain and numeric value alongside the human-readable text. Do not branch on the localized message string for this Win32 error.
A test should construct the specific state, assert the exact result, and verify that partial resources are released. The recovery test for this Win32 error should prove that the operation is either deferred until a measurable state change or fails without an uncontrolled retry loop.
References
Looking for a different code? Search another status or error code.