Your Windows app auto-updated and now it won't open: what 0x80073D02 means

A Windows app you recently updated unexpectedly quit and no longer works. The desktop icon remains unresponsive, and there's no sign of the app under Apps in Task Manager. The only indication is an error dialog mentioning an error code: 0x80073D02. If you've encountered similar issues with Claude Desktop, Codex, or any app that is delivered as an MSIX package, this guide explains what went wrong and how to resolve it.

An MSIX update initiates a package swap, not a patch. When the update process updates the app, Windows stages the new files, adds the package, and registers it for your user account. However, if something from the old version is still running, the deployment service returns 0x80073D02, indicating that the package's resources are currently in use. This failure occurs at the end of an update that previously seemed to proceed without issues.

The problem arises because the update process only covers the processes belonging to the package, not the helpers that the app launched and carry no package identity. For example, Claude Desktop creates additional processes such as a bundled CLI, node.exe processes from MCP servers, native messaging hosts for browser integration, and Python processes handling stdio MCP connections. If any of these leftover processes are still running, they can prevent the package from registering, causing the update to fail.

To resolve this issue, first, locate the package and its installation location. Use the following command:

Get-AppxPackage -Name *Claude* | Select-Object Name, PackageFullName, InstallLocation, Status

Next, identify any processes associated with the app. While the Get-Process command with the name "claude" might not capture all leftover processes, you can use the following command to find processes by their executable path:

Get-CimInstance Win32_Process | Where-Object { $_.ExecutablePath -like "$env:LOCALAPPDATA\Packages\Claude_*" } | Select-Object ProcessId, Name, ExecutablePath

Similarly, check if a packaged service like CoworkVMService is running:

Get-Service CoworkVMService | Select-Object Name, Status, StartType

The simplest fix is to terminate any leftover processes associated with the app and then relaunch it. You can do this with the following commands:

Get-Process claude, cowork-svc -ErrorAction SilentlyContinue | Stop-Process -Force

If the name matching misses some processes, use the path-based query to find and stop those specific processes.

After stopping the processes, you can try registering the package manually:

Stop-Service CoworkVMService -Force -ErrorAction SilentlyContinue

Get-Process claude, cowork-svc -ErrorAction SilentlyContinue | Stop-Process -Force

$pkg = Get-AppxPackage -Name *Claude*

Add-AppxPackage -DisableDevelopmentMode -Register "$($pkg.InstallLocation)\AppxManifest.xml"

This process is similar to what the Settings > Apps > Advanced options > Repair function does under the hood, except that it bypasses the AUTO_START service that restarts the package mid-update.

If the deployment path itself is corrupted, a reboot may help. In some cases, an orphaned container holding a registry hive can cause the issue, resulting in 0x80070020 (ERROR_SHARING_VIOLATION). A reboot releases this hold, allowing the package to be registered successfully.

As a last resort, you can remove and reinstall the app. Use the following commands:

Get-AppxPackage -Name *Claude* | Remove-AppxPackage

For packages provisioned for all users, use:

Remove-AppxProvisionedPackage -UprovisionedPackagePath -Force

This command requires elevated privileges to work. If the app installation path is on a drive other than C:, you may encounter error 0x80073CF6 indicating that the package could not be registered due to stale or duplicate package state. In this case, reinstalling the app after a reboot might help.

Keep in mind that some apps require administrator privileges for certain operations, such as registering a service without proper elevation. If you encounter error 0x80073D28, ensure you have the necessary permissions to perform the required actions.

Lastly, be aware that files and registry hives under WindowsApps are owned by the OS (TrustedInstaller) and are locked down to prevent tampering. Attempting to access these files directly through your shell will result in Access denied errors, as this behavior is intentional and not a permissions issue you can resolve by taking ownership.

By following these steps and understanding the underlying causes of 0x80073D02, you should be able to successfully resolve issues with Windows apps that auto-update and subsequently fail to launch.