Skip to content
littleden.blogEvidence-led Windows troubleshooting, without the guesswork
Apps, installers & Microsoft Store · scoped error record
0x80073D02

MSIX/AppX package resources are currently in use

0x80073D02 means package deployment cannot proceed because a running process is using resources that must be changed.

Applies to: MSIX/AppX deploymentReviewed: 2026-09-17

What it means in this context

Microsoft’s MSIX deployment troubleshooting table maps 0x80073D02 to ERROR_PACKAGES_IN_USE: the package is currently in use by a running process. The narrow fix is to close the relevant running app/process before updating or uninstalling the package.

Diagnostic state

What is known, and what is not proven yet

Keep observation, evidence and conclusion separate before making a higher-impact change.

Observed fact

MSIX/AppX deployment returned 0x80073D02.

Windows evidence

Running process/package relationship plus ActivityId when available.

Likely subsystem

Package deployment blocked by resources in use.

Evidence still needed

Which process owns the package resource and whether closure/restart clears it.

Safe next action

Close the owning app/process and retry once.

Handoff boundary

App publisher/IT if package processes repeatedly remain locked after restart.

Start here
  1. Save work in the affected app and close it normally.
  2. Check Task Manager for remaining processes belonging to that app/package.
  3. Retry the deployment once after the app is fully closed.
  4. If an ActivityId was returned, preserve it and use Get-AppxLog if the code changes or the package still fails.
1

Close the owning process before changing the package

Low risk

Why: The documented condition is package resources currently in use.

  1. Close the app normally.
  2. End only clearly identified leftover processes for that app when necessary.
  3. Retry the install/update/uninstall.
  4. Restart Windows if package processes cannot be cleanly released.
Scope boundary

When not to use this record

Do not terminate unrelated Windows processes or bulk re-register all AppX packages just to clear 0x80073D02.

If it persists

If the deployment then returns a different HRESULT, preserve the new ActivityId/code and follow that scoped package error.

Evidence

Reviewed source