1.6.x: HardwareIdentification.GetPackageSpecificToken(...) throws COMException now

[TomPMoleman]

Describe the bug

Using any 1.5.x or older version, Windows.System.Profile.HardwareIdentification.GetPackageSpecificToken(...) yielded a result (maybe the COMException was encountered once or twice based on which thread it has been invoked within, but then it was working quite fine) even for packaged WinUi3 applications running with fulltrust.

However, sadly, after trying to upgrade to any 1.6.x WindowsAppSdk, the COMException will inevitably be thrown!

Using an AppContainer is also not an option, since there are still many open issue available with file access not working, not even upon using pickers. Also figuring out a different approach as to be receiving an unique app- and hardware-specific identifier won't be an option here, since this approach has been in place even back then when the app was built for Windows 8.1 which then was migrated to UWP and later on to WinUi3. Some aspects of the received app specific hardware identifier are used as an identification within our licensing process, whereas changing that approach now would result in each and every device consuming another seat (unless someone identifies the outdated seats and renews their licenses (but since the licensing process is shared for several solutions (e.g. Android & iOS as well), that might not be easily feasible either or at least very cumbersome if different 'client types' are used)).

Steps to reproduce the bug

1. Setup test application using 1.5.x
2. ensure the app is packaged and running in fulltrust
3. invoke "HardwareIdentification.GetPackageSpecificToken(null)" several times (different threads and at different times)
4. please note that the COMException will not be thrown (unless it is still invoked while app setup process settles)
5. update using SDK 1.6.x now
6. please note that each and every "HardwareIdentification.GetPackageSpecificToken(null)" call is now destined to fail

Expected behavior

Like for 1.5.x, the "HardwareIdentification.GetPackageSpecificToken(...)" should not yield a COMException.

Especially since the documentation of the "HardwareIdentification.GetPackageSpecificToken(...)" method still states that one of its primary purposes is to be used for licensing:

Screenshots

As shown below, the call succeeded using SDK 1.5.x and below (even for packaged fulltrust applications):

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

[DarranRowe]

From some simple testing, this seems to work fine with C++. There are no unexpected exceptions thrown at all.

If you enable native debugging, is there any messages reported in the debugger output?

[TomPMoleman]

Hi @DarranRowe,

first of all thanks for your support.

Sadly enabling native debugging won't yield any further bits of information (despite VS took a long time loading all symbols):

Sorry that I forgot to include the stack trace in the first place:

at WinRT.ExceptionHelpers.g__Throw|38_0(Int32 hr) at WinRT.ExceptionHelpers.ThrowExceptionForHR(Int32 hr) at ABI.Windows.System.Profile.IHardwareIdentificationStaticsMethods.GetPackageSpecificToken(IObjectReference _obj, IBuffer nonce) at Windows.System.Profile.HardwareIdentification.GetPackageSpecificToken(IBuffer nonce) at [my code here ...]

However, what might be worth mentioning is, that unlike you in your sample I'm using the 'single-project packaging' approach though. I've noticed in some previously found issue reports, that using a single-project for packaging sometimes sadly was the key to whether or not an issue arose in the first place.

Thanks, BR Thomas

[DarranRowe]

@TomPMoleman

Actually, I managed to trigger it. There is something about the newer project templates that are subtly broken.

Anyway, native debugging did provide extra information.

Now I really want to figure out what it is about the newer projects that is broken.