How to robustly update a Microsoft Store packaged app from a Windows Service running as LocalSystem? StoreContext/AppInstallManager APIs fail silently or block indefinitely

There is no supported way in the Microsoft Store/MSIX platform to implement a fully controlled, service‑driven self‑update mechanism for a Store‑distributed app running under LocalSystem. The supported update model is:

• Updates are orchestrated by the Microsoft Store infrastructure.
• App‑initiated update checks and installs are done from an interactive user context via Windows.Services.Store.StoreContext.
• Silent behavior is constrained by user and network settings.

Within those constraints, the closest supported architecture is:

1. Use StoreContext from the app’s user context (not from a LocalSystem service) to:
   • Check for available updates.
   • Initiate download and install.
   • Track progress and completion.
2. Let the Store infrastructure enforce user settings such as “Update apps automatically” and metered network behavior; these are not overrideable from a service.
3. Use mandatory updates and in‑app logic to enforce that a required version is installed before enabling certain functionality.

Below is what is officially supported and how it maps to the requirements.

Supported APIs and their behavior

For Store‑published MSIX apps, the supported programmatic update APIs are on StoreContext in the Windows.Services.Store namespace:

• GetAppAndOptionalStorePackageUpdatesAsync – checks which packages have updates available for the current app.
• RequestDownloadStorePackageUpdatesAsync – downloads updates with user consent UI.
• RequestDownloadAndInstallStorePackageUpdatesAsync – downloads and installs updates with user consent UI.
• TrySilentDownloadStorePackageUpdatesAsync – attempts silent download (no UI).
• TrySilentDownloadAndInstallStorePackageUpdatesAsync – attempts silent download and install (no UI).

These APIs are explicitly designed for the current app context and are documented as the way to “programmatically check for package updates for the current app from the Microsoft Store, and download and install the updated packages.” They are not documented or supported for use from a system service running as LocalSystem.

Check whether an update is available

Use:

var storeContext = StoreContext.GetDefault();
var updates = await storeContext.GetAppAndOptionalStorePackageUpdatesAsync();

• Returns a collection of StorePackageUpdate objects representing packages that have updates available.
• This is the supported “check for update” API. It does not itself perform download or install.
• It is subject to rate limits (no more than one check every 30 minutes and no more than ten checks in 24 hours). If called more frequently, it returns the last known status instead of performing a new check.
• It requires that the Microsoft Store app and services are present and functional, and that Store endpoints are reachable.

Start download/update explicitly

Once updates are known, the app can choose how to proceed:

• Interactive (with UI):
  • RequestDownloadStorePackageUpdatesAsync(updates) – download only.
  • RequestDownloadAndInstallStorePackageUpdatesAsync(updates) – download and install.
  These show OS dialogs asking the user to approve download and then install. The methods return an IAsyncOperationWithProgress<StorePackageUpdateResult, StorePackageUpdateStatus> that can be observed for progress and completion.
• Silent (no UI, only if allowed):
  • TrySilentDownloadStorePackageUpdatesAsync(updates) – silent download.
  • TrySilentDownloadAndInstallStorePackageUpdatesAsync(updates) – silent download and install.
  These are available starting in Windows 10, version 1803. They:
  • Only succeed if the user has enabled Update apps automatically in the Store and the user is not on a metered network.
  • Should be gated by checking StoreContext.CanSilentlyDownloadStorePackageUpdates before calling.

The platform does not provide an API to bypass these user/network conditions. If auto‑update is disabled or the network is metered, silent operations will not perform the update; the supported pattern is to check CanSilentlyDownloadStorePackageUpdates and fall back to interactive APIs or defer.

Deterministic status and progress

All of the Request* and TrySilent* methods return an IAsyncOperationWithProgress<StorePackageUpdateResult, StorePackageUpdateStatus>:

• StorePackageUpdateResult:
  • Has an OverallState property that indicates success, canceled, or error.
  • If the user declines the download or install dialogs in the interactive methods, OverallState is Canceled.
• StorePackageUpdateStatus:
  • Provided via the Progress handler.
  • Contains a PackageDownloadProgress field from 0.0 to 1.0 representing combined download+install progress (0.0–0.8 for download, 0.8–1.0 for install).

This allows building a custom progress UI or logging progress in the app. The platform does not expose a richer, strongly typed breakdown such as “app in use” vs “restart required” as separate states; these conditions are handled by the Store infrastructure and surfaced primarily via the dialogs and the final OverallState.

“App in use”, “restart required”, and blocking behavior

For interactive methods (RequestDownloadAndInstallStorePackageUpdatesAsync):

• The OS displays dialogs for download and install.
• If the user does not grant permission, OverallState is Canceled.
• If the app must restart, the dialog warns the user. The app is expected to react appropriately (for example, closing itself when the update is applied).

The documentation does not define a specific error code for “app in use” or “restart required” that can be programmatically distinguished from other failure modes. Instead, the expectation is that the app coordinates its own shutdown/restart behavior around the update process.

The APIs are asynchronous and non‑blocking at the call level; they return an async operation that completes when download and install are done. If behavior appears to “block indefinitely” in practice, that typically indicates that the OS is waiting for user interaction or that the Store services are not able to complete the operation (for example, Store service issues or connectivity problems). Proper error handling around the async operation and logging of exceptions is required.

Service/LocalSystem scenario

The provided documentation and APIs are scoped to:

• The “current app” context.
• A StoreContext obtained via StoreContext.GetDefault() (or GetForUser for multi‑user apps).
• UI‑thread requirements for methods that show dialogs (for example, RequestDownloadAndInstallStorePackageUpdatesAsync must be called on the UI thread; calling it off the UI thread can cause COM exceptions such as ERROR_INVALID_WINDOW_HANDLE).

There is no documentation indicating that StoreContext or these update methods are supported from a Windows Service running as LocalSystem. On the contrary, the requirements (UI thread, app window ownership for modal dialogs, user settings like “Update apps automatically”) imply that the intended usage is from an interactive app process running in a user session.

For silent methods, the same StoreContext and “current app” assumptions apply, and they still rely on user‑level Store settings and network conditions. Running them from LocalSystem would not align with the documented prerequisites (for example, user Store settings, app context, UI thread for some methods).

Recommended architecture for controlled updates

Within the supported model, the recommended approach for a Store‑distributed MSIX desktop app that needs controlled updates is:

1. Perform update checks and initiation from the app (user context), not from a LocalSystem service.
   • Use GetAppAndOptionalStorePackageUpdatesAsync to detect updates.
   • Use TrySilentDownloadAndInstallStorePackageUpdatesAsync when CanSilentlyDownloadStorePackageUpdates is true.
   • Fall back to RequestDownloadAndInstallStorePackageUpdatesAsync when silent update is not allowed.
2. Use mandatory updates and in‑app gating for robustness.
   • In Partner Center, mark critical updates as mandatory.
   • In the app, query for mandatory updates and disable or limit functionality until the update is installed.
3. Track progress and completion via the async operation and StorePackageUpdateStatus.
   • Log progress and final OverallState for diagnostics.
   • Implement app restart behavior as needed when an update is applied.
4. Keep Store auto‑update enabled where possible.
   • Silent APIs depend on the user’s Update apps automatically setting and non‑metered network.
   • If an environment requires strict control, consider that disabling auto‑update shifts responsibility to the organization to keep the app current, and Microsoft may block outdated clients from connecting to services for security reasons.

For scenarios where an enterprise needs full, service‑driven control over deployment and updates (including running under LocalSystem, independent of user Store settings), the supported approach is to use non‑Store distribution and enterprise management tools (for example, MSIX via enterprise deployment mechanisms) rather than relying on Microsoft Store update APIs. The provided documentation, however, focuses on Store‑based updates and does not describe a LocalSystem service pattern for Store packages.

References:

• Download and install package updates from the Store
• Update Store-published apps from your code
• StoreContext.GetAppAndOptionalStorePackageUpdatesAsync Method
• StoreContext.RequestDownloadAndInstallStorePackageUpdatesAsync Method
• StoreContext.TrySilentDownloadAndInstallStorePackageUpdatesAsync Method
• Configure Windows App updates on Windows
• Troubleshoot Microsoft Store app download failures