microsoft / WindowsAppSDK

The Windows App SDK empowers all Windows desktop apps with modern Windows UI, APIs, and platform features, including back-compat support, shipped via NuGet.
https://docs.microsoft.com/windows/apps/windows-app-sdk/
MIT License
3.84k stars 320 forks source link

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

Open marticliment opened 8 months ago

marticliment commented 8 months ago

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 commented 8 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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

bpulliam commented 7 months ago

Does this repro with 1.5?

marticliment commented 7 months ago

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

bpulliam commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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

https://github.com/marticliment/WingetUI/issues/1939#issuecomment-1999349769

DrusTheAxe commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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?

image

Are you a packaged or unpackaged app?

marticliment commented 7 months ago

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 commented 7 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 5 months ago

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