Closed pingzing closed 6 months ago
I hit this as well. The nullable pActivationParams
isn't being handled correctly here, ends up trying to access pActivationParams.HasValue
.
Poking @AArnott for prioritization 😅
I don't think there's anything wrong with calling pActivationParams.HasValue
in the friendly overload, as that is a nullable struct, so it can't throw NRE.
I suspect the issue is that the .NET interop layer cannot handle a null reference passed into an in struct
parameter on a COM interface. That seems unfortunate because the COM side should only need the address, and taking the address of a null reference is allowed in C# and produces a null pointer as intended.
But on the flip side, I don't know why CsWin32 is generating the COM interface with an in PROPVARIANT
rather than PROPVARIANT*
in the first place. Given it's an [Optional]
parameter, CsWin32 should be (I think) be preferring pointers. That's the first thing I'll look into.
This bug was surprisingly difficult to solve.
Yay, thanks @AArnott. Will try it out tonight.
Actual behavior
Calling the
IMMDevice.Activate()
overload with the convenience extension (e.g. the one that takes aGuid
rather than aGuid*
) method results in aNullReferenceExcception
.It seems the issue is in the generated convenience extension method that looks like this:
The actual culprit is the
Unsafe.NullRef<PROPVARIANT>()
call--it seems that passing a non-nullable struct type to it results in aNullReferenceException
.Expected behavior
Calling the
.Activate()
convenience overload works!Repro steps
NativeMethods.txt
content:NativeMethods.json
content (if present): N/AAny of your own code that should be shared?
Here's a little minimal sample, cut down a bit from what I have:
Context
Note: this is a WPF project.
0.3.49-beta
net7.0-windows
LangVersion
(if explicitly set by project): [e.g.9
]: Not explicitly set