Fixing Microsoft Store error 0x80073cf9 when trying to install or update a specific app
Today I found that Calculator.exe could not open. Since it is now a Microsoft Store app, apparently that is a thing that can happen, rather than the executable just being an innate standalone part of the OS. Moronic design decisions aside, finding a fix for this error online is an exercise in futility, because apparently nobody actually knows what the problem is and just guesses at solutions (e.g. sfc /scannow… sigh).
To save folks some reading if they’re trying to figure out if this blog post is even useful to them, here are the exact symptoms I ran into:
- An app is already installed, or was previously installed and then removed.
- Error 0x80073cf9 is reported when trying to install or update a specific app.
- Other apps can be installed without problems.
- Terminating, repairing, and resetting the app from the app settings did not fix the issue.
- If the app package is installed but won’t open, uninstalling it and attempting to re-install it did not fix the issue.
- Once uninstalled, running
Get-AppXPackage [PackageName]
(e.g.Microsoft.WindowsCalculator
) did not show any results. - Restarting the Windows Update service did not fix the issue.
- Restarting the computer did not fix the issue.
- Renaming the c:directory did not fix the issue.
- Running the Windows Update Troubleshooter did not fix the issue.
- Resetting or repairing the Microsoft Store app did not fix the issue.
- Running
WSReset.exe
as both a normal user and administrator did not fix the issue. - Running any of the random
Get-AppXPackage
Powershell commands mentioned on the internet did not fix the issue. - Running pointless incantations like
sfc /scannow
andDISM /Online /Cleanup-Image /CheckHealth
do not fix the issue (I didn’t even bother trying these). - In Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> WindowsUpdateClient -> Operational, the error “Windows Update failed to download an update” appears.
- In Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> Store -> Operational, error events are logged mentioning HResult error code 0x803f6107.
- In Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> AppXDeployment-Server -> Operational, there are error events pertaining to the attempted install operation.
In my case, those AppXDeployment error events are what led me to the solution. Specifically, the events mentioned the following:
Deployment ResumeOperation operation with target volume C: on Package Microsoft.WindowsCalculator_2020.2103.8.0_neutral_~_8wekyb3d8bbwe from: (fafa61aa6f4543aa9b045ab5a90713ab8f901caa) failed with error 0x800704C8. See http://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app deployment issues.
AppX Deployment operation failed for package Microsoft.WindowsCalculator_2020.2103.8.0_neutral_~_8wekyb3d8bbwe with error 0x80073CF9. The specific error text for this failure is: error 0x800704C8: Creating file ?:Files.WindowsCalculator_10.2103.8.0_x64__8wekyb3d8bbwe.pri failed.
error 0x800704C8: Creating file ?:Files.WindowsCalculator_10.2103.8.0_x64__8wekyb3d8bbwe.pri failed.
The relevant event IDs in that log were 401, 404, and 462.
These indicate that the installer was failing to create a particular file inside the install directory. Since, in my case, the app was uninstalled, nothing should be preventing the file from being created. This made no sense.
(side note: if the AppXDeployment event logs mention a different problem, the fix described below may not apply to you. use your best judgement.)
The C:\Program Files\WindowsApps\
directory is protected from being accessed by normal users, and even administrators have restricted rights. This is an important security control - you should not take ownership of the directory. One downside of this security control is that you cannot browse to this directory in Explorer. Instead, start a command prompt as an administrator (Start -> Run -> cmd.exe
, hold ctrl+shift and press enter), then type cd "C:\Program Files\WindowsApps"
, then type dir
. A list of directories will be printed. Check through this list to see if the broken app is there. In my case there were four directories for the Windows Calculator app:

Since the app had been uninstalled, it made no sense for these directories to be present. They need to be removed.
Administrators do not have the rights to delete, move, or create directories in this directory. To get around this, use psexec to launch a command prompt as the SYSTEM user: psexec -s -i cmd.exe
(side note: some anti-malware products alert on psexec because it is commonly used by attackers who have compromised a system. in this case, you can safely ignore this alert. psexec is a legitimate tool written by Microsoft; it just happens to be useful to malicious people too)
This will launch a new command prompt. You can type whoami
to double check that you’re running as SYSTEM. From here, cd
back into the directory, then make a backup directory and move the offending directories into it:
cd "C:\Program Files\WindowsApps"
mkdir _bak
move Microsoft.WindowsCalculator_10_... _bak
move Microsoft.WindowsCalculator_10_... _bak
move Microsoft.WindowsCalculator_10_... _bak
move Microsoft.WindowsCalculator_2020_... _bak
If you’re unfamiliar with the command prompt, you can just hit tab after typing some of the file name to autocomplete, and press it again to cycle through autocomplete results.
After doing this, the Calculator app installed just fine.
As for why this happened in the first place, I’m not 100% sure. The specific file it was failing on was a PRI file, which is used for package resource indexing in UWP apps, so maybe that’s relevant, but it could just be a total coincidence.
If anyone from Microsoft wants to investigate this, I’m on Windows 10 Pro for Workstations (21H2 19044.1348 / WFEP 120.2212.3920.0), and I can provide event log dumps and other ETLs. You can reach me via Twitter via Mastodon (DMs are open).