microsoft / microsoft/react-native-windows
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
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 17.3k
- Forks
- 1.2k
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 33
Description
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 -vbucket: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.dllships 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):
- First throw: during
reactNativeWin32App.ReactNativeHost().InstanceSettings()— caught/handled internally, execution continues. - Second throw: during
reactNativeWin32App.AppWindow()— not caught this time, propagates toabort().
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_ARCHall defined - Note: the vendored
.vcxprojfor@react-native-async-storage/async-storage's Windows native module hardcodesPlatformToolset v143, which VS2026 no longer ships — had to patch tov145to 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
npx react-native-windows-init(Composition/new-arch C++ app template) or equivalent existing project.- Build Release x64, either as packaged AppX or as the plain intermediate
.exe. - Launch it directly (not via VS F5) — crashes within ~1 second, before any window is shown.
- Launching the same binary via VS F5 with a live Metro packager connection works fine.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the Release x64 standalone or packaged build using the minimal JavaScript case, then debug the first ReactNativeHost().InstanceSettings() and AppWindow() calls with cdb. Investigate the uncaught C++ exception and Windows Runtime error 0x40080201, using symbols if available. Done means the same binary launches without FAST_FAIL_FATAL_APP_EXIT outside Visual Studio F5.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, react-native
- Domain
- desktop, operating-systems
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100