MddBootstrapInitialize : ERROR_NOT_FOUND

[castorix]

Hello,

I installed Microsoft.WindowsAppSDK.1.0-experimental1 (0.218.840.0)
from "WindowsAppSDKInstall.exe"
but when I call MddBootstrapInitialize , I get :
hr = 2147943568 = 0x80070490 =ERROR_NOT_FOUND
Tested either in C++ or in C#
What could be the reason ?

Thanks in advance.

[riverar]

@castorix Can you show some code? What parameters do you pass into MddBootstrapInitialize? Did you install the correct WindowsAppSDKInstall for your target platform? (x86, x64, etc.)

[castorix]

Here's a known working sample if you want to try it out in the meantime. https://github.com/riverar/mux-repros/tree/master/unpackaged/scratch

I had tried it and I get the same error...

[DrusTheAxe]

Here's a known working sample if you want to try it out in the meantime. https://github.com/riverar/mux-repros/tree/master/unpackaged/scratch

I had tried it and I get the same error...

What do you see when you run this at a normal (not admin) command line

powershell -c Get-AppxPackage *appsdk*

?

[castorix]

What do you see when you run this at a normal (not admin) command line
powershell -c Get-AppxPackage appsdk

It seems the same thing :
powershell -c Get-AppxPackage appsdk

[riverar]

What version/build of Windows are you on?

[castorix]

What version/build of Windows are you on?

On Windows 10 1909, 18363.1621

[castorix]

I debugged by copying Microsoft.WindowsAppSDK.dll
from C:\Program Files\WindowsApps into the exe directory

and it crashes in the function FindDDLM at :
auto catalog{ winrt::Windows::ApplicationModel::AppExtensions::AppExtensionCatalog::Open(appExtensionName) };
with appExtensionName = "microsoft.winappsdk.ddlm-1.0-x8-e1"
(with version "1.0" from majorMinorVersion)

[DrusTheAxe]

Merging threads...

I just noticed that Microsoft.WindowsAppSDK.Main.1.0-experimental1 is only displayed in x64, not sure if it is normal...

Yes, if you have an x64 machine when WinAppSDK's installed you should have the followed registered:

• 2x Microsoft.WindowsAppSDK.1.0-experimental1 [x86 + x64]
• 1x Microsoft.WindowsAppSDK.Main.1.0-experimental1 [x64]
• 2x Microsoft.WindowsAppSDK.DDLM.1.0...x8-e1 and ...-x6-e1 [x86 + x64]

Framework packages can be installed side-by-side only differing by architecture. Thus an x64 system has both x64 + x86 flavors of the framework package.

Main packages can only have 1 package in the family registered for a user at a time. If there's multiple that could work the most-applicable is chosen, thus same package family name, same version but different architecture the one matching the system is installed. Thus the x64 Main package on x64 systems.

The DDLM is main package (as in, PackageType=main) but we need SxS behavior, hence the reason their package name includes the architecture (x8=x86, x6=x64). That's the magic how we get both x86+x64 DDLM packages registered for a user - the package name differs so don't run afoul of the main-packages-can-only-have-1-package-in-the-family-registered-for-a-user-at-a-time restriction.

...

with appExtensionName = "microsoft.winappsdk.ddlm-1.0-x8-e1"

Sounds like your app is an x86 process running on an x64 machine. Yes?

If so then your MddBoostrapInitialize call needs the following packages registered for the user (you can check via powershell -c get-appxpackage *appsdk*):

• x86 framework package (Microsoft.WindowsAppSDK.1.0-experimental1)
• x64 Main package (Microsoft.WindowsAppSDK.Main.1.0-experimental1)
• x86 DDLM package (Microsoft.WindowsAppSDK.1.0-...x8-e1)

and it crashes in the function FindDDLM at :

Is it crashing or failing? (sorry to be pedantic, but those words have very specific meaning here)

If the DDLM x8-e1 package isn't registered for the user then the AppExtensionCatalog::Open() call won't find a match and throw an exception, but it's the not-found error case and should boil up as a FAILED(hresult) return value from MddBootstrapInitialize. If that's the problem you can run the installer, or manually install the packages via

cd ...dir-where-you-have-the-nuget-unzipped-on-disk...\tools\MSIX
powershell -c add-appxpackage win10-x86\Microsoft.WindowsAppSDK.1.0.msix
powershell -c add-appxpackage win10-x86\Microsoft.WindowsAppSDK.DDLM.1.0.msix
powershell -c add-appxpackage win10-x64\Microsoft.WindowsAppSDK.1.0.msix
powershell -c add-appxpackage win10-x64\Microsoft.WindowsAppSDK.Main.1.0.msix

VS doesn't install those today when you hit F5 (something we're working on for 1.0 but not ready yet).

OTOH if there's an actual crash in there, can you share a callstack?

[castorix]

If so then your MddBoostrapInitialize call needs the following packages registered for the user (you can check via powershell -c get-appxpackage appsdk):
x86 DDLM package (Microsoft.WindowsAppSDK.1.0-...x8-e1)

I don't have 1.0, but the version 0.218.840 in the name :
Microsoft.WindowsAppSDK.DDLM.0.218.840.0-x8-e1

I tried
powershell -c remove-appxpackage Microsoft.WindowsAppSDK.DDLM.0.218.840.0-x8-e1_0.218.840.0_x86__8wekyb3d8bbwe
powershell -c add-appxpackage Microsoft.WindowsAppSDK.DDLM.1.0-experimental1.msix
then
powershell -c get-appxpackage appsdk
but I still get
Microsoft.WindowsAppSDK.DDLM.0.218.840.0-x8-e1

then in the code :

which returns :
hr = HRESULT_FROM_WIN32(ERROR_NOT_FOUND)

[castorix]

I removed all packages and installed the last preview2 version:
Still same ERROR_NOT_FOUND error

Deploying package: Microsoft.WindowsAppRuntime.1.0-preview2_0.272.1934.0_x64__8wekyb3d8bbwe
Package deployment result : 0x0
Deploying package: Microsoft.WindowsAppRuntime.1.0-preview2_0.272.1934.0_x86__8wekyb3d8bbwe
Package deployment result : 0x0
Deploying package: Microsoft.WindowsAppRuntime.Main.1.0-preview2_0.272.1934.0_x64__8wekyb3d8bbwe
Package deployment result : 0x0
Provisioning result : 0x0
Deploying package: Microsoft.WindowsAppRuntime.Singleton-preview2_0.272.1934.0_x64__8wekyb3d8bbwe
Package deployment result : 0x0
Provisioning result : 0x0
Deploying package: Microsoft.WinAppRuntime.DDLM.0.272.1934.0-x6-p2_0.272.1934.0_x64__8wekyb3d8bbwe
Package deployment result : 0x0
Provisioning result : 0x0
Deploying package: Microsoft.WinAppRuntime.DDLM.0.272.1934.0-x8-p2_0.272.1934.0_x86__8wekyb3d8bbwe
Package deployment result : 0x0
Provisioning result : 0x0
All packages were installed successfully.

[DrusTheAxe]

Aha! I think I see the problem! You need to initialize COM on the thread before calling the bootstrap API

Try adding this as line 27.5

const HRESULT hrCoInit{ ::CoInitializeEx(nullptr, COINITBASE_MULTITHREADED) };
if (FAILED(hrCoInit))
{
    printf("Oh no! 0x%X", hrCoInit);
    return hrCoInit;
}

[castorix]

const HRESULT hrCoInit{ ::CoInitializeEx(nullptr, COINITBASE_MULTITHREADED) };

No, it doesn't change...

And I have the same bug with the C# sample from scratch

[riverar]

What OS version/build are you on? Is this a machine that had any privacy/"debloat" scripts run on?

[castorix]

What OS version/build are you on? Is this a machine that had any privacy/"debloat" scripts run on?

It is a standard Windows 10 Education, Version 1909, Build 18363.1801

[DrusTheAxe]

What OS version/build are you on? Is this a machine that had any privacy/"debloat" scripts run on?

It is a standard Windows 10 Education, Version 1909, Build 18363.1801

TL;DR known bug in the bootstrapper on <20H1. The fix was just checked in (Unpackaged Windows App SDK app doesn't run on RS5/19H1 #1681) to cook through the overall build pipeline and verification. The next 1.0 release should have the fix, so, soon.

Per my handy dandy decoder ring Windows 10 Version 1909 == 19H2, but 19H2 has the same limitation for the bootstrap as 19H1 (no surprise, as 19H2 is (oversimplified) 19H1 plus some fixes).

[pjc50]

I'm having the same problem, except I definitely have the version as 0x10000 from the example code at MicrosoftDocs/windows-dev-docs#3439

I notice that installing the runtime gives packages named Microsoft.WindowsAppRuntime.DDLM.1.0-preview3.msix etc whereas all the discussion above refers to Microsoft.WindowsAppSDK.DDLM - is this a different package or has it been renamed? Looks like it's been renamed given https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/check-windows-app-sdk-versions

[pjc50]

The C++ example from
https://github.com/MicrosoftDocs/windows-uwp/blob/docs/hub/apps/windows-app-sdk/tutorial-unpackaged-deployment.md does not initialize COM. It also doesn't work for me, and likewise calling CoInitializeEx does not make it work.

[pjc50]

My minimal C++ testcase is now

#pragma comment(lib, "windowsapp")
#include <winrt/base.h>
#include <winrt/Windows.Foundation.h>
#include <winrt/Windows.ApplicationModel.AppExtensions.h>

int main()
{
    winrt::init_apartment();
    auto catalog{ winrt::Windows::ApplicationModel::AppExtensions::AppExtensionCatalog::Open(L"microsoft.winappruntime.ddlm-1.0-x6-p3") };
}

Having isolated the failing call and brought it up where I can see it. It looks like the problem is the appextension winrt interface itself failing to load, but I'm at a loss as to why. System is Windows 10 Version 1909, "10.0.18363.1801". Project target version is "10.0.19041.0" (but I've also tried 17763. All within VS2019.

[pjc50]

This is the same issue as #1121 (comment) , except not on Windows Server. The app extension API is .. missing? Which makes it unavailable to the bootstrapper.

[castorix]

This is the same issue as #1121 (comment) , except not on Windows Server. The app extension API is .. missing? Which makes it unavailable to the bootstrapper.

I finally decided to upgrade my Windows version from 1909 to 21H1... and now it works !
(tested in C++ and C#)
So there is clearly a problem with Windows 10 1909, 18363.1801

[DrusTheAxe]

Yes. There was a Windows limitation we weren't aware of in <20H1 causing the Bootstrap API to fail. The fix changes the Bootstrap's implementation to avoid this problem.

For more details see Unpackaged Windows App SDK app doesn't run on RS5/19H1 #1681

[castorix]

I mark the thread as answered

from comments :
#1352 (reply in thread)
#1352 (reply in thread)

[triplef]

I’m getting the same error 0x80070490 from MddBootstrapInitialize2() with the latest SDK version 1.5.3 (1.5.240428000 / 5001.119.156.0) on Windows 11 23H2.

I already tried a full uninstall (get-appxpackage micro*win*appruntime* | remove-appxpackage) and reinstall with the same result.

Any idea @DrusTheAxe?

[DrusTheAxe]

0x80070490 means WinAppSDK isn't registered for the user as you expect. This is usually because all the needed packages didn't register, or your process isn't running as the user you think it is (or both).

You can do a few easy things to investigate:

• For the process calling the Bootstrapper...
  • What's the user context?
  • What's the security context? (Elevated, MediumIL, AppContainer, etc)
• Are the packages registered for the user?
  • At an admin prompt run `powershell -c get-appxpackage microwinapprun -AllUsers
    • The PackageUserInformation property will show a list of usersid [username]: status
      • Status of 'Installed' means it's registered for that user
      • Status of 'Staged' means it's staged on the machine.
        • NOTE: 'Staged` should only appear for LocalSystem (S-1-5-18)
        • NOTE: A package should be Staged for LocalSystem -OR- `Installed (registered) for 1 or more users. If both then something's wrong
  • Are all the packages registered for the user?
    • NOTE: The Framework (Microsoft.WindowsAppRuntime.1.5*) and DDLM packages are critical for the Bootstrapper
• Was there a Deployment problem installing the packages?
  • Review the EventLog channels Microsoft-Windows-AppXDeploymentServer/Operational and Microsoft-Windows-AppXDeployment/Operational e.g. run eventvwr.exe and drill down...
    
  • Every time Deployment processes an MSIX package you'll find events about a request to process the package, 1 or more events about the processing and an Informational event at the end about the request succeeding or an Error if it failed. If nothing's logged it's because the request never reached the Deployment pipeline, in which case the Microsoft-Windows-AppXDeployment/Operational channel should have more info (the PackageManager APIs log here before/after handing the request to the Deployment pipeline)