[Bug] Error for missing .NET frameworks on ARM64

[denelon]

Describe the bug
I installed Screen To Gif using the Windows Package Manager on an ARM64 device (Surface Pro X). After the install I was prompted about missing .NET. I installed the ARM64 version of the Framework and still received the same error.

To Reproduce
Steps to reproduce the behavior:

1. Run winget install screentogif -s winget or winget install screentogif -s msstore
2. Launch Screen To Gif

Expected behavior
I expected the Screen To Gif to launch.

Screenshots

Desktop (please complete the following information):

PS C:\Users\denelon> winget --info
Windows Package Manager v1.2.10271
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22000.526
Package: Microsoft.DesktopAppInstaller v1.17.10271.0

Additional context
I also attempted to install the x64 version of .NET to resolve the issue, and that still resulted in the same error being displayed.

[denelon]

For reference, this is the version of Screen To Gif I attempted to get working:

PS C:\Users\denelon> winget show screentogif -s winget
Found ScreenToGif [NickeManarin.ScreenToGif]
Version: 2.35.4
Publisher: Nicke Manarin
Publisher Url: https://github.com/NickeManarin/ScreenToGif
Publisher Support Url: https://github.com/NickeManarin/ScreenToGif/issues
Author: Nicke Manarin
Description: This tool allows you to record a selected area of your screen, live feed from your webcam or live drawings from a sketchboard. Afterwards, you can edit and save the animation as a gif, apng, video, psd or png images.
Homepage: https://www.screentogif.com
License: Microsoft Public License (Ms-PL)
License Url: https://raw.githubusercontent.com/NickeManarin/ScreenToGif/master/LICENSE.txt
Installer:
  Type: wix
  Download Url: https://github.com/NickeManarin/ScreenToGif/releases/download/2.35.4/ScreenToGif.2.35.4.Setup.Arm64.msi
  SHA256: e7e4e51e778a8a60f0eb825bfe455fb848b04f6fb56ebc770454fea3fb5520d6

[marswe]

What appears to be happening is that the ARM64 MSI installs the x64 .NET for you rather than ARM64. When you then try to launch the installed ARM64 app, there's no ARM64 .NET and you get the error dialog shown. If the user is installing the ARM64 version of the app, the installer should fetch the ARM64 .NET instead of x64.

Note that a similar issue happens if you use the x86 MSI installer, as it also installs the x64 .NET for you rather than x86.

[NickeManarin]

For x86, the installer was not downloading the correct package.
But as for arm64, the download flow was supposed to be ok.
Unless the architecture detection system is not detecting as arm64.

[NickeManarin]

Can you run dotnet --info to check what's installed?

[denelon]

@NickeManarin sadly, I just have the one ARM64 device and I had to reimage it. Once that's done, I'll work on a solid repro and share the data with you.

[marswe]

This is what you see if you run the ARM64 installer on Windows 11: internally it is detecting the architecture as x64. (If you run it on Windows 10, it detects the architecture as x86.)

I don't see the source code of the installer, but the WixSharp UI is running as an x86 process. That means if it calls GetNativeSystemInfo, the architecture it gets back will be x86 (if Windows 10) or x64 (if Windows 11) for compatibility reasons. To get the true host architecture, it can call IsWow64Process2 instead.

[NickeManarin]

Ohh, thank you for the details!
Do you mind testing these binaries and posting the results here?

Test.zip

Example x86 process running in x64:

[marswe]

Your x86 EXE on Windows 11 on ARM64 returns:

GetNativeSystemInfo:
X64

IsWow64Process2:
Process: I386
Machine: Arm64

You can see that IsWow64Process2 will give you the true host architecture.

[NickeManarin]

@denelon Are you able to run the latest version?
I'm getting some strange issue, the app crashes with a BadImageException, unless I try to scan the Dll's.

dotnet/wpf#6458

[denelon]

I'll see if I can reproduce this.

[denelon]

It said it installed, but it doesn't launch.

[denelon]

@marswe do you have any ideas here?

[marswe]

I see the same problem. If you use the portable ARM64 version and attempt to launch it, you'll get a screentogif process but no window. In the logs you'll see:

► Title -
On dispacher unhandled exception - Unknown
▬ Message -
An attempt was made to load a program with an incorrect format. (0x8007000B)
○ Type -
System.BadImageFormatException
♦ [Version] Date/Hour -
[2.36] 04/28/2022 09:25:28
▲ Source -
PresentationCore
▼ TargetSite -
Void RenderOptions_ForceSoftwareRenderingModeForProcess(Boolean)
► Fuslog -

♠ StackTrace -
at MS.Win32.PresentationCore.UnsafeNativeMethods.MilCoreApi.RenderOptions_ForceSoftwareRenderingModeForProcess(Boolean fForce)
at System.Windows.Media.RenderOptions.set_ProcessRenderMode(RenderMode value)
at ScreenToGif.App.App_Startup(Object sender, StartupEventArgs e) in C:\Users\nicke\source\repos\ScreenToGif\ScreenToGif\App.xaml.cs:line 156
at System.Windows.Application.OnStartup(StartupEventArgs e)
at System.Windows.Application.<.ctor>b__1_0(Object unused)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

It appears to be failing to load the d3dcompiler_47.dll from its own temp directory, but I couldn't tell you why. Let me see if I can get some eyeballs on this internally.

[NickeManarin]

Someone else pointed that it could be related to this: dotnet/wpf#5747
I got to try out with .NET 7.
But if that's not solvable with .NET 6, I'll have to drop support for arm64 for now.

[NickeManarin]

Strange that when trying to find what was going on, running some tests, checking each assembly with Assembly.GetName() (in case some was clearly not supposed to be there), the app worked normally.

[NickeManarin]

Runs ok with .NET 7.