Windows 10/11 - App installed via *.appinstaller wont start anymore under Windows 10/11
Opened this issue · 21 comments
I am having the following issue. If i try to start an app i can see the Appinstaller appearing in taskbar for a milisecond and then nothing happens.
The App is installed via *.Appinstaller from my own website.
It seems to be an issue in Microsoft.DesktopAppInstaller v1.27.350.0 and v1.27.340.0.
Everything is fine with v1.26.510.0.
I already tried to narrow it down and it seems to be releated to ShowPromt and UpdateBlocksActivation. If i remove those Attributes the app starts again.
<UpdateSettings>
<OnLaunch
HoursBetweenUpdateChecks="0"
ShowPrompt="true"
UpdateBlocksActivation="true" />
</UpdateSettings>
Windows Event Log:
Aktivierungsfehler bei Microsoft.DesktopAppInstaller_8wekyb3d8bbwe!App. Fehlercode: Klasse nicht registriert. Aktivierungsphase: No phase defined
Aktivierungsfehler bei *****App. Fehlercode: Die Aktivierung ist aufgrund der APPINSTALLER-Aktualisierungseinstellungen für diese App blockiert.. Aktivierungsphase: Deployment
Can you help me to resolve this issue?
Is this an issue related to WinGet specifically, or App Installer?
Is this an issue related to WinGet specifically, or App Installer?
This is App Installer.
ShowPromt and UpdateBlocksActivation. If i remove those Attributes the app starts again.
So AppInstaller.exe is crashing. If you set ShowPrompt="false", then the OS shouldn't use AppInstaller.exe at all. If you set UpdateBlocksActivation="false", then the OS will launch your app even if AppInstaller.exe fails to update your app - and that includes failing because it crashed.
(That is just to confirm that the workaround seems sound and should work for now. I still need to look into the actual AppInstaller.exe issue.)
Givin this is App Installer as opposed to WinGet, I'm making this as "Area-External". I'm fine leaving this issue open here until it's resolved (assuming nothing else changes).
Machine translation of the event log for reference:
Activation error with Microsoft.DesktopAppInstaller_8wekyb3d8bbwe!App. Error code: Class not registered. Activation phase: No phase defined
Activation error with *****App. Error code: Activation is blocked for this app due to the APPINSTALLER update settings. Activation phase: Deployment
So it is not that App Installer itself crashes, but that something fails when trying to launch it, I think?
I wonder if it could be related to dependencies, since we just updated that. @l4nk4b3l , would you mind checking if the required dependencies are present? You can do it with this command:
(Get-AppPackage Microsoft.WindowsAppRuntime*1.8) + (Get-AppPackage Microsoft.VCLibs.140.00*) |
Select-Object -Property Name, Architecture, Version, StatusYou need to have
Microsoft.VCLibs.140.00 - v14.0.33519.0
Microsoft.VCLibs.140.00.UWPDesktop - v14.0.33728.0
Microsoft.WindowsAppRuntime.1.8 - v8000.616.304.0
Edit: If you have any logs from App Installer that also would be incredibly helpful. They are in the same location as winget's logs (%LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir)
I have the exact same issue on computers with Windows 11 22h2 or lower and Windows 10, if I update to latest Windows 11 25h2 issue goes away but it's no ideal, all of them installed automatically the update from Microsoft Store for AppInstaller and that's when the issue started.
@florelis I tried the command you mention in an still affected Windows 11 21h2 an got:
PS C:\Users\CAJA 2> (Get-AppPackage Microsoft.WindowsAppRuntime*1.8) + (Get-AppPackage Microsoft.VCLibs.140.00*) |
>> Select-Object -Property Name, Architecture, Version, Status
Name Architecture Version Status
---- ------------ ------- ------
Microsoft.WindowsAppRuntime.1.8 X64 8000.642.119.0 Ok
Microsoft.WindowsAppRuntime.1.8 X86 8000.642.119.0 Ok
Microsoft.VCLibs.140.00 X64 14.0.32530.0 Ok
Microsoft.VCLibs.140.00 X64 14.0.33321.0 Ok
Microsoft.VCLibs.140.00.UWPDesktop X64 14.0.33519.0 Ok
Microsoft.VCLibs.140.00 X86 14.0.33519.0 Ok
Microsoft.VCLibs.140.00.UWPDesktop X86 14.0.33728.0 Ok
Microsoft.VCLibs.140.00.UWPDesktop X64 14.0.33728.0 Ok
Microsoft.VCLibs.140.00 X64 14.0.33519.0 Ok
This are some of the logs in the computer:
AppInstaller-2025-10-30-06-36-12.401.zip
@florelis i attached my logs. I will check if installing Microsoft.WindowsAppRuntime.1.8 - v8000.616.304.0 will make any difference.
C:\WINDOWS\system32> (Get-AppPackage Microsoft.WindowsAppRuntime*1.8) + (Get-AppPackage Microsoft.VCLibs.140.00*) |
>> Select-Object -Property Name, Architecture, Version, Status
Name Architecture Version Status
---- ------------ ------- ------
Microsoft.WindowsAppRuntime.1.8 X64 8000.642.119.0 Ok
Microsoft.WindowsAppRuntime.1.8 X86 8000.642.119.0 Ok
Microsoft.VCLibs.140.00 X64 14.0.27810.0 Ok
Microsoft.VCLibs.140.00 X64 14.0.29231.0 Ok
Microsoft.VCLibs.140.00 X64 14.0.30035.0 Ok
Microsoft.VCLibs.140.00 X64 14.0.30704.0 Ok
Microsoft.VCLibs.140.00.UWPDesktop X64 14.0.30704.0 Ok
Microsoft.VCLibs.140.00 X64 14.0.32530.0 Ok
Microsoft.VCLibs.140.00.UWPDesktop X64 14.0.32530.0 Ok
Microsoft.VCLibs.140.00.UWPDesktop X64 14.0.33321.0 Ok
Microsoft.VCLibs.140.00 X86 14.0.33321.0 Ok
Microsoft.VCLibs.140.00 X64 14.0.33321.0 Ok
Microsoft.VCLibs.140.00.UWPDesktop X64 14.0.33519.0 Ok
Microsoft.VCLibs.140.00.UWPDesktop X86 14.0.33519.0 Ok
Microsoft.VCLibs.140.00 X86 14.0.33519.0 Ok
Microsoft.VCLibs.140.00.UWPDesktop X86 14.0.33728.0 Ok
Microsoft.VCLibs.140.00.UWPDesktop X64 14.0.33728.0 Ok
Microsoft.VCLibs.140.00.Debug X64 14.0.33519.0 Ok
Microsoft.VCLibs.140.00.Debug X86 14.0.33519.0 Ok
Microsoft.VCLibs.140.00 X64 14.0.33519.0 Ok
Microsoft.VCLibs.140.00.Debug.UWPDesktop X64 14.0.33728.0 Ok
Update
I just tried on a fresh Windows 10 installation. Same result.
Name Architecture Version Status
---- ------------ ------- ------
Microsoft.WindowsAppRuntime.1.8 X64 8000.642.119.0 Ok
Microsoft.WindowsAppRuntime.1.8 X86 8000.642.119.0 Ok
Microsoft.VCLibs.140.00 X64 14.0.27323.0 Ok
Microsoft.VCLibs.140.00 X64 14.0.33519.0 Ok
Microsoft.VCLibs.140.00 X86 14.0.33519.0 Ok
Microsoft.VCLibs.140.00.UWPDesktop X86 14.0.33728.0 Ok
Microsoft.VCLibs.140.00.UWPDesktop X64 14.0.33728.0 Ok
Windows 11 is working fine for me
Name Architecture Version Status
---- ------------ ------- ------
Microsoft.WindowsAppRuntime.1.8 X86 8000.642.119.0 Ok
Microsoft.WindowsAppRuntime.1.8 X64 8000.642.119.0 Ok
Microsoft.VCLibs.140.00 X86 14.0.33519.0 Ok
Microsoft.VCLibs.140.00 X64 14.0.33519.0 Ok
Microsoft.VCLibs.140.00.UWPDesktop X86 14.0.33728.0 Ok
Microsoft.VCLibs.140.00.UWPDesktop X64 14.0.33728.0 Ok
I also added the 3 Windows Event logs in English.
Activation for 5c7e2727-0077-4369-affa-87a46a7311c1_qr4qbfp594vzg!App failed. Error code: Activation is blocked due to the .appinstaller update settings for this app.. Activation phase: Deployment
event_3.log
Activation for Microsoft.DesktopAppInstaller_8wekyb3d8bbwe!App failed. Error code: Class not registered. Activation phase: No phase defined
event_2.log
Activation of app 5c7e2727-0077-4369-affa-87a46a7311c1_qr4qbfp594vzg!App attempted. Execution state: Attempted activation of the app, 0, The operation completed successfully..
event_1.log
I am unable to install Microsoft.WindowsAppRuntime.1.8 - v8000.616.304.0
Add-AppxPackage : Deployment failed with HRESULT: 0x80073D06, The package could not be installed because a higher version of this package is already installed. Windows cannot install package Microsoft.WindowsAppRuntime.1.8_8000.616.304.0_x64__8wekyb3d8bbwe because it has version 8000.616.304.0. A higher version 8000.642.119.0 of this package is already installed.
I found a workaround. The app is starting when i run it using the .appinstaller file.
VirtualBoxVM_91klVjSbOr.mp4
I found a workaround. The app is starting when i run it using the .appinstaller file.
VirtualBoxVM_91klVjSbOr.mp4
Yes, i resorted to same workaround since yesterday, forgot to mention that sorry. Today i have more computers with the same issue because they finally applied the update of AppInstaller
On my repro, manually installing the latest version of the Windows App Runtime 1.8.2 seems to fix the issue. You can download it from their downloads page (direct link).
If this fixes your issue too, I would think that the cause is a wrong dependency declaration on our side, and that it doesn't show up in the latest Windows because it already comes with that dependency installed.
On my repro, manually installing the latest version of the Windows App Runtime 1.8.2 seems to fix the issue. You can download it from their downloads page (direct link).
If this fixes your issue too, I would think that the cause is a wrong dependency declaration on our side, and that it doesn't show up in the latest Windows because it already comes with that dependency installed.
Does not fix the issue
On my repro, manually installing the latest version of the Windows App Runtime 1.8.2 seems to fix the issue. You can download it from their downloads page (direct link).
If this fixes your issue too, I would think that the cause is a wrong dependency declaration on our side, and that it doesn't show up in the latest Windows because it already comes with that dependency installed.
I tried in a Windows 10 machine and in one with Windows 11 21h2 and it didn't fix the issue. On another machine i updated it to Windows 11 25h2 and the issue went away, so there is a mismatch somewhere but i can pinpoint where.
Any updates on this? I tried to collect some dumps but without success.
I would like to investigate further but i have no ideas.
Are there any updates on this issue? We are receiving a growing number of complaints from customers who are unable to open our applications as a result of this problem.
For now, the only workaround is to launch the application directly via the .appinstaller file, but this is not a workable solution for our customers.
We have confirmed that the application does work for users running Windows build 26100 with the latest App Installer version (1.27.350.0) installed.
However, for all users running earlier Windows builds, even with the same App Installer version (1.27.350.0), the applications still fails to launch.
We are experiencing the same problem, and I want to offer another workaround for this:
On one of the computers starting using the .appinstaller also would not work, so we opted to install the appropriate .msix package without the appinstaller, trading the update mechanism for a convenient and reliable start of the application.
This obviously only works when there are not frequent updates, but from the user perspective it now "works as usual", and hopefully by the time we ship a new version this will be resolved, we just have to remember which computers we did this on and re-install on them with the appinstaller to get updates again.
We are facing the same problem, and have followed a rationale similar to @park-jasper, trading updates for user convenience.
We managed to work around the issue by adjusting the .appinstaller configuration so that the pop-up is never shown. The trade-off is that we can no longer enforce updates through the App Installer, but the apps continue to receive updates in the background.
<UpdateSettings>
<OnLaunch
HoursBetweenUpdateChecks="0" ShowPrompt="false" UpdateBlocksActivation="false" />
<AutomaticBackgroundTask/>
</UpdateSettings>
We're hoping that once the issue is resolved, we will be able to revert the configuration change through an update, without affecting the installations.
@denelon perhaps the title could be updated, since the issue also occurs on Windows 11?
Any news on this? We offer our customers all possible workarounds, but there should be also a fix available.
We're working on a solution. We will release an update for WinGet 1.12 as soon as it's ready.
We will release it as "pre-release" at GitHub when we push it out to Windows Insider Beta / Windows Insider Release Preview. Once we've had enough usage over a couple of days to ensure it's not caused a regression, we'll mark it as a stable release at GitHub and push it out as GA (Generally Available).
We believe the cause of this is microsoft/WindowsAppSDK#3137
The latest version of App Installer has a dependency on the Windows App Runtime framework package. This runtime depends on two other packages, besides the framework package Microsoft.WindowsAppRuntime.1.8. If those two are already installed, everything is good. Otherwise the runtime will try to install them. In older OS builds there is a bug that causes an "access denied" error when trying to deploy a package in specific conditions. App Installer hits this during initialization, which prevents it from launching properly, which in turn prevents apps that use App Installer for an update-on-launch prompt from complete their activation.
dotnet/maui#12080 (comment) offers several mitigations:
- Update the OS to get the bug-fix for the deployment stack. This fully prevents the "access denied" issue.
- Ensure the Windows App Runtime is fully installed. This avoids going into the deployment flow for those dependencies, so we never hit the bug.
To install the runtime there are several options:
- Download and run the installer from the Windows AppSDK downloads page
- Execute App Installer as admin so that it can run the deployment without issues. One way to do this is to create an empty
test.msixand then open it. The package would fail to parse, but App Installer would still launch and be able to install the dependencies. Any following activations should work after this.
The packages we need to have installed are MicrosoftCorporationII.WinAppRuntime.Singleton main MicrosoftCorporationII.WinAppRuntime.Main.1.8. If manually installing the runtime doesn't fix this issue, it would be helpful to know the exact OS build being used (to know if it has the update needed) and the state of the runtime packages.
We are working on a change to App Installer so that it does not need any of these manual mitigations.