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: Move the RestoreContextSimulated call in RedirectedHandledJITCase to after the existing COMPlusCheckForAbort() block, so both the x86 SEH path and the RtlRestoreContext path share a single abort-check code path:

• CopyOSContext + COMPlusCheckForAbort() (both NOTHROW/GC_NOTRIGGER — no managed code) run unconditionally for all platforms
• If abort is pending, pCtx IP is redirected to ThrowControlForThread and the resume PC is stored in m_OSContext
• For x86 without RtlRestoreContext, RestoreContextSimulated is then called (using the already-computed abort redirect); the EXCEPTION_HIJACK path in its exception filter pops the RedirectedThreadFrame and calls UnmarkRedirectContextInUse before resuming

RestoreContextSimulated itself is kept minimal — it contains only the SEH-based context-restore machinery with no abort logic. No code is duplicated between the two paths.

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 aligns the x86 SEH path with the existing non-x86 abort-redirect pattern that is already proven correct on all other platforms.

Risk

Low. The change moves the RestoreContextSimulated call to after the shared COMPlusCheckForAbort block in RedirectedHandledJITCase, eliminating code duplication while preserving identical runtime behaviour. 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.

[Copilot]

Pull request overview

This PR fixes a win-x86-specific debug assert (!m_RedirectContextInUse) by removing a re-entrancy window where RestoreContextSimulated could call HandleThreadAbort() while the redirect context was still marked “in use”. The change aligns the x86 SEH-based restore path with the existing shared abort-check flow used by the RtlRestoreContext path.

Changes:

• Remove the HandleThreadAbort() call from RestoreContextSimulated so it performs only the SEH-based context restore mechanics.
• Move the x86 “no RtlRestoreContext” call to RestoreContextSimulated to after the shared CopyOSContext + COMPlusCheckForAbort() logic in RedirectedHandledJITCase.