[firebase_core] Windows Debug crash in App::RegisterLibrary (access violation writing 0x0) before Firebase.initializeApp

[rlomazzimitric]

Is there an existing issue for this?

• I have searched the existing issues.

Which plugins are affected?

Core

Which platforms are affected?

Windows

Description

On Windows Debug, a Flutter app that depends on firebase_core crashes immediately after a successful native build, before the window appears and before Dart can call Firebase.initializeApp().

Flutter reports:

Error waiting for a debug connection: The log reader stopped unexpectedly, or never started.

Windows Event Viewer records 0xC0000005 (access violation) on the app executable.

A Visual Studio debugger break shows the crash inside Firebase C++ LibraryRegistry::RegisterLibrary, while writing '\0' through std::string::assign to address 0x0. _Count is 0 (empty string assign).

This happens during native plugin registration, not during Dart init.

Call site in firebase_core Windows (firebase_core_plugin.cpp):

void FirebaseCorePlugin::RegisterWithRegistrar(
    flutter::PluginRegistrarWindows* registrar) {
  auto plugin = std::make_unique<FirebaseCorePlugin>();
  FirebaseCoreHostApi::SetUp(registrar->messenger(), plugin.get());
  FirebaseAppHostApi::SetUp(registrar->messenger(), plugin.get());
  registrar->AddPlugin(std::move(plugin));
  // Register for platform logging
  App::RegisterLibrary(kLibraryName.c_str(), getPluginVersion().c_str(),
                       nullptr);
}

That RegisterLibrary call is reached from FirebaseCorePluginCApiRegisterWithRegistrar in RegisterPlugins(), while creating the Flutter Windows engine — before any Dart Firebase.initializeApp().

Isolation

• Release (and typically Profile): app starts.
• Debug: crash as above.
• Commenting out FirebaseCorePluginCApiRegisterWithRegistrar(...) in generated_plugin_registrant.cc (must rebuild without letting Flutter regenerate that file): Debug starts.
• Restoring the call: crash returns.
• The crash is therefore this registration path (RegisterLibrary / platform logging), not the placement of Firebase.initializeApp() in Dart.

Environment:

• Windows 11
• Visual Studio 2026 Community (generator Visual Studio 18 2026)
• MSVC platform toolset v143 (VS 2026 default v145; v143 forced in CMake)
• Flutter 3.44.9 stable (Dart 3.12.2)
• firebase_core 4.14.0 (Firebase C++ SDK 13.11.0)
• Also in the app: firebase_analytics 12.5.0, firebase_crashlytics 5.3.0, firebase_messaging 16.6.0
• Windows actually uses Analytics only; Crashlytics/Messaging are not initialized on that platform. Those packages do not need to be in a minimal repro.

Expected

Debug flutter run -d windows starts the app. App::RegisterLibrary during plugin registration must not access-violate, especially before Firebase.initializeApp().

Actual

Process dies in RegisterLibrary (c0000005 write to NULL). Flutter loses the debug log reader. No Dart exception.

Reproducing the issue

Minimal:

1. flutter create firebase_windows_debug_crash
2. cd firebase_windows_debug_crash
3. flutter pub add firebase_core:4.14.0
4. In lib/main.dart, after WidgetsFlutterBinding.ensureInitialized():

await Firebase.initializeApp(
  options: const FirebaseOptions(
    apiKey: 'dummy',
    appId: '1:1:web:1',
    messagingSenderId: '1',
    projectId: 'dummy',
  ),
);

(Even without this Dart call, the crash may still happen, because registration is native.)

5.flutter run -d windows (Debug)
If it still crashes, skip step 4 and run Debug with only the firebase_core dependency.

Observed in a real app:

1. flutter run -d windows (Debug) with firebase_core: 4.14.0.
2. Windows build succeeds (Built ...\runner\Debug\<app>.exe).
3. Process starts, then exits immediately (optional warning about unmerged UI/platform threads is unrelated).
4. Attach VS 2026 to the Debug exe, break on Win32 access violation: stack below.
5. Workaround: do not call App::RegisterLibrary in FirebaseCorePlugin::RegisterWithRegistrar (or skip FirebaseCorePluginCApiRegisterWithRegistrar). Debug then launches.

Firebase Core version

4.14.0

Flutter Version

3.44.9

Relevant Log Output

-- Flutter (Debug)
√ Built build\windows\x64\runner\Debug\checker_multiplatform.exe
Error waiting for a debug connection: The log reader stopped unexpectedly, or never started.
Error launching application on Windows.

--Visual Studio 2026 call stack:
[Exception at 0x... in <app>.exe: 0xC0000005: access violation writing location 0x0000000000000000.]
> <app>.exe!std::_Narrow_char_traits<char,int>::assign(char & _Left, const char & _Right='\0')
  <app>.exe!std::string::assign(const char * const _Ptr=..., const unsigned __int64 _Count=0)
  <app>.exe!firebase::app_common::LibraryRegistry::RegisterLibrary(char const *, char const *)
  ... (unknown frames; Firebase C++ libs have no PDBs)

Flutter dependencies

Expand Flutter dependencies snippet

- firebase_analytics_platform_interface 6.0.7 [_flutterfire_internals firebase_core flutter meta plugin_platform_interface]
- firebase_analytics_web 0.6.1+13 [_flutterfire_internals firebase_analytics_platform_interface firebase_core firebase_core_web flutter flutter_web_plugins]
- firebase_core_platform_interface 8.1.1 [collection flutter meta plugin_platform_interface]
- firebase_core_web 3.11.0 [firebase_core_platform_interface flutter flutter_web_plugins meta web]
- firebase_crashlytics_platform_interface 3.9.0 [_flutterfire_internals collection firebase_core firebase_core_platform_interface flutter meta plugin_platform_interface]
- firebase_messaging_platform_interface 4.10.0 [_flutterfire_internals firebase_core flutter meta plugin_platform_interface]
- firebase_messaging_web 4.2.5 [_flutterfire_internals firebase_core firebase_core_web firebase_messaging_platform_interface flutter flutter_web_plugins meta web]

Additional context and comments

Notes for maintainers:

• Debug links ...\firebase_cpp_sdk_windows\libs\windows\VS2019\MD\x64\Debug\firebase_app.lib with /MDd (MultiThreadedDebugDLL). Release links the Release .lib with /MD. This does not look like mixing Release Firebase libs into a Debug app.
• Flutter Windows APPLY_STANDARD_SETTINGS defines _HAS_EXCEPTIONS=0 (and firebase_core applies those settings to the plugin). Combined with /EHsc, that can change std::string layout vs prebuilt Firebase C++ libs.
• RegisterLibrary runs at plugin registration, before any firebase::App exists.

[russellwheatley]

Hey @rlomazzimitric - thank you for the detailed write up.

Your isolation to App::RegisterLibrary lines up with what I'd expect: it's the first call from the plugin into the prebuilt firebase_app.lib, so if there's an ABI mismatch between how that lib was built and how Flutter's Windows Debug runner compiles the plugin, this is exactly where it'd surface, writing into a std::string whose memory layout doesn't match what the caller assumes. Your _HAS_EXCEPTIONS=0 note is a reasonable thread to pull on, MSVC's STL types can lay out differently depending on exception model and _ITERATOR_DEBUG_LEVEL, so if those differ between how the app is compiled and how the SDK's libs were compiled, you'd get exactly this kind of null write in std::string::assign.

We can get this looked at and see what the issue is.