How do I investigate ECC or hardware memory errors on a dedicated server?
ECC-capable platforms can report corrected and uncorrected memory errors through firmware, kernel drivers or management-controller logs. A corrected event and an uncorrected event have different implications, and a count alone does not identify a replaceable DIMM reliably. Correlate repeated events, timestamps and the vendor’s slot mapping before requesting hardware work.
Before you start
- Authorised access to the dedicated server and the named inspection tools.
Instructions
1. Read kernel error evidence
Check the time window in which the symptom occurred. Message wording and available error reporting depend on the processor, kernel and platform driver.
sudo journalctl -k --since "24 hours ago" --no-pager | grep -Ei "EDAC|MCE|Hardware Error"Record the exact event, correction state and any bank/channel identifiers. No matching line is not proof that the hardware has never reported an error.
2. Compare management-controller events
Where local IPMI access is supported, read the system event log without clearing it. Management-controller time may differ from the OS clock.
sudo ipmitool -I open sel elistCross-check the sensor or slot identity against the manufacturer’s service documentation. Do not reset counters before support has reviewed them.
Check the result
- The incident report identifies recurrence, severity and a verified component mapping, with vendor guidance determining whether replacement is required.
Troubleshooting
- A log mentions a channel rather than one DIMM
- Some memory modes cannot localise every fault to one module. Use the platform’s supported diagnostics and slot mapping.
- The OS has no EDAC data
- Firmware or BMC reporting may still exist; confirm the platform’s supported telemetry path.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.