This application requires the App Windows Runtime version 1.X when the runtime is already installed

[marticliment]

Describe the bug

I am receiving complaints of users being required to install the app runtime (which was installed on their computers by my app installer automatically), installing it as the prompt suggests and being prompted again to install it

Steps to reproduce the bug

Could not recreate it. Sometimes an app runtime uninstall works, sometimes it does not work for the affected users

Expected behavior

AppRuntime works after installing

Screenshots

No response

NuGet package version

Windows App SDK 1.5.1: 1.5.240311000

Packaging type

Unpackaged

Windows version

Insider Build (xxxxx), Windows 11 version 22H2 (22621, 2022 Update), Windows 11 version 21H2 (22000), Windows 10 version 22H2 (19045, 2022 Update)

IDE

Visual Studio 2022-preview

Additional context

No response

[majaeger]

We are seeing this issue sporadically as well, both on dev machines + end-user installs. The installer logs show that we successfully acquired and ran the installer, and it completed successfully. We are on version 1.4.2 currently

[DarranRowe]

Just to make something clear, the Windows App Runtime is strongly versioned to the minor version too. So if you built the application with the Windows App SDK version 1.4, you MUST install the 1.4 version of the Windows App Runtime. Version 1.5 will not be found or used.

[majaeger]

Understood. We do install the specific version as part of our wix installer (1.4.2)

<?define WindowsAppRuntimeRedistLink = https://aka.ms/windowsappsdk/1.4/1.4.231008000/windowsappruntimeinstall-x64.exe?>

[DrusTheAxe]

It's unclear from the thread but...are you running the installer elevated?

If the installer's run elevated it will stage + provision the packages thus making them available to all users.
If the installer's not run elevated it will add the package for the current user.

Key difference there. In the latter case user1 has the package's registered but user2+ do not and will each need to install it. In the former, the packages are provisioned and will be registered for all users (current user now, other users at their next login).

Depending how your and winappsdk's installers run, and the user and security contexts they run under, this could explain the inconsistencies. Hard to say given the limited information here but it's a thought.

[marticliment]

I have had users reinstall the app sdk package multiple times both with and without administrator rights without success

[bpulliam]

Does this repro with 1.5?

[marticliment]

I cannot tell, the first version of my app running app sdk was with 1.5.1

[bpulliam]

Let's make sure it is the right installer. Here is the x64 one: https://aka.ms/windowsappsdk/1.5/1.5.240311000/windowsappruntimeinstall-x64.exe
Similar links for x86 and arm64.

[marticliment]

Yes, users are getting the right installer. App Sdk is bunded with my app installer, and for 99.9% of users it works out of the box. Only for that 0.1% it crashes. I have checked they had the proper versions installed, and they do

[DrusTheAxe]

I have checked they had the proper versions installed, and they do

Checked how?

The packages need to be registered for that user or as far as the caller's concerned they don't exist. Easiest way to tell is to run from a mediumIL command prompt

powershell -c Get-AppxPackage micro*win*app*run*

That only shows packages registered to the user.

If you run from an admin prompt

powershell -c Get-AppxPackage micro*win*app*run* -AllUsers

you'll also see PackageUserInformation reported for each package with the list of which users have it registered ("Installed")

NOTE: If PackageUserInformation only shows {S-1-5-18 [blah]: Installed} then it's actually Staged and not registered for any user.

[marticliment]

The issue the user is facing is due to the AppSdk installer failing (see second screenshot of the linked post):

marticliment/UniGetUI#1939 (comment)

[DrusTheAxe]

The issue the user is facing is due to the AppSdk installer failing (see second screenshot of the linked post):

marticliment/WingetUI#1939 (comment)

The error message from there is French. Translate to English:

...DeploymentExtendedText:Microsoft.WinAppRuntime.DDLM.5001.70.1338.0-x6_5001.70.1338.0_x64__8wekyb3d8bbwe package failed to deploy with the package origin Unknown because there was no valid license or independent upload policy

@bpulliam Thoughts...

1. Something wrong with the signing? (DDLM packages aren't submitted to Store for signing or distribution)
2. Does the machine have Developer Mode not enabled?
3. Is the machine Server (not Desktop) and relying on the default handling re signing (Server+Desktop have different defaults)

[marticliment]

I have received the output of one of the users who are receiving the issue:

Installing license: MSIX_MAINPACKAGE_LICENSE
Install License result : 0x0
Installing license: MSIX_SINGLETONPACKAGE_LICENSE
Install License result : 0x0

All install operations successful.

This is the error they are receiving on EventViewer:

Log Name:      Application
Source:        Windows App Runtime
Date:          4/1/2024 9:02:20 AM
Event ID:      5
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      TIGGER
Description:
Access is denied.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Windows App Runtime" />
    <EventID Qualifiers="32775">5</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2024-04-01T13:02:20.4721576Z" />
    <EventRecordID>749572</EventRecordID>
    <Correlation />
    <Execution ProcessID="0" ThreadID="0" />
    <Channel>Application</Channel>
    <Computer>TIGGER</Computer>
    <Security />
  </System>
  <EventData>
    <Data>Windows App Runtime</Data>
    <Data>ERROR 0x80070005: Bootstrapper initialization failed while looking for version 1.5 (MSIX package version &gt;= 5001.70.1338.0)</Data>
  </EventData>
</Event>

[DrusTheAxe]

User: N/A

Why is user N/A?

What user were the packages installed by?
Was the installer run elevated?
What user is trying to run your app which calls the Bootstrapper and failing?

Please run from an admin prompt

get-appxpackage micro*win*app*run* -allusers

That'll show the WinAppSDK packages on the machine and which users they're registered for or if they're merely staged.

<Data>ERROR 0x80070005: Bootstrapper initialization failed while looking for version 1.5 (MSIX package version &gt;= 5001.70.1338.0)</Data>

0x80070005 = E_ACCESSDENIED. Which is odd.

How is your app being launched? Clicking on tile in StartMenu? In file explorer right-click on .exe and Open, Run as administrator or Run as another user? Explicitly path'ing to your .exe?

Are you a packaged or unpackaged app?

[marticliment]

User is n/a for privacy.
Intaller was run with standard and admin privileges.
An user with admin rights (but the app was ran without elevation)
App was launched regularly from start menu.
App is unpackaged.

I will attach the output of running the command once affected users answer back.

[marticliment]

I have been able to workaround this issue by deploying the app sdk self-contained with the app.
This issue can be closed now

[omikhailov]

Had the same problem with a solution where multiple projects contained references to different 1.4 builds.
The problem went away after updating all Nuget packages in all projects to the latest stable version of SDK.

[just-a-hriday]

Having this problem too, with an unpackaged AOT-compiled WinUI 3 app on windows 11. Running the executable as admin didn't help.

I also tried uninstalling and reinstalling the windows app SDK from the nuget package manager in visual studio, and updated the SDK build tools. Neither of these made a difference.

Whenever I run the executable, a dialog box reads:

This application requires the Windows App Runtime
  Version 1.5
  (MSIX package version >= 5001.119.156.0)

Do you want to install a compatible Windows App Runtime now?

[amadeo-alex]

I have been able to workaround this issue by deploying the app sdk self-contained with the app. This issue can be closed now

For anyone experiencing this, or "System.UnauthorizedAccessException" while calling AppNotificationManager.Register() - the above is the solution.

<WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>

in the project file

[sotanakamura]

This problem occurs in 24H2, but not in 22H2.

Edition Windows 11 Enterprise
Version 22H2
OS build 22621.4391

[haonanttt]

I have been able to workaround this issue by deploying the app sdk self-contained with the app. This issue can be closed now

As the author for this issue already found a workaround for this, this issue will be closed.

For anyone else who also encounter this issue (or similar issue), please open a new issue and paste your problem as well as the needed information. A new issue only for your problem is more clear and can better communicate rather than use this issue to track everyone's scenario.

Per the discussion above, before you open a issue and announce you have met this issue, please double confirm that you have installed the WinAppSDK successfully and please paste the results into your issue as needed information:

1. See this comment and please double confirm whether you run the installer elevated

If the installer's run elevated it will stage + provision the packages thus making them available to all users. If the installer's not run elevated it will add the package for the current user.

Key difference there. In the latter case user1 has the package's registered but user2+ do not and will each need to install it. In the former, the packages are provisioned and will be registered for all users (current user now, other users at their next login).

Depending how your and winappsdk's installers run, and the user and security contexts they run under, this could explain the inconsistencies. Hard to say given the limited information here but it's a thought.

2. Use these command prompts to double check the package registration status for your users

The packages need to be registered for that user or as far as the caller's concerned they don't exist. Easiest way to tell is to run from a mediumIL command prompt

powershell -c Get-AppxPackage micro*win*app*run*

That only shows packages registered to the user.

If you run from an admin prompt

powershell -c Get-AppxPackage micro*win*app*run* -AllUsers

you'll also see PackageUserInformation reported for each package with the list of which users have it registered ("Installed")

NOTE: If PackageUserInformation only shows {S-1-5-18 [blah]: Installed} then it's actually Staged and not registered for any user.

[sotanakamura]

@haonanttt I don't think the self-contained app is not the solution for the non-self-contained app that cannot find the app runtime, but I don't have the problem of the runtime after installing v1.6.5, so it seems to be fixed anyway.

runtime v1.6.5
Edition Windows 11 Home
Version 24H2
OS build 26100.3194