AppX/MSIX deployment consistently fails at Indexed stage (0x80073CF9 / 0x87AF0813) on Win11 Insider Dev 29648 after packages were previously provisioned on a secondary-drive AppX volume

Neno X 0 Reputation points
2026-08-23T09:02:27.0666667+00:00

Environment

Windows 11 Pro Insider Preview, Build 29648 (Dev Channel), x64

Not domain joined, not MDM managed, local admin account

System locale zh-CN

Symptom

Installing a specific Store-signed MSIX (OpenAI.Codex, PFN OpenAI.Codex_2p2nqsd0c76g0)

fails consistently regardless of channel:

  • Microsoft Store UI → 0x80073CF9, later 0x80073CF6 during Register
  • Direct Add-AppxPackage of the signed MSIX → same failure at Register stage
  • After StateRepository cleanup attempts → failure moved EARLIER, to the Indexed stage
  • winget --source msstore → reports success but installs a different product
  • Add-AppxProvisionedPackage (DISM) → error 1168

Error chain (AppXDeploymentServer/Operational):

  • Event 404/401: deployment fails, error 0x80073CF9, internal error 0x87AF0813, "Failed to reach state Indexed", "Indexed state handler failed"
  • Earlier variant before cleanup: Register stage fails 0x80073CF6, internal 0x800700B7, windows.stateExtension: "Cannot create a file when that file already exists"
  • Rollback: 0x800703FA "Illegal operation attempted on a registry key that has been marked for deletion"
  • Event 330: windows.MRT extension registration fails 0x80070002
  • Event 5282: "Create secure system app data folder failed" 0x800700B7
  • Event 468: "Cannot set access permissions for <PFN>" 0x80070002

Context that appears relevant

This machine previously had Settings > System > Storage > "Where new content is saved"

New apps will save to: D:. An AppX volume existed at D:\WindowsApps with per-user

state under D:\WpSystem<SID>. Multiple package deployments were attempted against that

volume and rolled back, leaving:

  1. Orphaned package folders + a junction from C:\Program Files\WindowsApps<pkg> pointing into D:\WindowsApps<pkg>
  2. Stale rows in the StateRepository threads/package tables still binding the family to AppDataVolume=2 (D:)
  3. Remove-AppxVolume on D:\WindowsApps fails 0x80073D0C "volume is not empty" even though Get-AppxPackage -AllUsers shows ZERO packages with InstallLocation on D: (only the system-managed Deleted\ and MutableBackup\ subfolders remain)

The default volume has since been switched back to C:\Program Files\WindowsApps

(verified via Get-AppxDefaultVolume), and new installs of OTHER Store apps succeed

normally. Only this package family fails, always at the same stage.

Already attempted (all unsuccessful)

  • wsreset.exe, Store re-registration, DISM /RestoreHealth, sfc /scannow
  • In-place repair install of Windows (kept files/apps)
  • Removing stale StateRepository rows (threads/package/packageidentity/ packagelocation/packageuser) referencing the affected family
  • Removing orphaned package folders and junctions from C:\Program Files\WindowsApps and D:\WindowsApps
  • Deleting per-user HKCU AppModel\SystemAppData key for the PFN (recreated on each failed attempt, left in marked-for-deletion state)
  • Setting current-user default AppX volume explicitly to the system volume
  • Installing all pending Windows Updates, then retrying
  • Web installer bootstrapper: same failure
  • Reinstalling the CLI/app after rebooting: same failure

DISM /Cleanup-Image /CheckHealth and RestoreHealth report no component store damage.

sfc /scannow found no integrity violations.

Questions

  1. Is there a SUPPORTED procedure to reset or rebuild the current-user AppX registration state (StateRepository / stateExtension) for a specific package family, short of reinstalling Windows or creating a new user profile?
  2. Is the Indexed-state-handler failure (0x87AF0813) on Insider Dev build 29648 a known regression?
  3. How should a dangling AppxVolume (registered, zero packages, Remove-AppxVolume returns 0x80073D0C "volume is not empty", physical folders emptied but shells undeletable due to ACL) be correctly removed?

Any guidance appreciated. Happy to supply CBS logs, AppXDeployment ETL traces, or

StateRepository dumps on request.

Windows Insider program | Apps on Insider preview
0 comments

2 answers

Sort by: Newest
Most helpful Newest Oldest
  1. Deleted

    This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

    Comments have been turned off. Learn more

  2. Kai-H 26,385 Reputation points Microsoft External Staff Moderator
    2026-08-24T09:06:42.69+00:00

    Hi, Neno X

    The failure appears tied to damaged package-family metadata and the former D: AppX volume, rather than the Store, package signature, or Windows component store. The Indexed/stateExtension errors also indicate that further manual StateRepository or registry edits may make rollback state worse.

    There is no documented, supported command to rebuild StateRepository or stateExtension for only one package family. Reset-AppxPackage applies only to an installed package and does not rebuild deployment metadata. Avoid deleting database rows, PackageVolumes registry keys, or protected WindowsApps folders manually. The supported boundaries are package removal/re-registration, testing another Windows profile, or resetting/reinstalling Windows.

    I could not verify 0x87AF0813 as a published known issue for Dev build 29648. Because this is an Insider build, submit the problem through Feedback Hub under Apps > App installation, attach the AppXDeploymentServer events and ETL trace, then test a newer Dev build if offered. Also test the same MSIX in a temporary local profile. If it installs there, that confirms profile-specific deployment state rather than a package defect.

    Remove-AppxVolume is supported only after no packages remain staged on that volume for any user. Zero packages with an InstallLocation on D: does not necessarily prove that staging metadata is empty. Check both Get-AppxPackage -AllUsers and Get-AppxProvisionedPackage -Online, remove any entries still referencing that volume through supported cmdlets, reboot, then pass the volume object from Get-AppxVolume to Remove-AppxVolume. If 0x80073D0C remains, do not force-delete its ACL-protected folders. At that point, a clean Windows installation is the supported recovery path.

    Thank you for your patience in reading, I hope this information has been helpful to you. 

    If the answer is helpful, please click "Yes" and kindly upvote it. If you have extra questions about this answer, please click "Comment."    

    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    Was this answer helpful?

    1 person found this answer helpful.

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.