Windows AI APIs do not work in x64 Apps packaged with external location

[ULTRON-MARK]

Describe the bug

I want to use Windows AI APIs in my x64 desktop app, so I need a package identity. I chose to Grant package identity by packaging with external location, but I found that it cannot run and throws an ERROR_BAD_EXE_FORMAT exception. However, arm64 programs work fine (Perhaps it's because my computer uses the arm64 architecture). In addition, packaged Apps work fine for both arm64 and x64 architectures.

Steps to reproduce the bug

1. In Visual Studio, create a new C++ console application project.
2. Install Nuget package: Microsoft.WindowsAppSDK, Microsoft.Windows.CppWinRT.
3. Follow this tutorial to grant package identity by manually packaging with an external location.
4. Write a simple Demo code:

#include <iostream>
#include <winrt/Microsoft.Graphics.Imaging.h>
#include <winrt/Microsoft.Windows.AI.Imaging.h>
#include <winrt/Windows.Foundation.h>
#include <winrt/Windows.Graphics.Imaging.h>
#include <winrt/Windows.Storage.Streams.h>

bool IsTextRecognizerReady() {
  using namespace winrt::Microsoft::Windows::AI;
  auto ready_state = Imaging::TextRecognizer::GetReadyState();
  if (ready_state == AIFeatureReadyState::Ready ||
      ready_state == AIFeatureReadyState::NotReady) {
    if (ready_state == AIFeatureReadyState::NotReady) {
      auto result = Imaging::TextRecognizer::EnsureReadyAsync().get();
      if (result.Status() != AIFeatureReadyResultState::Success) {
        return false;
      }
    }
  } else {
    return false;
  }
  return true;
}

int main() {
  if (IsTextRecognizerReady()) {
    std::cout << "TextRecognizer is ready." << std::endl;
  } else {
    std::cout << "TextRecognizer is not ready" << std::endl;
  }
  getchar();
}

5. Select Solution Platform as x64, then compile and launch the application.

Expected behavior

It runs normally without throwing any exceptions.

Screenshots

The image below is a screenshot of the application running with the Solution Platform set to arm64:

However, an exception is thrown when set to x64, as shown in the image below:

NuGet package version

Windows App SDK 1.8.5: 1.8.260209005

Packaging type

Unpackaged

Windows version

Insider Build (xxxxx)

IDE

Visual Studio 2022

Additional context

• Device: Microsoft Surface Laptop, 7th Edition
• OS: Windows Insider Preview, 25H2 (26220.8062)
• CPU: Snapdragon(R) X 12-core X1E80100 @ 3.40 GHz (3.42 GHz)
• NPU: Snapdragon(R) X Elite - X1E80100 - Qualcomm(R) Hexagon(TM) NPU

[DrusTheAxe]

Does your project include a Fusion manifest declaring the <msix> element? I suspect that's the root cause.

3. Follow this tutorial to grant package identity by manually packaging with an external location.

I didn't see a step 3.5 Install WinAppSDK -- run windowsappruntimeinstaller.exe or at least register the winappsdk Framework package. I suspect this is an omission in the repro steps as the Bootstrap autoinitializer (probably) was included in the exe so failure to find the registered package would be an error in a global constructor i.e. before calling into main().

It runs normally without throwing any exceptions.

#1 How did you 'run' the app? Did you click its tile in the Start Menu? CreateProcess() on the .exe in the External Location? AAM->ActivateApplication(aumid)?Other?

#2 Does your project include a Fusion manifest declaring <msix...>?

#3 Is that package registered for the user? Get-AppxPackage lists packages registered for the user

#4 Does your appxmanifest.xml declare a static dependency (ie <PackageDependency>) on the WinAppSDK framework package?

#5 Are you built for WinAppSDK/MSIX or WinAppSDK/SelfContained? If WinAppSDK/MSIX then WinAppSDK's framework package must be registered for the user (#3=Yes)

#6 If building targeting WinAppSDK/MSIX did you disable the WinAppSDK Bootstrap AutoInitializer?

If you're built for WinAppSDK/MSIX then, by default, <WindowsAppSdkBootstrapInitialize> should be undefined, the nuget's build logic sets it to true and WindowsAppRuntimeAutoInitializer.cpp will be compiled and linked into your .exe to automagically call MddBootsrapInitialize*() when your process starts.

If launching via StartMenu or other system paths (filetypeassociations, etc) it amounts to activation via identity (eg AAM->ActivateApplication). This requires the package is registered for the user. If the package isn't registered for the user you'll get an error.

If launching via the executable in the ExternalLocation (CreateProcess("c:\foo\bar.exe"...), ShellExecute(), double-click the .exe in Explorer, etc) then the package must be registered for the user AND the exe must contain a Fusion manifest with the <msix...> element. If the exe has no Fusion manifest, or has a Fusion manifest w/o <msix>, or has a Fusion manifest with <msix> but the package isn't registered for the user then the process is created but without package identity.

You can add a few lines of code to the start of main() to help diagnose why you're failing

...
#include <appmodel.h>

int main() {
  WCHAR packageFullName[PACKAGE_FULL_NAME_MAX_LENGTH + 1]{};
  UINT32 n{ ARRAYSIZE(packageFullName) };
  auto rc{ ::GetCurrentPackageFullName(&n, packageFullName)) };
  wprintf(L"GetPackageFullName: 0x%08X => %ls\n", rc, packageFullName);

  WCHAR applicationUserModelId[APPLICATION_USER_MODEL_ID_MAX_LENGTH]{};
  UINT32 n{ ARRAYSIZE(applicationUserModelId) };
  rc = ::GetCurrentApplicationUserModelId(&n, applicationUserModelId));
  wprintf(L"GetApplicationUserModelId: 0x%08X => %ls\n", rc, applicationUserModelId);

  UINT32  bufferLength{};
  UINT32  count{};
  rc = ::GetCurrentPackageInfo(flags, &bufferLength, nullptr, &count);
  wprintf(L"GetCurrentPackageInfo: 0x%08X => Count=%u\n", rc, count);

  if (IsTextRecognizerReady()) {
  ...
  return 0;   //P.S. main's declared as returning int but the example code doesn't end with a return N
}

If all is well then the process should be created with package+application identity. GetCurentPackageFullName and GetCurrentApplicationUserModelId should return ERROR_SUCCESS (0) and their respective string values. Likewise, GetCurrentPackageInfo should return ERROR_SUCCESS (0) and count =1 (or 1+N, if your appxmanifest.xml declares NM <PackageDependency>).

If your process runs but w/o package identity all 3 APIs will return APPMODEL_ERROR_NO_PACKAGE (15700 / 0x3D54), though in some odd cases it may be encoded as an HRESULT (0x80073D54). But same difference. This means the exe has no Fusion manifest with the <msix> element, or it does but the package isn't registered for the user.

But...if the package wasn't registered for the user and the Bootstrap auto-initializer wasn't disabled then the Bootstrapper should have failed and you never got into main() to even get to calling TextRecognizer. The console project template is defined to create a packaged app, not a exe to be used as an app via External Location. That's why I suspect the Fusion manifest with <msix> is missing.

If so this is easily corrected as noted at Add identity metadata to your desktop application manifests

Alternatively, winappcli may provide an easy solution. Issue #286 [Feature] Add sparse packaging support (winapp sparse command group) aims to address this. You'll need to check with the winappcli project regarding its status.

[ULTRON-MARK]

Howard Kapustein (@DrusTheAxe) Hi DrusTheAxe, thank you for your reply! Regarding your questions, here are my answers:

How did you 'run' the app? Did you click its tile in the Start Menu? CreateProcess() on the .exe in the External Location? AAM->ActivateApplication(aumid)?Other?

I launch the app just like a desktop application — by double-clicking the exe file in File Explorer. In other words, I start the executable file located in the External Location.

Does your project include a Fusion manifest declaring <msix...>?

Yes, the app.manifest already includes the Fusion manifest with the <msix...> declaration.

Is that package registered for the user? Get-AppxPackage lists packages registered for the user

Yes, I used the following command to register the identity package during a per-user installation:

powershell.exe -NoLogo -NoProfile -NonInteractive -WindowStyle Hidden -ExecutionPolicy Bypass -Command "Add-AppxPackage -Path <PackagePath> -ExternalLocation <ExternalLocation>"

This is the result I got after executing the Get-AppxPackage command.

Does your appxmanifest.xml declare a static dependency (ie <PackageDependency>) on the WinAppSDK framework package?

Yes, I added a PackageDependency named Microsoft.WindowsAppRuntime.1.8 in AppxManifest.xml

Are you built for WinAppSDK/MSIX or WinAppSDK/SelfContained? If WinAppSDK/MSIX then WinAppSDK's framework package must be registered for the user

My project targets WinAppSDK/MSIX.

If building targeting WinAppSDK/MSIX did you disable the WinAppSDK Bootstrap AutoInitializer?

I have not modified any relevant settings, so everything is using the default configuration.

---

I added test code in the main() function, and it can retrieve package information normally for both x64 and arm64 app builds:

Below are the app.manifest from the ConsoleApplication project and the AppxManifest.xml of the corresponding ConsoleApplicationPkg.msix:

<!-- app.manifest -->

<?xml version="1.0" encoding="utf-8"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
  <assemblyIdentity version="1.0.0.0" name="ConsoleApplication.app"/>
  <msix xmlns="urn:schemas-microsoft-com:msix.v1"
          publisher="CN=ULTRON"
          packageName="ConsoleApplication"
          applicationId="ConsoleApplicationPkg"
        />
</assembly>

<!-- AppxManifest.xml -->

<?xml version="1.0" encoding="utf-8"?>
<Package 
  xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"
  xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10"
  xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
  xmlns:uap10="http://schemas.microsoft.com/appx/manifest/uap/windows10/10"
  xmlns:systemai="http://schemas.microsoft.com/appx/manifest/systemai/windows10"
  IgnorableNamespaces="uap rescap uap10 systemai">

  <Identity
    Name="ConsoleApplication"
    Publisher="CN=ULTRON"
    Version="1.0.0.0" />

  <Properties>
    <DisplayName>ConsoleApplication</DisplayName>
    <PublisherDisplayName>ULTRON</PublisherDisplayName>
    <Logo>Assets\StoreLogo.png</Logo>
    <uap10:AllowExternalContent>true</uap10:AllowExternalContent>
  </Properties>

  <Resources>
    <Resource Language="en-us" />
  </Resources>

  <Dependencies>
    <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.19000.0" MaxVersionTested="10.0.26226.0" />
      <PackageDependency
          Name="Microsoft.WindowsAppRuntime.1.8"
          Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US"
          MinVersion="8000.500.1427.0" />
  </Dependencies>

  <Capabilities>
    <rescap:Capability Name="runFullTrust" />
    <rescap:Capability Name="unvirtualizedResources"/>
    <systemai:Capability Name="systemAIModels"/>
  </Capabilities>

  <Applications>
    <Application Id="ConsoleApplicationPkg" Executable="ConsoleApplication.exe" uap10:TrustLevel="mediumIL" uap10:RuntimeBehavior="win32App">
      <uap:VisualElements
        DisplayName="ConsoleApplicationPkg"
        Description="ConsoleApplicationPkg"
        BackgroundColor="transparent"
        Square150x150Logo="Assets\Square150x150Logo.png"
        Square44x44Logo="Assets\Square44x44Logo.png">
      </uap:VisualElements>
    </Application>
  </Applications>
</Package>

I apologize for providing insufficient details earlier that caused confusion. However, since the application works perfectly when built for arm64, I believe the issue is highly unlikely to be related to package registration. Looking forward to your reply!

[DrusTheAxe]

I think we're getting warmer...

TL;DR Add Architecture="x64" to your <Identity> ?

it cannot run and throws an ERROR_BAD_EXE_FORMAT exception. However, arm64 programs work fine (Perhaps it's because my computer uses the arm64 architecture).

OK, so your machine is ARM64

Select Solution Platform as x64, then compile and launch the application.

Your exe is compiled as X64

Your appxmanifest.xml doesn't specify Architecture=... so it's the default: neutral

  <PackageDependency
      Name="Microsoft.WindowsAppRuntime.1.8"
      Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US"
      MinVersion="8000.500.1427.0" />

You declared a dependency on WinAppSDK's framework package release 1.8

Since you didn't specify an architecture for your package you get the default of Neutral

When Deployment resolves your PackageDependency it's going to enumerate framework packages registered to your account looking for a match with Version >= 8000.500.1427.0 (your MinVersion) and a compatible architecture. I think this is where you're running into trouble.

The PackageDependency resolution algorithm amounts to...

Architecture native = GetNativeCpuInfo().Architecture

Package Resolve(PackageDependency pd, PackageIdentity callersPackageIdentity)
{
    List<Package> candidates

    FOREACH (pkg IN pkgmgr.FindPackagesForUser(user=current, PackageFamilyName=pd.PackageFamilyName, PackageType=Framework)
    {
         // Ignore packages failing to meet the required MinVersion
         IF (pkg.Version < pd.MinVersion) { continue }

        // Ignore packages with an incompatible Architecture
        //   * Neutral callers can use any neutral OR native (system/hardware) architectures
        //   * Not-Neutral callers can use neutral OR caller matching architectures
        IF (callersPackageIdentity.Architecture == neutral)
        {
            IF ((pkg.Architecture != neutral) && (pkg.Architecture != native)) { continue }
        }
        ELSE // callersPackageIdentity.Architecture != neutral
        {
            IF ((pkg.Architecture != neutral) && (pkg.Architecture != callersPackageIdentity.Architecture)) { continue }
        }

        // We have a candidate
        candidates += pkg
    }

    // Possible outcomes:
    // * No candidate ==> Can't resolve the dependency
    // * 1 candidate   ==> Bingo! We have a winner!
    // * 2+ candidates  ==> We have multiple matches. Pick the 'best fit' => Not-Native is better than Neutral
    IF (candidates.Count == 0) { return null / ERROR_NOT_RESOLVED }
    ELSEIF (candidates.Count == 1) { return candidates[0] }
    ELSE
    {
        // BestFit amongst 2+ matches in preferred order...
        // 1. native
        // 2. not-native not-neutral
        // 3. neutral
        p = candidates.FindByArchitecture(native)
        IF (found) { return p }
        p = candidates.FindByArchitecture(callersPackageIdentity.Architecture)
        IF (found) { return p }
        p = candidates.FindByArchitecture(neutral)
        IF (found) { return p }

        // Multiple candidates but can't resolve the dependency
        return null / ERROR_NOT_RESOLVED
    }
}

WinAppSDK has no neutral framework package so your ARM64 device can have x86, x64 and/or arm64 flavors registered (and having all 3 is common - different packages built for different architectures need different framework flavors).

Deployment considers the native matching package the best of possible candidates. On your PC that's arm64. And I'm guessing you've got the winappsdk 1.8 framework package registered, so tada! That's what's picked - arm64.

A packaged process' is born with a package graph, per 7. Static Package Dependency Resolution Algorithm. In your case that amounts to 2 packages - your main package followed by your package dependency

[ConsoleApplication_1.0.0.0_neutral__1234567890abc, Microsoft.WindowsAppRuntime.1.8_8000.500.1427.0_arm64__8wekyb3d8bbwe]

When your app runs your x64 compiled EXE runs and makes a call into a DLL in winappsdk 1.8's arm64 package. And since x64 processes don't understand arm64 files loading the arm64 DLL into your x64 EXE fails reporting ERROR_BAD_EXE_FORMAT.

You can confirm this if you change

  UINT32  bufferLength{};
  UINT32  count{};
  rc = ::GetCurrentPackageInfo(flags, &bufferLength, nullptr, &count);
  wprintf(L"GetCurrentPackageInfo: 0x%08X => Count=%u\n", rc, count);

to

  UINT32  bufferLength{};
  UINT32  count{};
  rc = ::GetCurrentPackageInfo(flags, &bufferLength, nullptr, &count);
  wprintf(L"GetCurrentPackageInfo: 0x%08X => Count=%u\n", rc, count);
  BYTE* buffer{ new BYTE[bufferLength] };
  rc = ::GetCurrentPackageInfo(flags, &bufferLength, buffer, &count);
  wprintf(L"GetCurrentPackageInfo: 0x%08X => Count=%u\n", rc, count);
  if (rc == ERROR_SUCCESS)
  {
    const PACKAGE_INFO * packageInfo{ reinterpret_cast<PACKAGE_INFO*>(buffer) };
    for (UINT32 index=0; index< count; ++index)
    {
      wprintf(L"    [%u] %ls\n", index, packageInfo[index].packageFullName);
    }
  }

That should show

    [0] ConsoleApplication_1.0.0.0_neutral__...
    [1] Microsoft.WindowsAppRuntime.1.8_8000.500.1427.0_arm64__8wekyb3d8bbwe

To fix the problem you should add Architecture="x64" to your appxmanifest.xml's <Identity> element when building as x64.

You could compile your exe as ARM64, but then you'd have the same problem in reverse -- your exe will work on arm64 but fail if installed and run on an x64 system.

x64 EXEs will run on arm64 systems, albeit with a perf penalty. If that matters to you then you'll want install and run your EXE compiled for the system's native architecture. If you distribute to both x64 + arm64 systems you'll need to build for x64 and again for arm64, same code but different appxmanifest.xml

I don't know if VS has any sort of $architecture$ macro in package.appxmanifest that'll automagically resolved to a value matching your build configuration's Platform property. Lacking that you'll need 2 different package.appxmanifest with conditional build logic to pick the right one, or other similar logic.

I've usually seen folks do one of those 2 solutions

• multiple manifests varying by archictecture with ...Condition="'$(Platform)'=='x64'"... etc to pick the right one for the current build configuration
• build logic to generate appxmanifest.xml with the desired value e.g. your own source pre-appxmanifest.xml file containing Architecture="$architecture$" and a Powershell script or like logic to read pre-appxmanifest.xml into a string, search/replace $architecture$ with your desired value and save the string to $(OutDir)\appxmanifest.xml (or wherever your package content's placed to then run through makeappx.exe).

[ULTRON-MARK]

Howard Kapustein (@DrusTheAxe)

It works! ! ! ! ! ! ! ! ! !

After I added the relevant debugging code, the printed logs were completely consistent with your expectations:

So I added ProcessorArchitecture="x64" to the <Identity> element in AppxManifest.xml, then repackaged, signed, and registered ... and it finally worked!

Notes:

1. It seems that the Architecture attribute is not supported, and I encountered an error when using MakeAppx.exe.

2. As you mentioned, x64 EXEs will run on arm64 systems, albeit with a perf penalty. However, since my app relies on several third-party libraries that do not yet support arm64, I can only distribute the x64 version of the app for now. This is the reason why I raised this question.

---

Regardless, the issue has finally been resolved. Thank you so much for your patient answer and detailed explanation!