9NRZT3Q9R3DL-Microsoft.WindowsAppRuntime.2 updates every day

Denis Bakharev 0 Reputation points
2026-09-07T11:52:31.24+00:00

see the screenshot:User's image

this appx is in 'staged' status for 'NT Authority/SYSTEM' account:

PS C:\Users\DenisAdmin> Get-AppxPackage -AllUsers |
>>      Where-Object {
>>          $_.Name -match 'Microsoft.WindowsAppRuntime.2'
>>      } |
>>      Select-Object Name, PackageFullName, PackageUserInformation
Name                          PackageFullName                                          PackageUserInformation
----                          ---------------                                          ----------------------
Microsoft.WindowsAppRuntime.2 Microsoft.WindowsAppRuntime.2_2.4.0.0_x86__8wekyb3d8bbwe {S-1-5-18 [S-1-5-18]: Staged}
Microsoft.WindowsAppRuntime.2 Microsoft.WindowsAppRuntime.2_2.4.0.0_x64__8wekyb3d8bbwe {S-1-5-18 [S-1-5-18]: Staged}

And it can't be uninstalled: 

PS C:\Users\DenisAdmin> Remove-AppxPackage -Package 'Microsoft.WindowsAppRuntime.2_2.4.0.0_x64__8wekyb3d8bbwe'
Remove-AppxPackage: Deployment failed with HRESULT: 0x80073D02, The package could not be installed because resources it modifies are currently in use.
Error 0x80073D02: The request cannot be processed because package Microsoft.WindowsAppRuntime.2_2.4.0.0_x64__8wekyb3d8bbwe is in use.

How to remove Microsoft.WindowsAppRuntime.2_2.4.0.0_x86__8wekyb3d8bbwe and Microsoft.WindowsAppRuntime.2_2.4.0.0_x64__8wekyb3d8bbwe from my PC?

Windows for business | Windows Client for IT Pros | User experience | Other
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Daphne Huynh (WICLOUD CORPORATION) 1,385 Reputation points Microsoft External Staff Moderator
    2026-09-09T03:33:13.8233333+00:00

    Welcome to Microsoft Q&A!

    Thank you for sharing the additional details and for clarifying that point.

    Based on the output you provided, I agree that Microsoft.WindowsAppRuntime.2 is not a provisioned package, so Remove-AppxProvisionedPackage would not apply in this case.

    From the Get-AppxPackage -AllUsers results, the packages appear only as: S-1-5-18 [NT AUTHORITY\SYSTEM]: Staged

    This suggests that the Windows App Runtime packages are staged for the SYSTEM account as framework dependencies, rather than being provisioned for new user profiles.

    A few observations that may help explain the behavior:

    • Microsoft.WindowsAppRuntime.2 is part of the Windows App SDK runtime framework. Applications built on the Windows App SDK rely on these runtime packages, and Windows manages them separately from the applications that use them.
    • The error 0x80073D02 indicates that the package is currently in use. In this situation, Remove-AppxPackage is expected to fail because the deployment service cannot remove a package while it is still being referenced by the system or by a dependent application.
    • Based on the information shared so far, I do not see clear evidence that the staged SYSTEM registrations themselves are causing the repeated update entries. The update history shows recurring successful updates for 9NRZT3Q9R3DL-Microsoft.WindowsAppRuntime.2, but that does not necessarily mean the SYSTEM-staged packages are being recreated each day.

    To better understand what is happening, could you check whether the package version is actually changing between updates?

    Get-AppxPackage -AllUsers Microsoft.WindowsAppRuntime.2 |

    Select-Object Name, Version, PackageFullName, PackageUserInformation

    It may also be useful to know whether the device has applications installed that depend on the Windows App SDK runtime, such as Windows App, Dev Home, WinUI 3 applications, or other Microsoft Store apps built on the Windows App SDK.

    At this point, I would be cautious about trying to forcibly remove the staged runtime packages. Since these packages serve as framework dependencies, removing them may impact applications that rely on the Windows App SDK runtime.

    From a troubleshooting perspective, the more interesting question seems to be why Microsoft Store or the App Installer infrastructure continues to detect, offer, or record updates for the same runtime package daily, rather than why the SYSTEM-staged package exists. Determining whether the package version changes after each update, or whether the same version is being repeatedly offered, would help narrow down the root cause.

    For reference: Remove outdated Windows App SDK runtime versions from your development computer - Windows apps | Microsoft Learn

    Windows App SDK deployment guide for framework-dependent packaged apps - Windows apps | Microsoft Learn

    Thank you for using Microsoft Q&A.

    If you find this information helpful, please click Accept Answer. 

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments
  2. Hoang Le 5,630 Reputation points Independent Advisor
    2026-09-07T12:26:02.18+00:00

    Dear Denis Bakharev,

    The packages you’re seeing in “Staged” state under the SYSTEM account are framework packages that Windows keeps for runtime dependencies, which is why a direct Remove-AppxPackage fails with 0x80073D02. To remove them cleanly you need to use Remove-AppxProvisionedPackage -Online -PackageName <PackageFullName> from an elevated PowerShell session. This command targets provisioned packages staged for all users, including SYSTEM. After removal, run DISM /Online /Cleanup-Image /StartComponentCleanup to flush any residual references. If the package is still locked, reboot into Safe Mode and repeat the DISM cleanup, since no user processes will hold the runtime. Be aware that removing WindowsAppRuntime can break apps that depend on it, so validate application compatibility before stripping it out.

    If my answer is useful for you, please hit Accept the answer to support me.

    Thank you,

    HL.

    Was this answer helpful?

    1 person found this answer helpful.

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.