Skip to content

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

Description

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

Activity

  1. russellwheatley commented on Sep 4, 2026

    @russellwheatley
    Member

    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.

  2. SelaseKay commented on Sep 14, 2026

    @SelaseKay
    Contributor
  3. rlomazzimitric commented on Sep 24, 2026

    @rlomazzimitric
    Author

    Any update on this issue?

  4. SelaseKay commented on Sep 28, 2026

    @SelaseKay
    Contributor

    Hi @rlomazzimitric, thanks for the stack and the isolation notes. I tried the minimal repro (flutter create, firebase_core 4.14.0, Debug flutter run -d windows) and could not reproduce the crash, so this looks specific to the toolchain in the report rather than something every Windows Debug build hits.
    App::RegisterLibrary does run from FirebaseCorePlugin::RegisterWithRegistrar, before Firebase.initializeApp. The call only passes const char*:

    App::RegisterLibrary(kLibraryName.c_str(), getPluginVersion().c_str(), nullptr);

    The std::string::assign in the stack is inside the prebuilt SDK (LibraryRegistry::RegisterLibrary in firebase_app.lib), not in the plugin. On the first registration that function looks the library up, misses, and assigns an empty string. An empty assign through a null buffer pointer is a write to address 0, which matches the access violation. Flutter's _HAS_EXCEPTIONS=0 is set on the plugin target. It does not recompile that function, which ships already built in libs/windows/VS2019/MD/x64/Debug/firebase_app.lib.
    Skipping plugin registration will let the process start, because that skips the first call into the SDK. App::Create also uses std::string inside the same library, so the same failure can show up at Firebase.initializeApp if the problem is the debug runtime rather than this one call.
    What would help narrow it down:

    1. The cl.exe banner, and whether a Debug build with VS 2022 (toolset v143, not VS 2026) crashes the same way.
    2. Leave the plugin registered, remove only the App::RegisterLibrary line, and call Firebase.initializeApp. Does it crash in App::Create with the same access violation?
    3. The path and file version of the msvcp140d.dll the crashing process loads.
      Your environment (VS 2026, generator Visual Studio 18 2026, v143 forced over the default v145) is the main difference from the setup where this did not reproduce. Release and Profile surviving fits the release libraries, which use the stable release CRT. If (2) also crashes, the next place to look is the VS2019 debug firebase_app.lib against the VS 2026 debug CRT. If initializeApp succeeds, the failure is specific to RegisterLibrary and we should dig into that call.
  5. added
    blocked: customer-responseWaiting for customer response, e.g. more information was requested.
    and removed
    Needs AttentionThis issue needs maintainer attention.
    on Sep 28, 2026
  6. google-oss-bot commented on Oct 6, 2026

    @google-oss-bot
    Collaborator

    Hey @rlomazzimitric. We need more information to resolve this issue but there hasn't been an update in 7 weekdays. I'm marking the issue as stale and if there are no new updates in the next 7 days I will close it automatically.

    If you have more information that will help us get to the bottom of this, just add a comment!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    StaleIssue with no recent activityblocked: customer-responseWaiting for customer response, e.g. more information was requested.platform: windowsIssues / PRs which are specifically for Windows.plugin: coretype: bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions