0x80070643 is not a Windows Update error

0x80070643 shows up in Windows Update, in Configuration Manager, and in Intune, usually attached to a .NET Framework update or a security update, and usually with no other detail. Searching the code returns a wall of pages telling you to run the Windows Update troubleshooter and reset the SoftwareDistribution folder. Sometimes that works. Most of the time it does not, because the failure is not in Windows Update at all.

Read the code instead of searching it

An HRESULT is three pieces of information packed into eight hex digits: a severity bit, a facility, and a code. Split 0x80070643 apart:

• 0x8 means the high bit is set, so this is a failure rather than a success or informational result.
• 007 is the facility. Facility 7 is FACILITY_WIN32, which means what follows is an ordinary Win32 error code that has been wrapped so it can travel as an HRESULT.
• 0643 is the code itself, in hexadecimal. In decimal that is 1603.

Windows Installer error 1603 is A fatal error occurred during installation. So 0x80070643 is not a Windows Update problem that happens to involve an installer. It is an installer failure that Windows Update is reporting on the installer's behalf.

Which log actually has the cause

Because the real failure is an installer failure, the Windows Update log will tell you that something failed and nothing about why. Two logs are worth your time instead.

For a Windows update

Open the newest CBS log and find the failure by timestamp:

Get-Content C:\Windows\Logs\CBS\CBS.log -Tail 400 |
    Select-String -Pattern ', error' -Context 0,3

You are looking for the line that names a file, a registry key, or a component. That object is the actual problem. The error code told you the category. The log tells you the target.

For an application or a .NET installer

Run the installer by hand with verbose logging and read the log:

msiexec /i package.msi /l*v C:\Windows\Temp\install.log /qn

Then search the log for Return value 3. Windows Installer writes that after the action that failed, so the line immediately above it names the action that broke. This is the single most useful search string in MSI troubleshooting, and it is why getting a verbose log matters more than any other step.

The three cases that account for most of them

1. A .NET Framework update failing on a damaged component store

The most common source of 0x80070643 in Windows Update. Repair the component store, then retry:

Dism.exe /Online /Cleanup-Image /RestoreHealth
Sfc.exe /Scannow

Restart the device afterwards, then let the update run again. If DISM cannot find its source, supply matching media with /Source: and remember that the media build must match the device build.

2. The installer cannot write where it needs to

A deployment running as SYSTEM does not have the same view of the file system as you do when you test the same package while signed in. A path in a user profile does not exist, a mapped drive is not there, and a folder that you can write to may be denied to the machine account. The verbose log names the path. Check that path in the context the install actually runs in.

3. A custom action inside the package fails

The MSI runs, one of its custom actions returns a failure, and Windows Installer rolls the whole thing back and reports 1603. Nothing about the Windows environment is wrong. The verbose log will name the action. From there it is a packaging question for whoever built the MSI, and it usually comes down to the action needing a user context that a silent machine-context deployment does not provide.

What not to do

• Do not reset SoftwareDistribution as step one. It fixes download and scan problems, and this is neither.
• Do not re-run the same deployment hoping for a different result. 1603 is not transient the way 1618 is.
• Do not report the device as a Windows Update failure without opening a log. The code is a category, not a diagnosis.

Code definitions checked against Microsoft's Windows Installer error code reference.

Back to the decoder