0x80073CF9: MSIX or Appx Install Failed – Read the Deployment Log First

Fix it now

Microsoft publishes 0x80073CF9 as ERROR_INSTALL_FAILED, “Package install failed”, and that is the whole of it. It is a wrapper, not a diagnosis. The useful information is the inner error recorded in the deployment log, which names the package, file or state that actually stopped the install.

Add-AppxPackage -Path .\package.msix
Get-AppxLog
Get-AppxLog | Out-GridView
Get-Service AppXSvc,ClipSVC,StateRepository

1. Retry the install, then read the log for that attempt straight away. Get-AppxLog prints the entries for the most recent deployment operation; piping it to Out-GridView makes a long one readable.
2. The same entries are in Event Viewer under Applications and Services Logs, Microsoft, Windows, AppXDeploymentServer, Operational, if you would rather read them there.
3. Find the inner error and the package name in the result entry. Work from that code, not from 0x80073CF9.
4. If the inner error names a framework package, supply the dependencies in the same operation: Add-AppxPackage -Path .\package.msix -DependencyPath .\dep1.appx,.\dep2.appx.

Searching for 0x80073CF9 on its own produces a mass of unrelated advice, because every person writing it up had a different inner error. Get the inner one first.

If the package installs you are done. If the inner error points somewhere you do not recognise, the next section maps the documented ones onto what to do.

Why it happens

Deploying a packaged application is a multi-stage operation. The package is opened and validated, its signature is checked, its dependencies are resolved, the payload is staged into the package repository, and a registration is written for the user. Each stage fails for its own reasons and raises its own error internally.

What surfaces at the top is usually the generic install failure. Installers, the App Installer application, management tools and deployment scripts all tend to show 0x80073CF9 rather than the inner code, because the inner code was produced several layers down. That is why advice for this code is so scattered: every writer was actually fixing something else.

Microsoft documents the inner codes, and they are specific. 0x80073CF0 is ERROR_INSTALL_OPEN_PACKAGE_FAILED, and its documented causes are worth reading carefully: the package is not signed, the publisher name in the manifest does not match the signing certificate’s subject, or the path was given without the file:// prefix. That is a very different investigation from a damaged download. 0x80073CF1 is the package not being found, 0x80073CF2 is package data that is invalid, 0x80073CF3 is a dependency or conflict validation failure, and 0x80073CF6 is a package that cannot be registered.

0x87AF0813 turns up in the same conversations and has no published meaning at all – no Microsoft documentation page defines it. Treat it exactly as you treat 0x80073CF9: read the deployment log entry that carries it and work from what the operation was doing.

Full reference

The documented deployment errors

0x80073CF0 and 0x8007000B both point at the signing relationship, and between them they account for a large share of sideloading failures on packages that were built in-house. The rule to remember is that the Publisher string in the manifest and the Subject of the signing certificate must be identical, not merely similar.

Where the log lives

Deployment commands

Why a package installs on one machine and not another

• Which framework packages are already present, and in which architectures.
• What is already registered for that user, and whether an older version is blocking the new one.
• Whether the signing certificate is trusted on the device.
• Whether deployment policy on the device permits what you are doing.
• Whether the package repository and the component store underneath are healthy.
• Compare those five things between the working machine and the failing one before anything else.

Codes without a published meaning

0x87AF0813 has no Microsoft documentation behind it. It appears in reports of Store and App Installer failures and nowhere in the vendor’s own error tables. When you meet a code like that, the productive move is to stop treating it as a lookup problem: find the log entry that carries it, read what operation was in flight, and diagnose that. The same discipline applies to 0x80073CF9 itself, which does have a published meaning and still tells you nothing useful on its own.

Every code this article covers

Confirm the fix worked

1. Run Get-AppxPackage -Name <PackageName> and confirm the package is listed with the version you intended.
2. Launch the application from Start and confirm it opens.
3. Re-read the AppXDeploymentServer Operational log and confirm the latest entry records success rather than a new inner error.
4. Sign in as a second user, if the package was provisioned, and confirm it appears for them too.
5. Run Get-Service AppXSvc,ClipSVC,StateRepository once more and confirm all three are running.

Questions people ask about this