Repository navigation
[firebase_core] Windows Debug crash in App::RegisterLibrary (access violation writing 0x0) before Firebase.initializeApp #18642
Description
Activity
- addedtype: bugSomething isn't workingSomething isn't workingNeeds AttentionThis issue needs maintainer attention.This issue needs maintainer attention.
on Sep 4, 2026 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.
- addedplatform: windowsIssues / PRs which are specifically for Windows.Issues / PRs which are specifically for Windows.and removedNeeds AttentionThis issue needs maintainer attention.This issue needs maintainer attention.
on Sep 4, 2026 - addedNeeds AttentionThis issue needs maintainer attention.This issue needs maintainer attention.
on Sep 7, 2026 cc @Lyokone
Any update on this issue?
Hi @rlomazzimitric, thanks for the stack and the isolation notes. I tried the minimal repro (
flutter create,firebase_core4.14.0, Debugflutter 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::RegisterLibrarydoes run fromFirebaseCorePlugin::RegisterWithRegistrar, beforeFirebase.initializeApp. The call only passesconst char*:App::RegisterLibrary(kLibraryName.c_str(), getPluginVersion().c_str(), nullptr);
The
std::string::assignin the stack is inside the prebuilt SDK (LibraryRegistry::RegisterLibraryinfirebase_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 address0, which matches the access violation. Flutter's_HAS_EXCEPTIONS=0is set on the plugin target. It does not recompile that function, which ships already built inlibs/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::Createalso usesstd::stringinside the same library, so the same failure can show up atFirebase.initializeAppif the problem is the debug runtime rather than this one call.
What would help narrow it down:- The
cl.exebanner, and whether a Debug build with VS 2022 (toolset v143, not VS 2026) crashes the same way. - Leave the plugin registered, remove only the
App::RegisterLibraryline, and callFirebase.initializeApp. Does it crash inApp::Createwith the same access violation? - The path and file version of the
msvcp140d.dllthe crashing process loads.
Your environment (VS 2026, generatorVisual 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 debugfirebase_app.libagainst the VS 2026 debug CRT. IfinitializeAppsucceeds, the failure is specific toRegisterLibraryand we should dig into that call.
- The
- addedblocked: customer-responseWaiting for customer response, e.g. more information was requested.Waiting for customer response, e.g. more information was requested.and removedNeeds AttentionThis issue needs maintainer attention.This issue needs maintainer attention.
on Sep 28, 2026 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!
Is there an existing issue for this?
Which plugins are affected?
Core
Which platforms are affected?
Windows
Description
On
Windows Debug, a Flutter app that depends onfirebase_corecrashes immediately after a successful native build, before the window appears and before Dart can callFirebase.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'throughstd::string::assignto address0x0._Countis0(empty string assign).This happens during native plugin registration, not during Dart init.
Call site in
firebase_coreWindows (firebase_core_plugin.cpp):That
RegisterLibrarycall is reached fromFirebaseCorePluginCApiRegisterWithRegistrarinRegisterPlugins(), while creating the Flutter Windows engine — before any DartFirebase.initializeApp().Isolation
FirebaseCorePluginCApiRegisterWithRegistrar(...)ingenerated_plugin_registrant.cc(must rebuild without letting Flutter regenerate that file): Debug starts.RegisterLibrary/ platform logging), not the placement ofFirebase.initializeApp()in Dart.Environment:
Visual Studio 18 2026)firebase_core4.14.0 (Firebase C++ SDK 13.11.0)firebase_analytics12.5.0,firebase_crashlytics5.3.0,firebase_messaging16.6.0Expected
Debug
flutter run -d windowsstarts the app.App::RegisterLibraryduring plugin registration must not access-violate, especially beforeFirebase.initializeApp().Actual
Process dies in
RegisterLibrary(c0000005write toNULL). Flutter loses the debug log reader. No Dart exception.Reproducing the issue
Minimal:
flutter create firebase_windows_debug_crashcd firebase_windows_debug_crashflutter pub add firebase_core:4.14.0lib/main.dart, afterWidgetsFlutterBinding.ensureInitialized():(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:
flutter run -d windows(Debug) withfirebase_core: 4.14.0.Built ...\runner\Debug\<app>.exe).App::RegisterLibraryinFirebaseCorePlugin::RegisterWithRegistrar(or skipFirebaseCorePluginCApiRegisterWithRegistrar). Debug then launches.Firebase Core version
4.14.0
Flutter Version
3.44.9
Relevant Log Output
Flutter dependencies
Expand
Flutter dependenciessnippetAdditional context and comments
Notes for maintainers:
...\firebase_cpp_sdk_windows\libs\windows\VS2019\MD\x64\Debug\firebase_app.libwith/MDd(MultiThreadedDebugDLL). Release links the Release.libwith/MD. This does not look like mixing Release Firebase libs into a Debug app.APPLY_STANDARD_SETTINGSdefines_HAS_EXCEPTIONS=0(and firebase_core applies those settings to the plugin). Combined with/EHsc, that can changestd::stringlayout vs prebuilt Firebase C++ libs.RegisterLibraryruns at plugin registration, before anyfirebase::Appexists.