PackageDeploymentManager.RegisterPackageAsync() fails while WinRT RegisterPackageByFullNameAsync() succeeds

[whiskhub]

Describe the bug

PackageDeploymentManager.RegisterPackageAsync() fails to execute while the WinRT counterpart PackageManager.RegisterPackageByFullNameAsync() succeeds.

The WASDK method returns withPackageDeploymentStatus.CompletedFailure, but empty Error/ErrorText/ExtendedError properties. The console (with native debugging enabled) shows:

Exception thrown at 0x00007FFF613A83EA (KernelBase.dll) in PackageManagerRegisterTest.exe: WinRT originate error - 0x800706BE : 'The remote procedure call failed.'.
Exception thrown at 0x00007FFF613A83EA (KernelBase.dll) in PackageManagerRegisterTest.exe: 0x000006BE: The remote procedure call failed.
onecore\admin\appmodel\packagemanager\client\Helpers.hpp(235)\AppXDeploymentClient.dll!00007FFF596B31C8: (caller: 00007FFF596B562C) LogHr(1) tid(739c) 800706BE The remote procedure call failed.
Exception thrown at 0x00007FFF613A83EA (KernelBase.dll) in PackageManagerRegisterTest.exe: WinRT originate error - 0x80070490 : 'Element not found.'.

The WinRT method succeeds and the package is registered and useable afterwards.

Steps to reproduce the bug

1. Create a packaged app (e.g. WinUI 3)
2. Stage a (signed, or self-signed in trusted certificate store) MSIX package:

var packageDeploymentManager = PackageDeploymentManager.GetDefault();
var options = new Microsoft.Windows.Management.Deployment.StagePackageOptions();
var uri = new Uri(@"C:\file_path_to_msix.msix");
var operation = packageDeploymentManager.StagePackageByUriAsync(uri, options);
var result = await operation;

3. Register the package using full package name and WASDK:

var packageDeploymentManager = PackageDeploymentManager.GetDefault();
var options = new Microsoft.Windows.Management.Deployment.RegisterPackageOptions();
var operation = packageDeploymentManager.RegisterPackageAsync("MyPackage_1.0.0.123_x64__publisherid", options);
var result = await operation;

4. Register the package using full package name and WinRT:

var packageManager = new PackageManager();
var operation = packageManager.RegisterPackageByFullNameAsync("MyPackage_1.0.0.123_x64__publisherid", [], DeploymentOptions.None);
var result = await operation;

5. Verify the package was registered (e.g. see the app in start menu)

Expected behavior

RegisterPackageAsync() succeeds, same as the WinRT counterpart RegisterPackageByFullNameAsync().

Screenshots

No response

NuGet package version

Windows App SDK 1.6.1: 1.6.240923002

Packaging type

Packaged (MSIX)

Windows version

Windows 11 version 22H2 (22621, 2022 Update)

IDE

Visual Studio 2022

Additional context

No response

[DrusTheAxe]

How timely. We were just discussing a similar scenario last week involving PackageManager.RegisterPackageByFullNameAsync.

PackageManagerManager.RegisterPackageAsync(packageFullName) ultimately calls PackageManager.RegisterPackagesByFullNameAsync() (note the plural) not RegisterPackageByFullNameAsync (singular). I bet there's a subtle difference under the hood.

PackageDeploymentManager uses the newer (plural) API to get the full options fidelity:

• RegisterPackages...(string[] packageFullNames, RegisterPackageOptions options)
• RegisterPackage...(string packageFullName, IEnumerable<string> dependencyPackageFullNames, enum DeploymentOptions options)

The core behavior shouldn't differ as you see, but obviously something does. I'll discuss this further with the team.

Thanks for bringing this to our attention!

--DrusTheAxe

P.S. WindowsAppSDK/dev/PackageManager/API/M.W.M.D.PackageDeploymentManager.cpp line 2327+ is the call to do the heavy lifting:

winrt::Windows::Foundation::Collections::IVector<winrt::hstring> packageFullNames{ winrt::single_threaded_vector<winrt::hstring>() };
packageFullNames.Append(packageFullName);
auto deploymentOperation{ m_packageManager.RegisterPackagesByFullNameAsync(packageFullNames, registerOptions) };

[DrusTheAxe]

This has been identified as a bug in RegisterPackageAsync(const hstring& package, ...) when package` = PackageFamilyName or PackageFullName.

The root problem is the parameter's passed as const hstring& which isn't properly captured before RegisterPackageAsync calls co_await so later uses of the parameter are access-after-free. This works for simple workloads where (if you're lucky) the heap layout isn't disrupted whereas larger (typical real world) scenarios will use the memory after it's altered and no longer valid. This can result in weird behavior (as reported in this issue) up to and including access violation and process crash.

The fix will be out in upcoming servicing update.

[whiskhub]

@DrusTheAxe I have tried with the latest v1.7-exp2. While I no longer get access violation exceptions, it still doesn't work.

But now with a different error: Deployment OnDemandRegisterOperation operation with target volume C: on Package ... from: failed with error 0x80070005. See http://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app deployment issues.'. So Access Denied.

The WinRT counterpart PackageManager.RegisterPackageByFullNameAsync() works as expected.

What I noticed: this only happens if the app is MSIX packaged (even full trust). When executed from an unpackaged app, the WASDK method PackageDeploymentManager.RegisterPackageAsync() works without error. Probably an issue in the OS then?

Should I create a new GitHub issue for this?

[DrusTheAxe]

Windows 11 version 22H2 (22621, 2022 Update)

...failed with error 0x80070005...

only happens if the app is MSIX packaged (even full trust). When executed from an unpackaged app, the WASDK method PackageDeploymentManager.RegisterPackageAsync() works without error. Probably an issue in the OS then?

I think I know the issue. Is your process is packaged and manifested as RuntimeBehavior="packagedClassicApp" TrustLevel="mediumIL" (or EntryPoint="windows.fullTrustApplication")?

Or perhaps packagedClassicApp+appContainer (or windows.partialTrustApplication) and you don't declare the packageManagement?

[whiskhub]

@DrusTheAxe Yes, Windows.FullTrustApplication (what you get from a new WinUI 3 app template). Windows OS is 24H2 (26100). Happens with or without packageManagement capability.

[DrusTheAxe]

Interesting. Need to do some spelunking and get back to you

Happens with or without packageManagement capability.
Capabilities shouldn't matter for mediumIL* processes. They're generally assumed to have potentially all capabilities (or could if they wanted to) so there's no point checking for them

[whiskhub]

@DrusTheAxe Sorry to ping, but were you able to find out something? If not I'll just open a new GitHub issue