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

Open
#16,442 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Needs: Triage :mag:
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 -v bucket: FAIL_FAST_FATAL_APP_EXIT_c0000409_ucrtbase.dll!abort
  • An uncaught C++ exception is thrown, dispatch fails to find a handler, ucrtbase!terminateucrtbase!abortint 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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.