0x800703F1 and 0x80070091: a corrupt registry hive or a folder that will not empty

Fix it now

These are ordinary Windows system error codes wearing an HRESULT prefix. 0x800703F1 is ERROR_BADDB, the configuration registry database is corrupt. 0x80070091 is ERROR_DIR_NOT_EMPTY, the directory is not empty. The first is registry damage; the second is a folder setup could not clear before it rolled back.

sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
chkdsk C: /scan

1. If the code appeared during a feature update, clear the leftovers the supported way: Settings, System, Storage, Temporary files, then remove Previous Windows installation(s) and Windows Setup temporary files.
2. If a folder refuses to go, take ownership and remove it: takeown /f C:\Windows.old /a /r /d y, then icacls C:\Windows.old /grant Administrators:F /t, then rd /s /q C:\Windows.old.
3. If chkdsk C: /scan reports problems, schedule a full pass with chkdsk C: /f /r and reboot.
4. Create a second local administrator account, sign in and retry the update. If it installs there, the original profile is the fault rather than Windows.

Removing the previous installation folder gives up the option of rolling back to the earlier build. If you are still inside the rollback window and might want it, resolve the failure another way first.

If the update now survives the restart, stop here. Below is what the servicing stack is failing to write, and how to tell registry damage from a failing disk.

Why it happens

Applying an update is a transaction. Windows stages the payload into the component store, writes the resulting state into the registry hives that record which components are present at which version, and commits during a restart. If any part of that write fails, the whole transaction rolls back, which is why you see the same code on every attempt rather than gradual progress.

The 0x800703Fx block is that registry write failing, and the last digit says how badly. 0x800703F1 is ERROR_BADDB, the configuration registry database is corrupt. 0x800703F2 is ERROR_BADKEY, the configuration registry key is invalid. 0x800703F7 is ERROR_REGISTRY_CORRUPT, meaning a hive’s structure is damaged. 0x800703F8 is ERROR_REGISTRY_IO_FAILED, an input or output operation initiated by the registry failed unrecoverably, and that last one points at the disk rather than at Windows.

0x80070091 is plainer than its reputation. It is ERROR_DIR_NOT_EMPTY: setup tried to delete a working folder, found something still in it and stopped. The file is usually held open by security software, or the folder contains a reparse point setup refuses to follow. 0x80070001 is ERROR_INVALID_FUNCTION, an incorrect function, which in practice means a driver or device in the path could not carry out the request at all.

Worth saying plainly, because a good deal of advice implies otherwise: none of these codes is specifically about a user profile. A damaged profile can produce update failures, and it is worth testing, but 0x80070091 says a directory was not empty and nothing more than that.

Full reference

The six codes, translated

The pattern is worth internalising because it generalises: an HRESULT of the form 0x8007xxxx carries a Win32 system error code in its low sixteen bits. Convert the last four hex digits to decimal and look the result up in Microsoft’s system error code list, and a code that looked like a servicing mystery turns into a plain statement about a directory, a hive or a device.

Repair command reference

Order of operations, and why it matters

sfc repairs protected files using the component store as its source. If the store itself is damaged, sfc has nothing good to copy from and will report files it could not fix. That is why DISM comes second in the sequence but is often the operation that actually resolves the problem: it repairs the store, after which sfc has something to work with. Running sfc twice is not a strategy.

An in-place repair upgrade rewrites the operating system around your data. It keeps files, applications and activation, but it cannot be reversed once started, and a machine already showing disk errors can fail part-way through and leave you worse off. Take a full backup first, and deal with the disk before the upgrade rather than after.

Telling a machine problem from an update problem

• If one machine in an estate fails and the rest install the same package, it is the machine. Start with chkdsk and DISM.
• If every machine fails on the same package on the same day, pause the deployment and check for known issues before repairing anything.
• Check the System log for disk, controller and filter driver events around the failure time.
• Check whether third-party security software is installed. Its filter driver is the most common reason a folder cannot be emptied.
• Look for reparse points under the setup folders with dir /al before assuming a permissions problem.

Encrypted volumes

If the volume is protected by BitLocker, have the recovery key available before you run a full chkdsk pass or start a repair upgrade. Neither operation is supposed to require it, and being locked out of a machine because the key was in a document on that machine is a bad afternoon that is entirely avoidable.

Every code this article covers

Confirm the fix worked

1. DISM /Online /Cleanup-Image /ScanHealth reports no component store corruption.
2. The update installs and survives the restart rather than rolling back.
3. chkdsk C: /scan completes with no problems found.
4. The previous installation and setup temporary folders are gone, and the System log shows no new disk or configuration errors.

Questions people ask about this