QUIC: Callback GCHandles are released too soon

[geoffkizer]

For MsQuicStream and similar classes that receive native callbacks from MsQuic:

We register for event callbacks using a GCHandle to the relevant "State" object. However, we dispose this GCHandle (_stateHandle) in Dispose. This is too early; we may have events still in flight at this point, and when they try to deref the _stateHandle, they will likely get bogus data.

Once the callback (and associated GCHandle) is successfully registered, we should not release the GCHandle until we get a final callback event and know there will not be any more callback events that reference that GCHandle, at which point we can free it. Note this includes some places today where we are freeing the GCHandle on various exception cases; these cannot release the GCHandle either.

I suspect this may be the reason we see various native crashes when using MsQuic.

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

For MsQuicStream and similar classes that receive native callbacks from MsQuic:

We register for event callbacks using a GCHandle to the relevant "State" object. However, we dispose this GCHandle (_stateHandle) in Dispose. This is too early; we may have events still in flight at this point, and when they try to deref the _stateHandle, they will likely get bogus data.

Once the callback (and associated GCHandle) is successfully registered, we should not release the GCHandle until we get a final callback event and know there will not be any more callback events that reference that GCHandle, at which point we can free it. Note this includes some places today where we are freeing the GCHandle on various exception cases; these cannot release the GCHandle either.

I suspect this may be the reason we see various native crashes when using MsQuic.

Author:	geoffkizer
Assignees:	-
Labels:	area-System.Net.Quic
Milestone:	6.0.0