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

[yifanCandy]

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

#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.

[yifanCandy]

Follow-up: ruled out one likely-looking cause.

#12752 has a very similar symptom (works via VS/Metro, crashes standalone Release) traced to an unpackaged app being unable to activate DispatcherQueueController because it can't see the WinUI3/Windows App SDK framework package (WinRT originate error - 0x80040154 : 'Class not registered') — and we did see 0x80040154 show up in a stack-arg slot in one of our own dumps, so this looked very promising.

However, we ruled it out directly:

1. Self-signed the .msix with a cert matching the manifest's Publisher (CN=lingxi-build), imported it into LocalMachine\TrustedPeople and LocalMachine\Root.
2. Add-AppxPackage — package installs cleanly to C:\Program Files\WindowsApps\..., real package identity (not "run from layout").
3. Confirmed Microsoft.WindowsAppRuntime.1.8 (version 8000.859.21.0, matching the manifest's PackageDependency MinVersion) and the required Microsoft.VCLibs.140.00.UWPDesktop are already installed on the machine.
4. Launched via its real PackageFamilyName!AppId through shell:appsFolder (proper AppX activation, not a raw .exe start).

Same crash, identical signature and nearest-symbol stack (FAIL_FAST_FATAL_APP_EXIT_c0000409_ucrtbase.dll!abort, uncaught exception inside Microsoft.ReactNative.dll). So in our case it isn't a WinUI3-framework-package-resolution issue — the app has full package identity, the correct framework version is present, and it still crashes the same way. Posting this in case it saves someone else from chasing the same dead end.