Packaged WinUI 3 app can only p/invoke local DLLs on ARM when run as Admin

[wbokkers]

Describe the bug

We have issues with our packaged x64 WinUI3 app when running on ARM64. This app runs without any issues on x64.

P/Invoke to DLLs in the application folder does not work, unless the app is started as Administrator.

The app runs with full trust (as it is a WinUI 3 packaged app).

I tried to target as arm64 as well, but this gave me even more issues. Running as administrator did not help solve the issue in this case.

Steps to reproduce the bug

1. Install Xelion on an ARM device from this installer: https://appinstaller.xelion.com/winapp/v8n/Xelion-Package.appinstaller
2. Run Xelion
3. Enter credentials (if Microsoft reaches out, I can supply test credentials)
4. The app crashes on trying to p/invoke into the local dlls (sipdll.dll)

To successfully run the app, run Xelion as Administrator.

Expected behavior

The app should be able to p/invoke DLLs from the installation folder without the need for Admin privileges.

Screenshots

No response

NuGet package version

WinUI 3 - Windows App SDK 1.4.5: 1.4.240411001

Windows version

Windows 11 (22H2): Build 22621

Additional context

No response

[github-actions[bot]]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one. Thank you!

Closed similar issues:

• WinUI 3 App fails to start with missing dll message (#5660), similarity score: 0.72

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[wbokkers]

I have more information. When running the app as a normal (non Admin) user, the x64 DLL cannot load. I get the following exception:

System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (0x8007000B)

But as soon as the app runs as Admin, the DLL loads without any issue. The image format of the dll is the same for admin or normal users (obviously), so this error message is very strange.

[DarranRowe]

Have you tried doing the same thing with an application compiled for ARM64? I appreciate that the library you are trying to load may not have an ARM64 equivalent, so having a smaller test would be useful. Also, have you checked the ACL on the DLL that you are trying to load? Just to be sure that Windows didn't somehow mangle the DACL when the package was installed.

[wbokkers]

@DarranRowe Yes, I did try to build for ARM64, but the DLLs remain x64, so this does not work either. I did not check the ACL/DACL, I never do and I can't remember having issues with it in the 30 years I work on Windows. The installed package works just fine on x64 machines and I cannot imagine that the installation is somehow different on ARM-systems, but who knows.

I looked into the access permissions. For that I had to take ownership of the WindowsApps folder. Now I have full control to all the files. But unfortunately this does not solve this issue. I saw that the Users access control entry for adding conditions is corrupt, according to Windows. I am not sure what that means, but I don't think it is important, since I have full access as the logged in user to all binaries.

Tl;dr: even with full access rights to all installation files, I get the same behavior: I need to run the app as Admin before it can P/invoke into DLLs.

[DarranRowe]

I have been testing things related to this, and I have not been getting any kind of reproduction. On a Surface Pro X, I have tried getting a basic WinUI 3 application to platform invoke a test DLL. I even went as far as testing WinForms and using LoadLibrary in C++ applications. All of these have no issues with using a DLL in the same directory as the application. Right now, all I can ask is, are you sure that it isn't that sipdll.dll that is the problem? The x64 environment on an ARM64 device has some quirks. One example is that if you query the hardware that it is running on, Windows will tell you that it is ARM64, not x64. It could also be that an object that the DLL requires access to restricts it to Administrators when you are running under Windows on ARM64, but allows Users when running under Windows on x64. There could also be some other subtle difference, like developer mode. Have you tried totally taking WinUI 3 and .NET out of the equation, and have a console C++ application try to use LoadLibrary to access that DLL?

[wbokkers]

Hi @DarranRowe, thank you for taking the time looking into this. I tried the same with another DLL and this works without any issues on arm64.

I got the System.BadImageFormatException when using .NET for arm64 combined with a x64 DLL.

I turns out the issue has to do with the windows.toastNotificationActivation extension. This does crash on arm64 when not running as administrator.

Sorry for the misleading information. I will close this issue and will open another one.