0x80073CFB: The Package Is Already Installed or Cannot Be Downgraded

Fix it now

The deployment engine found something already registered under the same package identity and refused to overwrite it. Microsoft documents two ways out: raise the version and rebuild, or remove the existing registration for every user on the machine first.

Get-AppxPackage -Name <PackageName> -AllUsers | Select-Object Name,Version,PackageFullName
Remove-AppxPackage -Package <PackageFullName> -AllUsers
Get-AppxProvisionedPackage -Online
Remove-AppxProvisionedPackage -Online -PackageName <PackageName_from_that_list>
Add-AppxPackage -Path .\package.msix -ForceApplicationShutdown

1. Read the version column before you remove anything. If it already matches what you are deploying, 0x80073CFB is telling you the install is done and there is nothing to fix.
2. Close the application first, including any tray or background component. 0x80073D02 is the same refusal reported because resources the package modifies are still in use.
3. Remove the provisioned copy as well, or the package returns for the next new profile and the identity stays occupied.
4. If you must go back to an older build deliberately, use Add-AppxPackage -Path .\package.msix -ForceUpdateFromAnyVersion instead of the plain install.

-AllUsers works off the parent package type and needs administrator permissions. For a bundle, find it with Get-AppxPackage -PackageTypeFilter Bundle first, or the removal will miss it.

If the install now completes you are done. If it comes back with the same code, the next section covers the case Microsoft documents and most people miss.

Why it happens

A packaged application is identified by the name and publisher declared in its manifest plus its architecture, not by the file you double-clicked. Before anything is staged, the engine reads that identity, looks for an existing registration under it, and compares versions. Nothing matching means a normal install. Something matching at a lower version means an update. Something matching at the same or a higher version stops the operation.

The part that catches in-house packagers is narrower than “the same version is installed”. Microsoft’s own wording for 0x80073CFB is that you may get this error if you are installing a package that is not bitwise identical to the one already installed – and it adds that the digital signature is part of the package, so a rebuild or a re-sign is enough to make the two differ. Two builds that both say 1.0.0.0 in the manifest are not the same package, and the engine will not quietly replace one with the other.

The other half of the picture is that staging is machine-wide while registration is per user, and a provisioned package is a third thing again. A package can be absent from your own Start menu, still registered for a colleague who shares the machine, and still provisioned so it installs for every profile created from now on. That is why a removal that looked complete from your session leaves the identity occupied.

Full reference

The cmdlets this work is done with

-PreserveApplicationData is not a general way to keep user data across a reinstall. Microsoft documents it as applicable only to apps under development that were registered from a loose file layout, so on a normal signed package it is not the parameter you want.

Reading the failure properly

When Add-AppxPackage or Remove-AppxPackage fail they return an ActivityID, and that ID is what Get-AppxLog takes. Run Get-AppxLog immediately after the failure and you get the record for that attempt rather than a guess. The same material is in Event Viewer under Applications and Services Logs, Microsoft, Windows, AppXDeployment-Server, in the Operational channel; the packaging-side channel Microsoft points at separately is AppxPackaging, under Microsoft-Windows-AppxPackaging/Operational.

Read the code from that log rather than from whatever wrapper ran the install. A deployment tool will frequently surface a single generic failure for all five of the codes in this article, and they need four different responses.

Getting a clean slate on a machine that will not let go

1. Query with -AllUsers and note every PackageFullName returned, including resource and framework entries that share the family name.
2. Remove the registrations, then remove the provisioned entry, in that order.
3. Sign out and back in. Registration state is per user and some of it is only released when the profile is unloaded.
4. Re-query with -AllUsers and confirm nothing comes back before installing again.
5. If a stale entry survives all of that, deploy the new build with -ForceUpdateFromAnyVersion, which stages regardless of what version is recorded.

In a deployment pipeline

• Increment the version on every build. It is the cheaper of Microsoft’s two remedies and it removes this class of failure entirely.
• Treat a re-sign as a new package. If your signing step runs after versioning, two artefacts with the same version number will still collide.
• Do not rely on uninstalling through Settings. That removes the current user’s registration and leaves both other users’ registrations and the provisioned copy in place.
• If you deploy to shared or multi-session machines, always test the removal path with a second signed-in profile. That is where the identity conflict actually lives.

Every code this article covers

Confirm the fix worked

1. Get-AppxPackage -Name <name> -AllUsers returns the version you intended to deploy, and only that version.
2. Get-AppxProvisionedPackage -Online no longer lists the old build.
3. The application launches for a second profile on the same machine, not just for you.
4. Get-AppxLog for the install shows the deployment completing rather than a retry.

Questions people ask about this