Fix !m_RedirectContextInUse assert in RestoreContextSimulated on win-x86

[Copilot]

main PR

Description

On x86 Windows without RtlRestoreContext, RestoreContextSimulated called HandleThreadAbort() while m_RedirectContextInUse was still true. HandleThreadAbort() constructs a ThreadAbortException by running managed code (resource string loading, etc.), during which a concurrent GC redirect fires MarkRedirectContextInUse() → assert !m_RedirectContextInUse.

Fix: Replace HandleThreadAbort() with the same abort-redirect pattern already used by the non-x86 path in RedirectedHandledJITCase:

• Call CopyOSContext + COMPlusCheckForAbort() (both NOTHROW/GC_NOTRIGGER — no managed code)
• If abort is pending, redirect pCtx IP to ThrowControlForThread and store the resume PC in m_OSContext
• Proceed through the EXCEPTION_HIJACK path, which pops the RedirectedThreadFrame and calls UnmarkRedirectContextInUse before resuming at the abort handler

The abort exception is now raised only after the redirect context is fully released, eliminating the re-entrancy window.

Customer Impact

Checked (debug) builds of .NET on Windows x86 crash with STATUS_FAIL_FAST_EXCEPTION when ControlledExecution.Run (or any code path that triggers a thread abort) races with a GC redirect on the same thread. Release builds are not protected by the assert but the re-entrant redirect corrupts the saved context.

Regression

Not a regression introduced in the most recent release; latent race in the x86-only RestoreContextSimulated path.

Testing

Built clr.runtime (checked) with 0 errors/0 warnings. The affected code path is x86 Windows–specific (#ifdef TARGET_X86 / #ifndef TARGET_UNIX) and not exercisable in a Linux x64 CI environment; the fix is a mechanical port of the existing non-x86 abort-redirect pattern that is already proven correct on all other platforms.

Risk

Low. The change is confined to the x86-only RestoreContextSimulated function and replaces HandleThreadAbort() with COMPlusCheckForAbort() — an exact match of the logic already in use on every other code path through RedirectedHandledJITCase. No new mechanism is introduced.

Package authoring no longer needed in .NET 9

IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.

[dotnet-policy-service]

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