FAST_FAIL_FATAL_APP_EXIT (0xc0000409) on first ReactNativeHost API call in Release/standalone builds — reproducible with minimal JS, on both 0.85.0-preview.1 and 0.84.0

Summary

A packaged (MSIX/AppX) or plain standalone Release .exe build of a ReactNativeWin32App (Composition/new-architecture template) crashes immediately at startup with FAST_FAIL_FATAL_APP_EXIT (0xc0000409), before any JS runs. The app works correctly only when launched via Visual Studio's F5 debugger with a live Metro connection — any other launch method (packaged AppX, plain .exe, with or without a prebuilt bundle) crashes every time.

Reproduced identically on both react-native-windows 0.85.0-preview.1 and 0.84.0 (stable), with react-native 0.85.3 and 0.84.1 respectively, so this isn't a preview-only regression.

Crash signature

• !analyze -v bucket: FAIL_FAST_FATAL_APP_EXIT_c0000409_ucrtbase.dll!abort
• An uncaught C++ exception is thrown, dispatch fails to find a handler, ucrtbase!terminate → ucrtbase!abort → int 29h.
• Microsoft.ReactNative.dll ships without a public PDB, so the stack only resolves to nearest exports (facebook::yoga::Node::operator=, facebook::yoga::Event::operator=) with large, unreliable offsets.

Exact call site (found via live cdb, breakpoint on VCRUNTIME140!_CxxThrowException)

The exception is thrown twice, both times with the identical _ThrowInfo pointer (i.e. the exact same exception type/throw site both times):

1. First throw: during reactNativeWin32App.ReactNativeHost().InstanceSettings() — caught/handled internally, execution continues.
2. Second throw: during reactNativeWin32App.AppWindow() — not caught this time, propagates to abort().

Both are immediately preceded by:

(pid.tid): Windows Runtime Originate Error - code 40080201 (first chance)
(pid.tid): C++ EH exception - code e06d7363 (first chance)

The 40080201 code is completely consistent across every single run (different RNW versions, different builds, minimal vs. real app JS).

Reproduction is JS-content-independent

Reproduced with the actual app's real JS bundle and with a trivial one-line <Text> component as index.windows.js — identical crash, identical signature, identical call site. This rules out anything in application JS/config; it happens before any bundle is even read (crash occurs during InstanceSettings()/AppWindow(), both called before BundleRootPath/JavaScriptBundleFile are set).

Environment

• Visual Studio 2026 (18.10.1-1.26427.6), MSBuild toolset v145
• Windows SDK 10.0.22621.0 (RNW's default WindowsTargetPlatformVersion) and 10.0.26100.0 both tested, same result
• Windows 11, build 26100 (host)
• New Architecture (Fabric) enabled — default project template, RnwNewArch/USE_WINUI3/RNW_NEW_ARCH all defined
• Note: the vendored .vcxproj for @react-native-async-storage/async-storage's Windows native module hardcodes PlatformToolset v143, which VS2026 no longer ships — had to patch to v145 to build at all. Possibly indicates this whole toolchain combination (RNW + VS2026) isn't yet a validated/supported pairing.

Possibly related

microsoft/react-native-windows#14954 — same failure bucket (FAIL_FAST_FATAL_APP_EXIT_c0000409_microsoft.reactnative.dll) reported via Microsoft's own telemetry against 0.82, closed without a documented root cause.

What would help

Since Microsoft.ReactNative.dll has no public PDB, we can't identify the exact throwing function or exception message ourselves. A build with symbols, or pointers to what InstanceSettings()/AppWindow() might throw internally (e.g. Yoga config validation, a DirectX/Composition device query, or a WinRT activation failure under RoOriginateError code 0x40080201) would let us narrow this down further.

Repro steps

1. npx react-native-windows-init (Composition/new-arch C++ app template) or equivalent existing project.
2. Build Release x64, either as packaged AppX or as the plain intermediate .exe.
3. Launch it directly (not via VS F5) — crashes within ~1 second, before any window is shown.
4. Launching the same binary via VS F5 with a live Metro packager connection works fine.