REGISTRY_ERROR 0x00000051 and BAD_SYSTEM_CONFIG_INFO 0x00000074 at startup

Fix it now

Windows could not work with one of its registry hives. Two of the codes here are not hive damage at all: 0x00000073 and 0x00000075 are resource failures, usually a full system drive or exhausted pool, with the hive intact. Check free space before you replace anything.

diskpart
list volume
exit
dir X:\
chkdsk X: /f /r

1. Boot Windows Recovery Environment from installation media or a recovery drive: Repair your computer, then Troubleshoot, then Advanced options, then Command Prompt.
2. Find the Windows volume with diskpart and list volume. In the recovery environment it is rarely C:.
3. Read the bytes free from dir X:\. A system drive with almost nothing left is the whole answer for 0x00000073, and no hive needs replacing.
4. Try System Restore from the same Advanced options menu next. It restores the hives along with everything else and is the safest route by a wide margin.
5. Only if there is no usable restore point, look at X:\Windows\System32\config\RegBack. Files of 0 KB there mean the periodic backup is off, which is the default from Windows 10 version 1803 onwards.

Copy the existing hives to another folder before overwriting anything, and do it with Windows offline. Replacing a hive replaces the machine’s configuration wholesale.

If the machine boots and stays up, you are done. If not, the next section separates the three quite different failures these codes describe.

Why it happens

The registry is not one object. It is a set of files in the Windows configuration folder, of which SYSTEM matters most at boot because it holds the service and driver configuration the kernel reads before anything else runs. Each hive has a transaction log beside it, so a write interrupted part way through can be replayed or rolled back at the next start. That design survives most interruptions, which is why an unclean shutdown usually costs nothing worse than a slow boot. What it does not survive is the file itself becoming unreadable, or the machine running out of something the configuration manager needs – and those are two different failures that these codes tell apart.

0x00000051, REGISTRY_ERROR, is Microsoft’s severe registry error. The documented causes are an I/O error while reading one of the registry’s files, hardware problems or file system corruption, and a failed refresh operation used only by the security system when resource limits are reached. 0x00000074, BAD_SYSTEM_CONFIG_INFO, means there is an error in the registry: the SYSTEM hive is corrupt, which Microsoft calls unlikely because the boot loader checks hives as it loads them, or critical keys and values are missing because someone edited the registry by hand or an application damaged it. Parameter 4 carries an NT status worth looking up.

The other two are the ones that get misdiagnosed. 0x00000073, CONFIG_LIST_FAILED, means one of the core system hives could not be linked into the registry tree – and Microsoft states plainly that the hive is valid, because it loaded successfully. Parameter 2 says why linking failed, and the two common values are 0xC000017D, STATUS_NO_LOG_SPACE, meaning the system drive is out of disk space, and 0xC000009A, STATUS_INSUFFICIENT_RESOURCES, meaning a pool allocation failed. 0x00000075, CANNOT_WRITE_CONFIGURATION, means the SYSTEM hive file could not be converted to a mapped file, and typically occurs when the system is out of pool.

Full reference

What each code is actually saying

Three of those five point somewhere other than a damaged hive. If you take nothing else from this article, take that: 0x73 and 0x75 are resource failures with the hive intact, and replacing a hive to fix them is work that cannot help.

Turning the periodic hive backup back on

Windows stopped backing the registry up to RegBack in Windows 10 version 1803, to reduce the disk footprint. The folder is still there and the files in it are 0 KB. Microsoft’s recommendation is to use system restore points instead, because a restore point includes registry information. If you want the old behaviour on machines that matter, one value brings it back.

It lives under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Configuration Manager, and the machine has to be restarted for it to take effect. Set it before the incident, not during one.

Replacing hives by hand, if it comes to that

Work out the Windows volume letter first and keep the originals before you overwrite anything. Substitute the letter the recovery environment reported for X throughout.

diskpart
  list volume
  exit
X:
cd \Windows\System32\config
md configbak
copy *.* configbak\
copy RegBack\*.* .

Restore hives as a matched set from the same point in time. A SYSTEM hive from one date beside a SOFTWARE hive from another produces its own class of failures, and they are harder to diagnose than the one you started with because nothing on screen says the two disagree.

When the machine boots but the fault returns

• Run sfc /scannow and then DISM /Online /Cleanup-Image /RestoreHealth to repair anything inconsistent that the restore left behind.
• Check the System log for entries from the configuration manager naming a specific hive or key.
• Confirm the system volume is not filling again. This is the single most common repeat cause and the easiest to monitor.
• Run a memory diagnostic if the damage returns on a disk that tests clean. Bad memory writes bad data, and the disk is only where it lands.
• Create a restore point manually once the machine is stable, so the next incident has somewhere to go back to.

Every code this article covers

Confirm the fix worked

1. Start the machine from cold twice and confirm it reaches the desktop without a repair prompt.
2. chkdsk C: /scan reports the volume clean.
3. sfc /scannow reports no integrity violations.
4. The system volume has meaningful free space, and something is watching it.
5. A manually created restore point exists, so the next incident has a known good point to return to.

Questions people ask about this