.NET 5/6 TFM breaks existing WindowsRuntime code ("Invalid pointer" exception)

[christopher-rtf]

This bug report has been submitted to CsWinRT per recommendation of @jkoritzinsky.
Original bug report (in dotnet/runtime): dotnet/runtime#55406

Description

Under .NET Framework 4.6+ and .NET Core 3.1, we register for WNS side-channel push notifications using the Microsoft.Windows.SDK.Contracts NuGet package. This works in both packaged apps and also in unpackaged apps using sparse packages.

We are currently upgrading our application to .NET 5/6, and it appears that some of the Windows Runtime code has been broken in the migration from Microsoft.Windows.SDK.Contracts to TFM.

Code sample

var channel = await PushNotificationChannelManager.GetDefault().CreateRawPushNotificationChannelWithAlternateKeyForApplicationAsync(anyApplicationServerKey, anyChannelId);

What we expect to experience

What we experience under .NET Framework 4.6+ and .NET Core 3.1 (and expect to experience under .NET 5.0+):
The runtime returns a channel registration, including a URI and expiration date. We are then able to use a PushNotificationTrigger to capture the notifications in a background Windows Runtime task.

What we experience instead

We experience under .NET 5.0 using TFM and .NET 6.0 Preview using TFM (target framework: net5.0-windows10.0.19041.0):

Exception thrown at 0x00007FFA0084ED9 (KernelBase.dll) in .exe 0x80004003: Invalid Pointer
Exception thrown: "System.NullReferenceException" in WinRT.Runtime.dll

Severity

Blocking: this bug is 100% blocking us from moving our codebase to .NET 5 or .NET 6 Preview.

Regression?

This issue does not exist under .NET Framework 4.6.1+ or .NET Core 3.1. This is a new bug in .NET 5.0 and 6.0 Preview (created in the migration from Microsoft.Windows.SDK.Contracts to TFM).

Other information

We are able to register other background tasks and triggers (including permission-based triggers such as time zone triggers) without issue under .NET 5.0 and .NET 6.0 Preview. We are able to use those with C#/WinRT background tasks (using a packaged app or sparse package registrations). The call above is the only Windows Runtime call which is blocking our migration to .NET 5+. We are testing under x64 architecture.

Here is a link to the specific function which doesn't seem to be wired up properly under TFM (but worked under the old scheme):
https://docs.microsoft.com/en-us/uwp/api/windows.networking.pushnotifications.pushnotificationchannelmanagerforuser.createrawpushnotificationchannelwithalternatekeyforapplicationasync?view=winrt-19041

I have spent several days trying many workarounds, but I haven't come up with a good one yet that works under .NET 5 or .NET 6 Preview. Please note that side-channel push notifications don't seem to be included in the scope for Project Reunion, so we're hoping for a .NET runtime bug fix here (instead of building out a new architecture for the other kind of WNS push notifications).

Christopher

[manodasanW]

@christopher-rtf Do you happen to have a stack you can provide for those 2 exceptions and potentially a sample repro we can take a look at?

[christopher-rtf]

@manodasanW Sure thing, thanks for taking a look at this!

Here is a repo where I have uploaded a sample project under both .NET Core 3.1 (where registration is successful) and also .NET 5.0 (where WinRT.Runtime throws an exception).

https://github.com/christopher-rtf/CsWinRt_Issue905_Repro

This is a minimal repro, a packaged app which calls exactly one Windows Runtime function. Both should be identical except for .NET version (.NET Core 3.1 vs .NET 5.0).

Here is the error stack trace when running under .NET 5.0 (w/ TFM targeting Windows 10 v2004+):

System.NullReferenceException
  HResult=0x80004003
  Message=Object reference not set to an instance of an object.
  Source=WinRT.Runtime
  StackTrace:
   at WinRT.ExceptionHelpers.ThrowExceptionForHR(Int32 hr)
   at ABI.Windows.Networking.PushNotifications.IPushNotificationChannelManagerForUser2.global::Windows.Networking.PushNotifications.IPushNotificationChannelManagerForUser2.CreateRawPushNotificationChannelWithAlternateKeyForApplicationAsync(IBuffer appServerKey, String channelId)
   at Windows.Networking.PushNotifications.PushNotificationChannelManagerForUser.CreateRawPushNotificationChannelWithAlternateKeyForApplicationAsync(IBuffer appServerKey, String channelId)
   at WnsPushNotificationClient_NET50.MainWindow.<RegisterForPushNotificationsButton_Click>d__1.MoveNext() in C:\temp\WnsPushNotificationClient_NET50\WnsPushNotificationClient_NET50\MainWindow.xaml.cs:line 44

[manodasanW]

Issue looks to be due to our storage specific IMarshal interface makes use of delegates and in those cases we assume the vftbl constructor would not be public, but it is. Working on fix to convert the interface to not use delegates and be like the other net5 projection interfaces.