Fix over-release of caller-owned interface pointer in CreateObject

[Sergio Pedri (Sergio0694)]

Summary

Fixes a reference count over-release in WindowsRuntimeComWrappers.CreateObject, which released an interface pointer owned by the caller whenever a marshalling operation re-entered the marshalling infrastructure on the same thread.

Motivation

CreateObject receives the IInspectable interface pointer through the CreateObjectTargetInterfacePointer thread-static. That pointer is normally supplied (and owned) by the caller, but in the WeakReference<T> rehydration path there is no caller context, so CreateObject has to QueryInterface for it itself and release it afterwards.

To tell those two cases apart, the finally block re-read CreateObjectTargetInterfacePointer and treated null as "I acquired this myself". That inference is only valid as long as nothing resets the field while CreateObject is running, and GetOrCreateObjectForComInstanceUnsafe resets it to null on exit. Any nested marshalling operation therefore left the field null, so the outer finally released a pointer it did not own, dropping the reference count one time too many.

This is reachable today. Marshalling a NotifyCollectionChangedEventArgs resolves through the most-derived-type lookup to its ComWrappers marshaller, whose CreateObject calls NotifyCollectionChangedEventArgsMarshaller.ConvertToManaged. That in turn marshals the NewItems/OldItems collections through IListMarshaller.ConvertToManaged, which re-enters GetOrCreateObjectForComInstanceUnsafe.

While fixing that, the same shared state turned out to have a second, independent problem: because GetOrCreateObjectForComInstanceUnsafe unconditionally cleared the callbacks rather than restoring them, a nested marshalling operation also destroyed the outer operation's static type information. Once control returned to the outer CreateObject, the fallback that would have produced a wrapper specialized to the statically known type saw a null callback and silently degraded to an opaque IInspectable wrapper.

Changes

• src/WinRT.Runtime2/InteropServices/WindowsRuntimeComWrappers.cs: track whether CreateObject acquired the interface pointer itself in a local, instead of inferring it in the finally block from shared thread-static state. This is the actual fix for the over-release.

• src/WinRT.Runtime2/InteropServices/WindowsRuntimeComWrappers.cs: save and restore the three marshalling thread-statics in GetOrCreateObjectForComInstanceUnsafe instead of always writing null, so a nested marshalling operation no longer destroys the outer operation's state. For a top-level call the saved values are null, so the existing invariant that these fields are null outside a marshalling operation is preserved, and the WeakReference<T> rehydration path keeps behaving as before.

• src/Tests/UnitTest/ComWrappersTests.cs: new regression test covering re-entrant marshalling. The shipping trigger (NotifyCollectionChangedEventArgs) needs the WinUI runtime to activate, which is not available in the unit test host, so the test instead uses a minimal native IInspectable with a hand-written vtable whose GetRuntimeClassName marshals a second native object. That callback runs inside the outer CreateObject, reproducing the same re-entrancy without any activation dependency. Rather than hard-coding how many references the marshalling infrastructure takes internally, the test marshals twice (once re-entrant, once not) and asserts that both have the same net effect on the reference count of the caller-owned pointer, which keeps it robust to unrelated internal changes.

Validation

The new test was verified against each state of the fix:

Runtime state	Result
Before the fix	Fails with Expected:<1>. Actual:<0>
First commit only	Passes
Both commits	Passes

Actual:<0> is exactly the expected symptom: the spurious Release cancels out the reference that the created wrapper takes.

Running the full UnitTest suite before and after the change goes from 432 failed / 81 passed to 431 failed / 82 passed, so exactly one test flips and there are no regressions. The remaining failures are pre-existing and environmental: the C++ test component is not registered in the local test host, so those tests fail with REGDB_E_CLASSNOTREG while constructing the test class.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.