Random 0x80073D02 issue when trying to launch a provisioned MSIX app

Hi @Pascal Fresnay ,

Thank you for posting,

The 0x80073D02 message is Windows saying: “I tried to finish the per‑user registration (install/servicing) of this provisioned MSIX, but something already had files from the package open.” It can happen even when the app “was never launched” because a hidden or system activation touched it first.

Typical silent blockers in this scenario:

• UWP prelaunch (Windows warms the app at sign‑in unless you disable it).
• A StartupTask or background task (push/app service/timer) firing immediately.
• RuntimeBroker / ShellExperienceHost / Start tile / notifications loading assets (logos, PRI, DLLs) before install finalizes.
• A leftover per‑user install from a previous sideload (two states to reconcile).
• On newer Windows 11 builds (24H2), the OS is less aggressive about auto‑closing blockers; races surface as 0x80073D02 instead of being hidden.

Why “Repair” works: it re‑registers the manifest after those early handles have released, giving deployment the exclusive access it lacked.

Recommended fixes (apply in order; these usually eliminate the randomness):

1. Disable prelaunch so Windows doesn’t start a hidden instance during logon:

      using Windows.ApplicationModel.Core;
      public App() {
          this.InitializeComponent();
          CoreApplication.EnablePrelaunch(false);
      }
   

2. Clean up any legacy user installs before (re)provisioning a new version: remove user copies (Remove-AppxPackage -AllUsers), then provision only the current bundle once.
3. Defer StartupTask or background task registration until first successful manual launch (or add a short delay). If not essential at boot, let the user open the app first.
4. Schedule version updates / provisioning changes when no interactive users are logged on (maintenance window) to avoid suspended instances holding files.
5. Provide a scripted “repair” for helpdesk instead of sending users to Settings:

      $pkg = Get-AppxPackage -Name excense.CompositeurDigitalUX.sideloaded
      Add-AppxPackage -Register "$($pkg.InstallLocation)\AppxManifest.xml" -DisableDevelopmentMode -ForceApplicationShutdown
   

   (Use ForceApplicationShutdown only if you’re comfortable letting Windows close a lingering instance.)

Targeted verification when it fails:

• Event Viewer > Microsoft-Windows-AppxDeployment-Server/Operational: capture the failure plus a few earlier events for context.
• Process Explorer (Find Handle/DLL) or a PowerShell module scan to see if RuntimeBroker/ShellExperienceHost loaded your package files.
• Get-AppxPackage -AllUsers to spot duplicate versions or partially installed user states.

In most enterprise cases, disabling prelaunch + removing old per-user installs + deferring background activation stops these intermittent 0x80073D02 errors entirely. If you confirm you’re on Windows 11 24H2, the increased sensitivity to “in use” conditions explains why it appears “random” now.

If you can share whether you use a StartupTask, background tasks, or app services, I can narrow further—but implementing the above is usually sufficient.

I hope this helps.