microsoft-ui-xaml
microsoft-ui-xaml copied to clipboard
Copilot+ ARM64 : System.BadImageFormatException: at is not a valid Win32 application.
Describe the bug
System.BadImageFormatException: at is not a valid Win32 application.
My app is compiled and packaged for ARM64.
Yet a customer installed the ARM64 version from the MS Store, but the app crash on start with the message above in the Logs.
Steps to reproduce the bug
Install an ARM64 app from the MS Store on a Copilot+ laptop.
Expected behavior
The app should work, just like apps on the Apple, Android, Linux , PS, Nintendo and Xbox stores.
Screenshots
No response
NuGet package version
WinUI 3 - Windows App SDK 1.5.5: 1.5.240627000
Windows version
Windows 11 (22H2): Build 22621
Additional context
No response
Error from the LOG
Application: myapp.exe
CoreCLR Version: 7.0.1724.11508
.NET Version: 7.0.17
Description: The process was terminated due to an unhandled exception.
Exception Info: System.TypeInitializationException: The type initializer for 'WinRT.ActivationFactory1' threw an exception. ---> System.BadImageFormatException: is not a valid Win32 application. (0x800700C1) at System.Runtime.InteropServices.Marshal.ThrowExceptionForHR(Int32 errorCode) at WinRT.BaseActivationFactory..ctor(String typeNamespace, String typeFullName) at WinRT.ActivationFactory1..ctor()
at WinRT.ActivationFactory1..cctor() --- End of inner exception stack trace --- at WinRT.ActivationFactory1.As(Guid iid)
at Microsoft.Windows.AppLifecycle.AppInstance.Make___objRef_global__Microsoft_Windows_AppLifecycle_IAppInstanceStatics()
at Microsoft.Windows.AppLifecycle.AppInstance.get__objRef_global__Microsoft_Windows_AppLifecycle_IAppInstanceStatics()
at Microsoft.Windows.AppLifecycle.AppInstance.GetCurrent()
at myapp.Program.isOpenNewInstance()
at myapp.Program.Main(String[] args)
Faulting application name: myapp.exe, version: 4.5.0.0, time stamp: 0x65ce0000 Faulting module name: KERNELBASE.dll, version: 10.0.26100.1301, time stamp: 0x0780347f Exception code: 0xe0434352 Fault offset: 0x00000000001ae0d8 Faulting process id: 0x8320 Faulting application start time: 0x1DAECE781C9B78D Faulting application path: C:\Program Files\WindowsApps\myappSolutionsinc.myapp_4.5.0.0_arm64__efag6vr1nbgqc\myapp.exe Faulting module path: C:\Windows\System32\KERNELBASE.dll Report Id: 9ae688fc-2ef3-4328-93d6-d035c962eee4 Faulting package full name: myappSolutionsinc.myapp_4.5.0.0_arm64__efag6vr1nbgqc Faulting package-relative application ID: App
The log hints at this happening around AppInstance.GetCurrent. But in a test application, I don't see it happening.
https://github.com/user-attachments/assets/3fb1f46c-fe53-496b-8ab3-cef0b483e53c
As you can see through Visual Studio, the ARM64 versions of the libraries are loading when I call AppInstance.GetCurrent. So this doesn't seem to happen naturally. What does your application's code around that point?
Also, it is possible that the log has lost information. The way it is starting and stopping code blocks indicates that the log has backticks ` in it. This would mean that there is some generics in the log. The .NET metadata uses the backtick for that purpose. Could you check that the log hasn't lost any generic information, like any generic parameters for WinRT.ActivationFactory?
Sadly your video does not load.
Upgraded the project manually to .net8 and updated everything (framework and vs studio). Thanks for the info, will investigate further, but it looks like the ARM64 app is trying to load something that is not ARM64.
No wonder that the biggest and hottest project on the internet do not and may never have a windows version : ladybird (the next browser) and zed (the next vs code). I should not have to fight for everything. MS tools should do their job like Xcode and Android Studio do.
Steve Balmer loved the developers and MS were the best 15 years ago for developers, now they are the worst. At 62% of the desktop market and going down every months, Windows must treat the remaining developers with respect.
Because our 30 000 customers are complaining that the Windows version is inferior to the Apple one and right now, our app made for ARM does not run at all on the latest ARM Copilot laptops. When I publish the app on the MS Store, aren't they supposed to test the app like Apple does before releasing it?
Debugging with loader snaps enabled should find which binary is trying to be loaded with the incorrect format:
- Get a copy of the ARM64 version of gflags.exe, such as from the Windows SDK.
- In an Admin command prompt, run
gflags.exe /i myapp.exe +slsto show loader snaps. - Launch the app under a native debugger. (Launching from Visual Studio with "Enable native code debugging" enabled works for this. Another option is using WinDbg, using the "Launch app package" option if it is a packaged app or "Launch executable" if unpackaged.)
The loader snaps will spew a lot of information to the debug output as it is searching for and loading dlls. Hopefully this will show which dll failed to load when the invalid format error was hit.
I updated my app to .net 8.0 with the latest build tools and sdk Another customer called me because the app does not start on his Lenovo copilot+
How is it possible that I did everything exactly like MS wanted : Use only their WinUI3/Win32/WindowsAppSdk and compiled to arm64 with the latest VS Studio, the app was once again approved by the MS store employees who are supposed to test the app and yet it does not work. But these old apps from the 90's compiled in x86 32 bits are running????
Wake up MS!!!! Fix your s... you are destroying your customers confidence in your copilot+ thing (and also me the dev).
I don't have an overpriced Copilot+ Laptop, so I cannot test on it. I can only check for the error in the MS log.
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Application Error" Guid="{a0e9b465-b939-57d7-b27d-95d8e925ff57}" />
<EventID>1000</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>100</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="2024-08-20T18:40:48.0379956Z" />
<EventRecordID>6494</EventRecordID>
<Correlation />
<Execution ProcessID="19016" ThreadID="13048" />
<Channel>Application</Channel>
<Computer>LAPTOP-GHSG3R51</Computer>
<Security UserID="S-1-5-21-1990869147-377657909-4233791675-1001" />
</System>
- <EventData>
<Data Name="AppName">myapp.exe</Data>
<Data Name="AppVersion">7.6.5.0</Data>
<Data Name="AppTimeStamp">66960000</Data>
<Data Name="ModuleName">KERNELBASE.dll</Data>
<Data Name="ModuleVersion">10.0.26100.1455</Data>
<Data Name="ModuleTimeStamp">f4a3a16d</Data>
<Data Name="ExceptionCode">e0434352</Data>
<Data Name="FaultingOffset">00000000001ae0d8</Data>
<Data Name="ProcessId">0x49a4</Data>
<Data Name="ProcessCreationTime">0x1daf330791e5027</Data>
<Data Name="AppPath">C:\Program Files\WindowsApps\myappSolutionsinc.myapp_7.6.5.0_arm64__efag6vr1nbgqc\myapp.exe</Data>
<Data Name="ModulePath">C:\Windows\System32\KERNELBASE.dll</Data>
<Data Name="IntegratorReportId">f1e2ba5a-6a80-4623-8eb0-b73717c3a08b</Data>
<Data Name="PackageFullName">myappSolutionsinc.myapp_7.6.5.0_arm64__efag6vr1nbgqc</Data>
<Data Name="PackageRelativeAppId">App</Data>
</EventData>
</Event>
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name=".NET Runtime" />
<EventID Qualifiers="0">1026</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2024-08-20T18:40:47.8968712Z" />
<EventRecordID>6493</EventRecordID>
<Correlation />
<Execution ProcessID="18852" ThreadID="0" />
<Channel>Application</Channel>
<Computer>LAPTOP-GHSG3R51</Computer>
<Security />
</System>
- <EventData>
<Data>Application: myapp.exe CoreCLR Version: 8.0.824.36612 .NET Version: 8.0.8 Description: The process was terminated due to an unhandled exception. Exception Info: System.TypeInitializationException: The type initializer for 'WinRT.ActivationFactory`1' threw an exception. ---> System.BadImageFormatException: is not a valid Win32 application. (0x800700C1) 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.As(Guid iid) at Microsoft.Windows.AppLifecycle.AppInstance.Make___objRef_global__Microsoft_Windows_AppLifecycle_IAppInstanceStatics() at Microsoft.Windows.AppLifecycle.AppInstance.get__objRef_global__Microsoft_Windows_AppLifecycle_IAppInstanceStatics() at Microsoft.Windows.AppLifecycle.AppInstance.GetCurrent() at myapp.Program.isOpenNewInstance() at myapp.Program.Main(String[] args)</Data>
</EventData>
</Event>
.```
Update : All our customers who bought a Windows Copilot+ have returned it to the store because our Windows ARM64 app does not run on Copilot+ laptops. And now we tell our customers that our Windows ARM64 app (approved by MS on the MS App Store) does not run on Copilot+ Windows PC. Its a good thing that our 20 000+ customers are moving away from Windows to macOS, iOS and Android (Chromebook) everyday. Note that our customers must use our app to work, otherwise they can't work at all.
Once again MS has abandoned support for their own products right after releasing them (exactly like Windows Mixed Reality). Since we are the only one in the world making app for modern Windows and modern Hardware and MS does not want to help us, we may have to abandon the Windows version of our app and ask users to install the Android version on their Windows 11.
Warning, do no buy Windows Copilot+ laptops, they are not even compatible with apps made specifically for them.
So I got a Windows ARM to test and the problem was that I needed to set the target in the xml project settings to arm64. Now the app run on my Windows ARM, but once on the MS App Store and installed by the MS App Store, the app crash on start again. We have no choice to tell our users not to buy a Copilot+ laptop for now. The MS Tools and MS Store do not work for ARM. It has nothing to do with the code, maybe an obscure project setting in hidden xml files??? I guess people who still use Windows in 2024 kind of deserve the Microsoft Experience. And these idiots even got rid of the Android sub-system. Hey Windows users : you made your bed, you sleep in it.
Debugging with loader snaps enabled should find which binary is trying to be loaded with the incorrect format:
- Get a copy of the ARM64 version of gflags.exe, such as from the Windows SDK.
- In an Admin command prompt, run
gflags.exe /i myapp.exe +slsto show loader snaps.- Launch the app under a native debugger. (Launching from Visual Studio with "Enable native code debugging" enabled works for this. Another option is using WinDbg, using the "Launch app package" option if it is a packaged app or "Launch executable" if unpackaged.)
The loader snaps will spew a lot of information to the debug output as it is searching for and loading dlls. Hopefully this will show which dll failed to load when the invalid format error was hit.
Please follow these instructions to get more info on where the failure is coming from. This way, we can better assist you.
I just don't have time to work on that for now, maybe in a few months.
The reality is that a WinUI3 project compiled for ARM will run on an ARM windows, but once downloaded from the store, it crashes on start without a single line of code being executed. So I removed the ARM version from the store and now the x64 get installed on ARM computers and for now, that is good enough for the inferior windows platform.
This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment.