Add-AppxPackage error 0x80073D02, also identified as ERROR_PACKAGES_IN_USE, means Windows cannot complete an AppX/MSIX deployment because a running process is using resources the package operation needs to modify. It applies to installation, update, removal, and re-registration operations on Windows 10 and Windows 11. The safest first action is to read the failure output for the named app or package, close every visible instance of that app, and retry the same operation.

What Add-AppxPackage error 0x80073D02 means

The full failure may begin with Deployment failed with HRESULT: 0x80073D02 or state that the package could not be installed because resources it modifies are currently in use. According to Microsoft’s AppX deployment troubleshooting reference, the code specifically represents a package-in-use condition.

The resource can be held by a visible app instance, a background task or service associated with the app, or an open file in the app’s data, such as a log file. Closing a visible window may therefore be sufficient in some cases but not in every case.

Detail What it establishes
0x80073D02 The deployment was rejected because package resources are in use.
Named app or package The first place to look for the process holding the resource.
ActivityID, if returned A reference that can be used when reviewing the associated deployment log.

This guide does not apply to a deployment failure with a different code or to a Windows Update error. Those conditions require separate diagnosis.

Identify the app or package that must be closed

When this applies: Use this process when the error output names an app or package family, or says that one or more apps need to be closed.

Prerequisite: Keep the original error output available so that you can compare its app or package name with the processes you inspect.

  1. Read the complete deployment output rather than only the first HRESULT line.
  2. Look for the app or package family named as being in use. The output may explicitly identify the apps that need to be closed.
  3. Close every visible window belonging to the named app.
  4. Open Task Manager and look for a remaining instance of that same app.
  5. If you already know the corresponding process name, you can also use Get-Process to check whether it remains active.

Expected result: You identify a process that clearly corresponds to the app or package reported by the failure, or confirm that no obvious matching process remains.

Risk and warning: Inspection is low risk, but package-family names do not have a universal documented mapping to process names. Do not guess from an unfamiliar package name, end every process with a similar name, or terminate an unrelated system process. Task Manager wording may also vary slightly by Windows build.

Microsoft’s MSIX troubleshooting guide supports checking for running instances with Task Manager or Get-Process.

Close the confirmed blocker and retry the package operation

When this applies: Use this fix after the output or process inspection identifies the app that is using the package.

Prerequisites: Save work in the affected app and confirm that the process you intend to close belongs to the named app. If the relationship is uncertain, use the deployment logs in the next section instead of terminating the process.

  1. Close every visible window for the named app.
  2. Check Task Manager or Get-Process for a remaining instance.
  3. Stop only the matching process if it is safe to close.
  4. Confirm that the app is no longer running.
  5. Retry the same Add-AppxPackage, installation, update, removal, or re-registration operation that originally failed. Do not substitute a broad package-repair command.
  6. If 0x80073D02 returns, check the output and logs for another blocker.

Expected result: Windows can proceed once no process is holding the resources required by the package operation. A retry can still expose another blocker, so success is not guaranteed.

Risk and rollback: Closing a process can discard unsaved work in that app. Reopen the app after the deployment completes or after you stop troubleshooting. The official Add-AppxPackage reference documents the deployment command; reuse the operation appropriate to your original task without adding undocumented parameters.

Check AppX deployment logs when the blocker is unclear

Logs are appropriate when the error text is incomplete, the visible app is already closed, or the failure returns after the obvious blocker has been removed. Reading these logs is diagnostic and does not itself repair the deployment.

Review the AppxDeployment-Server log in Event Viewer

When this applies: Use Event Viewer when you need more detail about why Windows rejected the deployment.

Prerequisite: You must be able to open Event Viewer. No administrator requirement is asserted here because that can vary with the environment being examined.

  1. Open Event Viewer.
  2. Go to Applications and Services Logs > Microsoft > Windows > AppxDeployment-Server > Operational.
  3. Review the deployment rejection details associated with the failed operation.
  4. Identify the relevant app, package, process, background task, service, or open resource without inferring a process from an uncertain package name.
  5. Close only the confirmed blocker, then retry the original package operation.

Expected result: The log supplies more specific deployment information that can help distinguish the relevant blocker from unrelated running processes.

Risk and rollback: Reading the log does not change the system, so no rollback is needed. Do not clear or modify logs as part of this procedure.

Use Get-AppxLog for the failed deployment

When this applies: Use Get-AppxLog after an Add-AppxPackage or Remove-AppxPackage failure, particularly when the output returned an ActivityID.

Prerequisites: PowerShell access and, when available, the ActivityID from the failure output.

  1. Use Get-AppxLog for the most recent deployment or for the available ActivityID.
  2. Read the logged errors and warnings.
  3. Use those details to identify the package or process holding the required resources.
  4. Close only the confirmed blocker.
  5. Retry the same operation and recheck the log if the error returns.

Expected result: The deployment log provides evidence about the failed package operation and may reveal a blocker that was not obvious in the original output.

Risk and rollback: This is a read-only diagnostic step and needs no rollback. Do not treat the presence of a similar process name as sufficient evidence to terminate it.

Handle a Windows shell component that restarts automatically

When this applies: Use this fallback only when the confirmed blocker is a Windows shell or background component that relaunches automatically and cannot remain closed long enough to complete the package operation.

Prerequisites: Save work in all open applications and confirm from the error or deployment logs that the relaunching component is the blocker.

  1. Sign out of Windows and sign back in, or restart Windows.
  2. After signing in, retry the original deployment operation.
  3. If the same component returns and the operation again reports 0x80073D02, review the AppxDeployment-Server log or Get-AppxLog again.

Expected result: Signing out or restarting can end the previous session’s running instances, providing another opportunity to perform the deployment. A shell component may relaunch, so this fallback may not resolve every case.

Risk and rollback: Signing out or restarting closes applications and can discard unsaved work. Save first, then reopen your applications after signing back in. Do not repeatedly terminate shell processes.

Fixes not supported for 0x80073D02

Microsoft’s error-specific guidance centers on closing the process using the package and examining deployment logs. The supplied evidence does not support the following actions as fixes for ERROR_PACKAGES_IN_USE:

  • Resetting the Microsoft Store cache as the default response.
  • Bulk re-registering every AppX package or every user’s packages.
  • Weakening the PowerShell execution policy.
  • Editing the registry.
  • Resetting or restoring Windows.
  • Terminating unrelated processes because their names resemble a package family.

These broad actions do not address the confirmed condition that a required package resource is in use and may introduce additional problems. If your failure is an access-denied Windows Update condition instead, see the separate guide to Windows Update error 0x80070005; it is not equivalent to this AppX/MSIX error.