CoreCLR x86: CopyContext fails with ERROR_INVALID_PARAMETER in RestoreContextSimulated path on Windows 7, causing fatal EE error

[daigs]

Description

I am seeing a random native CoreCLR crash when running a .NET 10 win-x86 self-contained application on Windows 7.

This appears to be related to the x86 RestoreContextSimulated / RedirectedHandledJITCaseExceptionFilter path used when RtlRestoreContext is not available.

Related issues/PRs:

• !m_RedirectContextInUse Assert on win-x86 #127637
• Fix !m_RedirectContextInUse assert in RestoreContextSimulated on win-x86 #127638

I applied the fix from #127638 locally, but the crash still reproduced. After further investigation, the crash was caused by CopyContext() failing inside RedirectedHandledJITCaseExceptionFilter, after which CoreCLR calls EEPOLICY_HANDLE_FATAL_ERROR(COR_E_EXECUTIONENGINE).

Reproduction Steps

I do not currently have a minimal standalone repro. The issue reproduces randomly in a .NET 10 win-x86 self-contained WPF application running on Windows 7.

The fatal error is triggered in this code path:

CONTEXT* pTarget = pExcepPtrs->ContextRecord;
if (!CopyContext(pTarget, pCtx->ContextFlags, pCtx))
{
    STRESS_LOG1(LF_SYNC, LL_ERROR, "ERROR: Could not set context record, lastError = 0x%x\n", GetLastError());
    EEPOLICY_HANDLE_FATAL_ERROR(COR_E_EXECUTIONENGINE);
}

Native stack from dump:

coreclr!WatsonLastChance
coreclr!EEPolicy::LogFatalError
coreclr!EEPolicy::HandleFatalError
coreclr!RedirectedHandledJITCaseExceptionFilter
coreclr!Thread::RestoreContextSimulated
coreclr!_EH4_CallFilterFunc
coreclr!_except_handler4
coreclr!Thread::RedirectedHandledJITCase
coreclr!RedirectedHandledJITCaseForGCThreadControl_Stub
...

Additional diagnostics from an instrumented CoreCLR build showed that CopyContext() failed with ERROR_INVALID_PARAMETER:

CoreCLR: CopyContext failed in RedirectedHandledJITCaseExceptionFilter, lastError=0x57, pTarget=0026D0DC, pCtx=0E741820, ContextFlags=0x1003f, Eip=0xab2c694, Esp=0x26d608, Ebp=0x26d64c. Falling back to CopyOSContext.
CoreCLR: CopyContext failed in RedirectedHandledJITCaseExceptionFilter, lastError=0x57, pTarget=0026E01C, pCtx=0E741820, ContextFlags=0x1003f, Eip=0xab90864, Esp=0x26e538, Ebp=0x26e590. Falling back to CopyOSContext.

0x57 is ERROR_INVALID_PARAMETER. This suggests that the saved CONTEXT itself is usable, but Windows 7 x86 rejects the CopyContext() call, likely due to stricter requirements around the target context buffer or context flags.

Expected behavior

CoreCLR should not fatal with COR_E_EXECUTIONENGINE when CopyContext() fails in this old x86 simulated restore path if the saved CONTEXT can still be copied safely using CoreCLR's existing CopyOSContext() helper.

Actual behavior

On Windows 7 x86, CopyContext() returns FALSE with ERROR_INVALID_PARAMETER, and CoreCLR terminates the process via EEPOLICY_HANDLE_FATAL_ERROR(COR_E_EXECUTIONENGINE).

Regression?

No response

Known Workarounds

I changed the failure path to fall back to CoreCLR's existing CopyOSContext() helper instead of terminating the process:

CONTEXT* pTarget = pExcepPtrs->ContextRecord;
if (!CopyContext(pTarget, pCtx->ContextFlags, pCtx))
{
    STRESS_LOG1(LF_SYNC, LL_ERROR, "ERROR: CopyContext failed, lastError = 0x%x. Falling back to CopyOSContext.\n", GetLastError());
    CopyOSContext(pTarget, pCtx);
}

With this change, the same application ran overnight on Windows 7 x86 without crashing. The fallback path was hit multiple times, and execution continued successfully.

Configuration

• Runtime source: .NET 10.0.10
• Architecture: win-x86
• Deployment: self-contained
• OS where crash reproduces:
  • Windows 7 x86
  • Windows 7 x64 running the x86 app
• OS where this path does not appear to reproduce:
  • Windows 10 / Windows 11, because RtlRestoreContext is available

Other information

I understand Windows 7 may not be an officially supported OS for newer .NET versions. However, this fallback code path still exists specifically for x86 OSes without RtlRestoreContext, and the failure appears to be caused by the runtime treating CopyContext() failure as fatal instead of falling back to the existing OS context copy helper.

Would the runtime team consider accepting a guarded fallback to CopyOSContext() here?

[dotnet-policy-service]

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

[AaronRobinsonMSFT]

/cc @janvorli @jkotas

[MichalPetryka]

Windows 7 is not supported, any paths for handling it were supposed to be removed.

[jkotas]

any paths for handling it were supposed to be removed.

We have missed removing this one

[jkotas]

We have missed removing this one

Actually, this path is still needed on early Windows 10 versions - #131013 (comment)