microsoft
Windows 10/11 - App installed via *.appinstaller wont start anymore under Windows 10/11
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?
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, Status
You 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
AppInstaller-2025-10-31-11-39-15.135.zip
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.
https://github.com/user-attachments/assets/ed7ed3a6-1e30-457e-b231-bc87484745c0
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 https://github.com/microsoft/WindowsAppSDK/issues/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.
https://github.com/dotnet/maui/issues/12080#issuecomment-1398635826 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.
This is fixed in the latest version, build 1.27.420. It is currently available for Windows Insiders in the Beta channel, or you can download it from the Releases page in this repo.
This is fixed in the latest version, build 1.27.420. It is currently available for Windows Insiders in the Beta channel, or you can download it from the Releases page in this repo.
I installed this fix locally on my machine, however, app installer is still crashing when our C# application programatically launches a downloaded bundle via Process.Start. If this is considered a different bug let me know and I can open a different issue for tracking.
My Machine Details
Windows Build: 22631.6060
Windows SDK:
Results from the following command do seem to list the couple packages you mentioned in a previous post.
(get-appxpackage microwinappruntime*).packagefullname
AppInstaller.exe crash from event log
Faulting application name: AppInstaller.exe, version: 1.27.420.0, time stamp: 0x69129eb8
Faulting module name: Microsoft.UI.Xaml.dll, version: 3.1.8.0, time stamp: 0x2239de89
Exception code: 0xc000027b
Fault offset: 0x000000000039dce5
Faulting process id: 0x0xB7DC
Faulting application start time: 0x0x1DC53EA27D98003
Faulting application path: C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.27.420.0_x64__8wekyb3d8bbwe\AppInstaller.exe
Faulting module path: C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.8_8000.642.119.0_x64__8wekyb3d8bbwe\Microsoft.UI.Xaml.dll
Report Id: 0866af73-55a3-4486-8244-fa3379c825b7
Faulting package full name: Microsoft.DesktopAppInstaller_1.27.420.0_x64__8wekyb3d8bbwe
Faulting package-relative application ID: App
This can be reproduced by creating a basic winexe app and attempting to launch a bundle. Please note Process.Start seems to work for a console application but the bug happens for winexe apps.
Net Framework csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>WinExe</OutputType>
<TargetFramework>net472</TargetFramework>
<PlatformTarget>x64</PlatformTarget>
</PropertyGroup>
</Project>
Program.cs
using System.Diagnostics;
namespace NetFrameworkAppInstallerBug
{
internal class Program
{
static void Main(string[] args)
{
var installerPath = ""; // Set path to msix, msixbundle, or appxbundle on your machine
Process.Start(installerPath);
}
}
}
This also happens in a .Net 8 application.
.Net 8 csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>WinExe</OutputType>
<TargetFramework>net8.0</TargetFramework>
<PlatformTarget>x64</PlatformTarget>
</PropertyGroup>
</Project>
Program.cs
using System.Diagnostics;
using System.IO;
namespace AppInstallerBug
{
internal class Program
{
static void Main(string[] args)
{
var installerPath = ""; // Set path to msix, msixbundle, or appxbundle on your machine
var appxBundleName = Path.GetFileName(installerPath);
var directory = Path.GetDirectoryName(installerPath);
Process p = new Process();
p.StartInfo.WorkingDirectory = string.IsNullOrEmpty(directory) ? Path.GetTempPath() : directory;
p.StartInfo.FileName = appxBundleName;
p.StartInfo.Verb = "Open";
p.StartInfo.WindowStyle = ProcessWindowStyle.Normal;
p.StartInfo.UseShellExecute = true;
p.Start();
}
}
}
Right now this bug is preventing us from pushing additional app updates out as it'll cause pain for our clients. Any guidance or workarounds for this issue would be appreciated.
This is fixed in the latest version, build Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle. It is currently available for Windows Insiders in the Beta channel, or you can download it from the Releases page in this repo.
Still not able to run my installed app. AppInstaller v1.27.420.0. Same problem: "If i try to start an app i can see the Appinstaller appearing in taskbar for a milisecond and then nothing happens." Previous version of the AppInstaller v1.26.510.0 works fine.
Just so you know, this is a full-scale issue. Even at our level, it could potentially affect hundreds of organizational customers and thousands of users.
This is fixed in the latest version, build 1.27.420. It is currently available for Windows Insiders in the Beta channel, or you can download it from the Releases page in this repo.
I installed this fix locally on my machine, however, app installer is still crashing when our C# application programatically launches a downloaded bundle via Process.Start. If this is considered a different bug let me know and I can open a different issue for tracking.
My Machine Details
Windows Build: 22631.6060
Windows SDK:
Results from the following command do seem to list the couple packages you mentioned in a previous post. (get-appxpackage micro_win_appruntime*).packagefullname
AppInstaller.exe crash from event log
Faulting application name: AppInstaller.exe, version: 1.27.420.0, time stamp: 0x69129eb8 Faulting module name: Microsoft.UI.Xaml.dll, version: 3.1.8.0, time stamp: 0x2239de89 Exception code: 0xc000027b Fault offset: 0x000000000039dce5 Faulting process id: 0x0xB7DC Faulting application start time: 0x0x1DC53EA27D98003 Faulting application path: C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.27.420.0_x64__8wekyb3d8bbwe\AppInstaller.exe Faulting module path: C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.8_8000.642.119.0_x64__8wekyb3d8bbwe\Microsoft.UI.Xaml.dll Report Id: 0866af73-55a3-4486-8244-fa3379c825b7 Faulting package full name: Microsoft.DesktopAppInstaller_1.27.420.0_x64__8wekyb3d8bbwe Faulting package-relative application ID: AppThis can be reproduced by creating a basic winexe app and attempting to launch a bundle. Please note Process.Start seems to work for a console application but the bug happens for winexe apps.
Net Framework csproj
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>WinExe</OutputType> <TargetFramework>net472</TargetFramework> <PlatformTarget>x64</PlatformTarget> </PropertyGroup> </Project>Program.cs
using System.Diagnostics; namespace NetFrameworkAppInstallerBug { internal class Program { static void Main(string[] args) { var installerPath = ""; // Set path to msix, msixbundle, or appxbundle on your machine Process.Start(installerPath); } } }This also happens in a .Net 8 application.
.Net 8 csproj
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>WinExe</OutputType> <TargetFramework>net8.0</TargetFramework> <PlatformTarget>x64</PlatformTarget> </PropertyGroup> </Project>Program.cs
using System.Diagnostics; using System.IO; namespace AppInstallerBug { internal class Program { static void Main(string[] args) { var installerPath = ""; // Set path to msix, msixbundle, or appxbundle on your machine var appxBundleName = Path.GetFileName(installerPath); var directory = Path.GetDirectoryName(installerPath); Process p = new Process(); p.StartInfo.WorkingDirectory = string.IsNullOrEmpty(directory) ? Path.GetTempPath() : directory; p.StartInfo.FileName = appxBundleName; p.StartInfo.Verb = "Open"; p.StartInfo.WindowStyle = ProcessWindowStyle.Normal; p.StartInfo.UseShellExecute = true; p.Start(); } } }Right now this bug is preventing us from pushing additional app updates out as it'll cause pain for our clients. Any guidance or workarounds for this issue would be appreciated.
I have the same issue has you with the same error. My only work around is executing manually the MSIX file.
Any updates on this? It is becoming a significant problem for our release cycle, and I get the impression that the scale of this issue is being underestimated. More than four hundred of our customers are already experiencing this, and the number is still increasing.
The engineering team is investigating the issue. As soon as we have any updates, we'll share them.
This is impacting a non-trivial amount of users for our AppInstaller which has generally worked fine up until now. Currently both new and existing users are finding that launching the app is broken. This is a particularly bad experience given Windows does not present an error so it appears to the user that this is an issue with our application.
This is a P0 issue that is materially affecting our business.
