UWP Application Initialization Failures and AppX Registry Omissions in Non-Persistent Windows 10 Environments

Question

Hi there! We use non-persistent workstation environments to maintain operational continuity across our enterprise training facilities, but our endpoints consistently fail to launch native Universal Windows Platform (UWP) programs, notably the Windows Store, Calculator, and Camera. These Windows 10 machines are managed via SCCM and integrated into an on-premises Active Directory infrastructure. However, they function as shared kiosks that discard profiles upon logoff, every user session operates as a first-time authentication. Executing these modern applications generates a kernelbase.dll crash event within the AppX-Deployment telemetry. While forcefully re-registering the specific framework dependency Microsoft.UI.Xaml.2.8_8.2310.30001.0_x64__8wekyb3d8bbwe resolves the defect for the current session, this manual remediation is unsustainable at scale, and we are seeking the architectural root cause rather than a per-session band-aid. Diagnostics reveal that affected logins possess an entirely empty HKEY_CURRENT_USER\SOFTWARE\Classes\ActivatableClasses\Package registry node, which successfully populates on healthy profiles. Any advice on this?

Thanks in advance.

Answer 1

Hi Henrike Rosënkranz,

I’m following up to check whether the issue has been resolved. Feel free to reply if you need further information. If the information provided was helpful, please click "Accept Answer" to help others in the community. Thank you!

Answer 2

Hi Henrike Rosënkranz,

To the best of my knowledge, the root cause here lies in how non-persistent profiles handle registry initialization. Because each session is treated as a first-time login, the HKEY_CURRENT_USER registry hive is rebuilt every time. The AppX subsystem expects certain entries under ActivatableClasses to be present, but in non-persistent environments these keys often fail to populate correctly. That explains why re-registering the framework dependency resolves the issue temporarily, it forces the registry entries to be rebuilt for that session only.

Architecturally, this is not a bug in the apps themselves but a limitation of how UWP apps rely on per-user registry state. In non-persistent environments, Microsoft’s recommended approach is to use provisioning packages or enterprise management tools (like SCCM or Intune) to pre-stage UWP dependencies and ensure the default profile contains the necessary AppX registry entries. This way, every new user session inherits a healthy baseline rather than starting from an empty hive.

Another best practice is to avoid customizing the default profile in Audit mode, as this can interfere with AppX initialization. Instead, apply app provisioning through supported deployment channels and let the system handle registry population during first logon.

I hope this explanation helps clarify why the issue occurs and gives you a sustainable path forward. If this answer is helpful, please don’t forget to hit “Accept Answer”.

Jason.