DeploymentAgent.exe crashing when calling DeploymentManager::Initialize() on Windows 10
triplef opened this issue · 16 comments
Describe the bug
Launching a packaged app using the Windows App SDK v1.1 or v1.2 on Windows 10, which calls DeploymentManager::Initialize() on launch, results in DeploymentAgent.exe crashing and the following deployment result in the app if the machine does not already have the Main and Singleton packages installed:
- using Windows App SDK v.1.1:
0xc0000409(Report-v1.1.wer.txt) - using Windows App SDK v.1.2:
0x80070005(Report-v1.2.wer.txt)
The issue is not reproducible when launching the app on Windows 11.
The app launches correctly if the Windows App SDK from here is installed before.
Additional information in discussion #3125.
Steps to reproduce the bug
- Create an app with the Windows App SDK calling the DeploymentManager like this from its main() function on launch:
DeploymentInitializeOptions deploymentOptions;
auto deploymentResult{ DeploymentManager::Initialize(deploymentOptions) };
if (deploymentResult.Status() != DeploymentStatus::Ok) {
const HRESULT hr{ deploymentResult.ExtendedError().value };
wprintf(L"Error 0x%X initializing Windows App SDK\n", hr);
return hr;
}- Add the following dependency in its AppxManifest:
<PackageDependency Name="Microsoft.WindowsAppRuntime.1.2" MinVersion="2000.677.1750.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />- Create an MSIX from the app.
- Install the MSIX on a machine running Windows 10 which has no Windows App SDK packages installed (run
get-appxpackage micro*win*appruntime* | remove-appxpackagebefore).
Expected behavior
- The
Microsoft.WindowsAppRuntime.1.2package is installed during installation of the MSIX ✅ - The additional Main and Singleton packages are installed when the app is launched ❌
DeploymentManager::Initialize()returnsDeploymentStatus::Ok❌
NuGet package version
1.2.221109.1
Packaging type
Packaged (MSIX)
Windows version
Windows 10 version 22H2 (19045, 2022 Update)
IDE
Other
Additional context
Reproduced on various Windows 10 machines running Windows versions 21H2 and 22H2.
Event Viewer does not contain any error diagnostics in the categories listed here. Windows Logs > Application lists the crash of DeploymentAgent.
This is a known issue in the Windows 10 OS and not an issue with the WinAppSDK. The fix in Windows 10 OS is anticipated to be serviced on 3rd Tuesday of Jan 2023 as an OnDemand update patch and on 2nd Tuesday of Feb 2023 in an Auto update security patch.
Thanks for the info @sachintaMSFT!
Is there any workaround for this that we could employ, or how are other users of the WinAppSDK dealing with this? It seems like it would completely block usage of the WinAppSDK on Windows 10. How come we are we the first ones reporting this here?
Otherwise will there be a way for us to restrict our app to machines that have the patch installed?
I think I'm hitting this issue with a quite few users on Windows 10, but I'm not too sure why it's only for some...
This is WinUI C#, .NET 6
I'm wondering if the Windows App SDK installed via sideload is updating via Microsoft Store, which then breaks Windows 10 apps. I've had a few cases now of users updating to a newer version of an application, where WinAppSDK is already updated. The app does not launch.
But if users install the Windows App SDK manually, everything works again. I wonder if the Windows App SDK installer is registering the main and singleton package, but the Windows Update method does not?
@triplef Any luck?
Tested this flow, not the case. I might have a different issue here maybe (like maybe the newer version of the Windows App SDK packages are staged, but not installed? causing the app to not launch)
I should mention I'm not specifically calling any of these APIs, I simply have a C# app, which calls XamlCheckProcessRequirements within the program file. I'm thinking related to #3228
This is a known issue in the Windows 10 OS and not an issue with the WinAppSDK. The fix in Windows 10 OS is anticipated to be serviced on 3rd Tuesday of Jan 2023 as an OnDemand update patch
Does KB5019275 (OS Builds 19042.2546, 19044.2546, and 19045.2546) Preview fixes it?
Installing the latest system updates on Windows 10 seems to fix this for us, as promised above. 🙏
@sachintaMSFT can you tell us which update exactly fixed this, and is there a way we can add a requirement for it in our installer? I guess otherwise we’d just tell users to run Windows Update of SDK initialization fails.
@sachintaMSFT can you tell us which update exactly fixed this, and is there a way we can add a requirement for it in our installer?
19045.2604 fixed it. Query the UBR value to detect the patchlevel
Thanks @MagicAndre1981! So just to confirm, we read the UBR value and tell the user to run Windows Update if it’s < 2604 and we’re getting error 0x80070005 from DeploymentManager::Initialize() (using WinAppSDK 1.2 or later)?
correct. Read the value and if it is too old, tell them to run Windows Update.
Fix release timeline
The fix for this issue in Windows 10 OS has been released in February patch update on Feb 14th, 2023 (https://support.microsoft.com/en-us/topic/february-14-2023-kb5022834-os-builds-19042-2604-19044-2604-and-19045-2604-ffb56254-3fee-44f1-9574-b8a0c19bde77).The Windows 10 devices should be auto updated without any input from the user (assuming the device had chance to be connected to the network). To verify if a Windows 10 device has the fix, check that the build revision >= 2604 by running winver.exe
The Windows 10 device has the update with the fix. But when does the fix take affect on it ?
Once a Windows 10 device is updated with the fix, the fix takes effect when a WinAppSDK framework package is installed or updated or provisioned on the device. To check whether the fix took affect on the device, run the following Powershell command line and then check to see that "Mandatory Label\Low Mandatory Level:(I)(NW)" is NOT listed in the output.
Powershell (get-appxpackage *WindowsAppRuntime*).InstallLocation | ForEach-Object { icacls $_ }
If the WinAppSDK framework package is already installed prior to the Windows 10 device received the update with the fix, then it needs to be uninstalled and deprovisioned (only if it was provisioned on the device which is the case if WindowsAppRuntimeInstaller.exe was used to install WinAppSDK framework package) followed by a re-install.
We are unfortunately still seeing many of our users running into this on Windows 10 installations with build revisions >= 2604. @sachintaMSFT as you explained this can happen if the fix did not take effect.
We’re trying to figure out how to deal with this scenario on user machines. We have a large user base, and we cannot realistically tell them to run some PowerShell commands to fix this manually. Additionally, as far as I’m aware all apps depending on the WinAppSDK need to be uninstalled before the SDK packages themselves can be uninstalled, which could also mean users need to backup and later restore app-specific data as part of the process, making this potentially very involved for individual users.
Is there anything we or you can do to fix this programmatically? I think in an ideal world the deployment manager should deal with this automatically (e.g. force-uninstalling and reinstalling the SDK as part of the deployment). Alternatively would it be possible for Microsoft to offer a sort of installer we can direct users to for fixing the issue on their machines?
As-is, developers can unfortunately not rely on the Windows App SDK to work on user machines.
@DrusTheAxe @MagicAndre1981 @sachintaMSFT any thoughts on the above?
Without a user-deployable solution to this I don’t think developers can rely on the Windows App SDK for any customer-facing app where they don’t control the machines the app is being deployed on (e.g. published via Microsoft Store).
Why is this issue marked closed? Does it have a fix.
We have been developing a MAUI app and ready for deployment. Everything works fine in VS2022. But the moment you run it outside of VS, this error occurs.
dotnet Zoey.Market.App.dll
Unhandled exception. System.TypeInitializationException: The type initializer for '<Module>' threw an exception.
---> System.TypeInitializationException: The type initializer for 'WinRT.ActivationFactory`1' threw an exception.
---> System.Runtime.InteropServices.COMException (0x80040154): Class not registered (0x80040154 (REGDB_E_CLASSNOTREG))
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHR(Int32 errorCode)
at WinRT.BaseActivationFactory..ctor(String typeNamespace, String typeFullName)
at WinRT.ActivationFactory`1..ctor()
at WinRT.ActivationFactory`1..cctor()
--- End of inner exception stack trace ---
at WinRT.ActivationFactory`1.ActivateInstance[I]()
at Microsoft.Windows.ApplicationModel.WindowsAppRuntime.DeploymentInitializeOptions..ctor()
at Microsoft.Windows.ApplicationModel.WindowsAppRuntime.DeploymentManagerCS.AutoInitialize.get_Options()
at Microsoft.Windows.ApplicationModel.WindowsAppRuntime.DeploymentManagerCS.AutoInitialize.AccessWindowsAppSDK()
at .cctor()
--- End of inner exception stack trace ---
I'm still getting this issue any time Maui is involved.
Win 11 (10.00.22000.0653)
Visual Studio 2022 (17.12.3)
.Net 8.0.111
All I need to do is create a basic project with Maui. It builds within VS fine. Published projects won't even run on the system in which I built them.
I'm still getting this issue any time Maui is involved. Win 11 (10.00.22000.0653)
this is an old and outdated Windows 11 version. Update to at least Windows 11 23H2