[Bug]: Process fail-fast (0xC0000409) on Windows x64 when guest traps under .NET 9+ (CET shadow stack)

La reproducción mínima está en Program.cs; primero ejecuta su apphost generado en net8.0 y net9.0+/net10.0 con la matriz de CET. Después inspecciona la continuación de recuperación de traps de Windows de wasmtime.dll y los metadatos apphost emitidos; se considera terminado cuando los guest traps señalizados por hardware vuelven a aparecer como TrapException bajo CET, mientras el comportamiento de fuel y epoch permanece intacto.

Summary

On Windows x64, a WebAssembly guest trap that is hardware-signaled (unreachable, memory out-of-bounds, integer divide-by-zero) terminates the host process with 0xC0000409 (STATUS_STACK_BUFFER_OVERRUN, exit -1073740791) instead of surfacing as a catchable Wasmtime.TrapException.

Root cause (confirmed): Intel CET / hardware shadow stack enforcement. Since .NET 9 Preview 6, the .NET SDK marks the generated Windows apphost executable with /CETCOMPAT (documented breaking change). This enables the hardware shadow stack for the process. Wasmtime's Windows trap recovery performs a non-local thread-context restore to a landing pad that is neither present on the shadow stack nor registered in an EH continuation allow-list, so Windows terminates the process.

Cooperative metered traps (fuel / epoch) are not affected — they return through the normal call path and never perform a non-local context restore.

[!NOTE]
This issue was originally filed as a .NET 10 regression with an SEH / security-cookie theory, and stated that disabling CET had no effect. All three of those claims were wrong. They are struck through in Retracted claims at the bottom rather than deleted, since earlier comments refer to them. Body corrected 2026-08-17.

---

Environment

OS	Windows 11, build 26200 (x64)
CPU	AMD Ryzen 7 7735HS (Zen 3+, shadow-stack capable)
SDK	.NET SDK 10.0.302
Runtimes	Microsoft.NETCore.App 8.0.30 and 10.0.10
Package	Wasmtime 44.0.0
System mitigation policy	UserShadowStack: NOTSET (OS defaults, no per-machine override)
Configurations	Reproduces in both Debug and Release, deterministically (5/5 runs)

Although the feature is branded Intel CET, this reproduces on an AMD CPU — it is not vendor-specific.

_{The original report listed ".NET SDK: .NET 10.0.10". That figure is the runtime version (Microsoft.NETCore.App 10.0.10), not the SDK version; .NET SDK versions use feature bands (10.0.3xx), and the SDK here is 10.0.302. Both are listed above under the correct names.}

Affected .NET versions: 9.0 and later (anything whose apphost is /CETCOMPAT-marked). .NET 8 and earlier are unaffected.

---

Trap matrix

Each scenario runs in its own process so that a fail-fast in one cannot mask the others.

Guest trap	.NET 8	.NET 10 (CET on)	.NET 10 (CET disabled)
unreachable	✅ Unreachable	❌ 0xC0000409	✅ Unreachable
memory out-of-bounds load	✅ MemoryOutOfBounds	❌ 0xC0000409	✅ MemoryOutOfBounds
integer divide-by-zero	✅ IntegerDivisionByZero	❌ 0xC0000409	✅ IntegerDivisionByZero
fuel exhaustion	✅ OutOfFuel	✅ OutOfFuel	✅ OutOfFuel
epoch interruption	✅ Interrupt	✅ Interrupt	✅ Interrupt

---

Minimal reproduction

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Wasmtime" Version="44.0.0" />
  </ItemGroup>
</Project>

Program.cs:

using Wasmtime;

Console.WriteLine("Starting Wasmtime probe on Windows x64...");

using var engine = new Engine();
using var module = Module.FromText(engine, "unreachable_test", @"
(module
  (func (export ""run"")
    unreachable
  )
)
");

using var linker = new Linker(engine);
using var store = new Store(engine);
var instance = linker.Instantiate(store, module);
var run = instance.GetFunction("run");

if (run is null)
{
    Console.Error.WriteLine("Failed to find exported function 'run'");
    return 1;
}

try
{
    Console.WriteLine("Invoking guest function that traps...");
    run.Invoke();
    Console.Error.WriteLine("FAIL: Expected TrapException was not thrown.");
    return 1;
}
catch (TrapException ex)
{
    Console.WriteLine($"SUCCESS: Caught expected TrapException: {ex.Message}");
    return 0;
}

Steps:

1. Build and run the generated .exe on net8.0 → prints SUCCESS, exit 0.
2. Rebuild on net10.0 (or net9.0) and run the generated .exe → process terminates, exit -1073740791.

Run the generated apphost .exe, not dotnet run/dotnet app.dll. dotnet.exe is not CET-marked, so launching through it hides the bug entirely.

---

Root-cause evidence

Isolation controls. Each row changes exactly one variable against the net10.0 baseline:

Experiment	Result	Eliminates
net8.0 app on .NET 8 runtime	✅ exit 0	— (baseline)
net8.0 app forced onto the .NET 10.0.10 runtime (DOTNET_ROLL_FORWARD=LatestMajor, resolution confirmed via COREHOST_TRACE=1)	✅ exit 0	the runtime version
net10.0 app with DOTNET_LegacyExceptionHandling=1	❌ 0xC0000409	the new managed EH model added in .NET 9
net10.0 app with lib/net8.0/Wasmtime.Dotnet.dll swapped in	❌ 0xC0000409	the managed assembly / package asset selection
net10.0 app launched via dotnet.exe instead of its apphost	✅ exit 0	→ isolates the host executable
net10.0 apphost with the CET bit patched to 0	✅ exit 0	→ causation, single bit
net10.0 rebuilt with <CetCompat>false</CetCompat>	✅ exit 0	→ supported workaround

Two of these deserve emphasis:

• The .NET 10 runtime is not implicated. The same runtime executes the same IL successfully when the process is launched by a non-CET host.
• Package asset selection is a red herring. A net10.0 project resolves lib/net9.0/Wasmtime.Dotnet.dll while net8.0 resolves lib/net8.0/…; those files differ in content (identical length, same 44.0.0.0 assembly version). "The net9 managed build is at fault" is a natural first guess and it is wrong — forcing the net8.0 assembly into the net10.0 app still fail-fasts.

PE-level state. IMAGE_DLLCHARACTERISTICS_EX_CET_COMPAT (debug directory type 20) and the load-config EH continuation table:

Binary	CET compat	GuardFlags	EH continuation targets
apphost (net8.0 build)	absent	0x10417500	12
apphost (net10.0 build)	SET	0x10417500	12
dotnet.exe (10.0.10)	absent	—	—
coreclr.dll (10.0.10)	—	0x10417500	1017
wasmtime.dll (44.0.0, win-x64)	absent	0x00000100	0

The apphost carried /EHCONT in both .NET 8 and .NET 10. What .NET 9 changed is the CETCOMPAT bit that makes the constraint enforced — not the presence of continuation metadata. wasmtime.dll registers zero EH continuation targets and is not CFG-instrumented, so no address it continues to can be on an allow-list, by construction.

---

Workaround

Opt the application out of CET:

<PropertyGroup>
  <CetCompat>false</CetCompat>
</PropertyGroup>

This restores correct TrapException behavior for every trap kind. Verify the flag actually landed in the emitted binary — an incremental build will silently reuse an already-generated CET-marked apphost and the property will appear to do nothing:

dotnet build -c Release -p:CetCompat=false --no-incremental

Trade-off: this disables ROP protection for the whole process, so it is a mitigation rather than a fix.

Alternatively, opt the specific executable out via Windows Security / exploit-protection policy (UserShadowStack).

---

Proposed upstream resolution

wasmtime-dotnet (or Wasmtime's Windows trap handling) needs to make its trap-recovery continuation target legal under CET. The correct mechanism depends on where that landing pad lives, which I have not established:

• if it is static code inside wasmtime.dll (a setjmp-style recovery point) → building that library with /EHCONT (plus CFG) is sufficient;
• if it is JIT-generated code → SetProcessDynamicEHContinuationTargets must be called at runtime as code regions are published.

At minimum, shipping a win-x64 wasmtime.dll that is CET-aware would let .NET 9+ consumers keep shadow-stack protection enabled.

What I did not do: I did not attach a debugger to capture the faulting continuation address or the fail-fast subcode, so the specific RtlRestoreContext/NtContinue attribution is inference from the documented CET contract, not a direct observation. My measurements stop at "wasmtime.dll registers zero continuation targets." Happy to run that debugger session if it would help.

---

Retracted claims from the original report

Preserved for reference because earlier comments respond to them.

1. "This is a .NET 10 regression; .NET 8 works." → The trigger landed in .NET 9 Preview 6. .NET 8 does work, but .NET 9 is equally affected; I simply went 8 → 10 and never tested 9.
2. "Disabling CET (Hardware-enforced Stack Protection) does not alter the behavior." → False. Disabling CET fixes it completely, on every trap kind. My original observation was almost certainly an incremental build reusing the CET-marked apphost — the rebuild reported success in 0.39 s and emitted an exe whose CET bit was still set.
3. "Changes to SEH stack unwinding or security cookies in .NET 10 conflict with Wasmtime's native exception handler." → No evidence. DOTNET_LegacyExceptionHandling=1 does not help, which specifically rules out the .NET 9+ managed exception-handling rewrite.

Still standing from the original report: metered fuel/epoch traps behave correctly (re-verified above). The claim that Linux hosts (POSIX signals) are unaffected is carried over from the original report and was not re-tested in this round — though it is consistent with the mechanism, since CET shadow-stack enforcement is a Windows process mitigation.