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

[Dancraft3746]

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.

[Dancraft3746]

Root Cause Update: Intel CET (Hardware Shadow Stack) Compatibility on Windows x64

After further binary and PE-level isolation, we have pinpointed the exact root cause of this crash:

1. The Trigger: Intel CET Enabled by Default in .NET AppHost

Starting with .NET 9 (and .NET 10), the .NET SDK automatically marks generated Windows apphost executables with /CETCOMPAT (IMAGE_DLLCHARACTERISTICS_EX_CET_COMPAT).

When running a net10.0 app via its generated .exe apphost, CET is active. However, running the exact same compiled .dll through dotnet.exe (which is not CET-marked) succeeds with exit 0 and catches TrapException cleanly.

2. The Mechanism: RtlRestoreContext Violation of Hardware Shadow Stack

During a hardware-signaled WebAssembly trap (unreachable, memory out-of-bounds, integer divide-by-zero), Wasmtime's Windows exception handler restores thread context (RtlRestoreContext / NtContinue) to jump to the recovery landing pad.
Under CET shadow stack enforcement, non-local context jumps to dynamically generated JIT addresses without registered continuation metadata violate CET constraints, causing the OS to immediately fail-fast with 0xC0000409 (STATUS_STACK_BUFFER_OVERRUN).
Cooperative metered traps (fuel / epoch) do not execute non-local unwinding and thus succeed under CET.

3. Verification & Workaround

• Single-Bit Causation Proof: Patching the IMAGE_DLLCHARACTERISTICS_EX_CET_COMPAT bit to 0 in the PE header of the net10.0 apphost executable immediately eliminates the crash (exit 0).
• MSBuild Workaround: Rebuilding the project with <CetCompat>false</CetCompat> (using a clean rebuild --no-incremental to ensure the apphost is regenerated) fully resolves the crash and allows TrapException to be caught as expected:

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

4. Proposed Upstream Resolution

To make wasmtime-dotnet fully compatible with CET on Windows x64:

• The Cranelift / Wasmtime Windows JIT engine should register trap continuation landing pads with the Windows kernel via SetProcessDynamicEHContinuationTargets (or compile native trampolines with /EHCONT).

[Dancraft3746]

Issue body and title corrected — flagging it here, since GitHub doesn't notify subscribers of body edits.

Root cause stands as described in my previous comment (Intel CET / hardware shadow stack). Three claims in my original report were wrong and are now struck through in the body:

1. Not a .NET 10 regression. The apphost has been /CETCOMPAT-marked since .NET 9 Preview 6 (documented breaking change). Title updated — .NET 9 users are equally affected and would not have found this issue.
2. "Disabling CET has no effect" was false. <CetCompat>false</CetCompat> resolves every trap kind. My original observation was an incremental build silently reusing the already-generated CET-marked apphost — use --no-incremental and verify the bit in the emitted binary.
3. The SEH / security-cookie theory is withdrawn. DOTNET_LegacyExceptionHandling=1 does not help, which rules out the .NET 9+ managed exception-handling rewrite specifically.

The body now also carries the isolation controls — the important one being that the same IL on the same .NET 10.0.10 runtime succeeds when launched via dotnet.exe, so the runtime itself is not implicated — plus a five-scenario trap matrix and PE evidence that wasmtime.dll registers zero EH continuation targets.

The open question for maintainers is at the end of the body: whether the trap-recovery landing pad is static code in wasmtime.dll (in which case /EHCONT suffices) or JIT-generated (in which case SetProcessDynamicEHContinuationTargets is needed at runtime). I have not established which, and I did not capture the faulting continuation address under a debugger — happy to do that if it would help.