Repository navigation
[firebase_core] Windows Debug crash in App::RegisterLibrary (access violation writing 0x0) before Firebase.initializeApp #18642
Description
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(...)ingenerated_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 ofFirebase.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_core4.14.0 (Firebase C++ SDK 13.11.0)- Also in the app:
firebase_analytics12.5.0,firebase_crashlytics5.3.0,firebase_messaging16.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:
flutter create firebase_windows_debug_crashcd firebase_windows_debug_crashflutter pub add firebase_core:4.14.0- In
lib/main.dart, afterWidgetsFlutterBinding.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:
flutter run -d windows(Debug) withfirebase_core: 4.14.0.- Windows build succeeds (
Built ...\runner\Debug\<app>.exe). - Process starts, then exits immediately (optional warning about unmerged UI/platform threads is unrelated).
- Attach VS 2026 to the Debug exe, break on Win32 access violation: stack below.
- Workaround: do not call
App::RegisterLibraryinFirebaseCorePlugin::RegisterWithRegistrar(or skipFirebaseCorePluginCApiRegisterWithRegistrar). 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.libwith/MDd(MultiThreadedDebugDLL). Release links the Release.libwith/MD. This does not look like mixing Release Firebase libs into a Debug app. - Flutter Windows
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.
Activity
russellwheatley commentedon 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.
SelaseKay commentedon Sep 14, 2026
cc @Lyokone
rlomazzimitric commentedon Sep 24, 2026
Any update on this issue?
SelaseKay commentedon Sep 28, 2026
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*: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:
cl.exebanner, and whether a Debug build with VS 2022 (toolset v143, not VS 2026) crashes the same way.App::RegisterLibraryline, and callFirebase.initializeApp. Does it crash inApp::Createwith the same access violation?msvcp140d.dllthe 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 debugfirebase_app.libagainst the VS 2026 debug CRT. IfinitializeAppsucceeds, the failure is specific toRegisterLibraryand we should dig into that call.google-oss-bot commentedon Oct 6, 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!
rlomazzimitric commentedon Oct 12, 2026
Hi, sorry for the late reply.
I've applied some modifications to the project in which I've encountered the error:
MSVC v143declaration in theCMakeLists.txtfilefirebase_core: 4.15.018.10.3The issue does not present itself anymore, even after various builds.
I could not reproduce this in another new project.
SelaseKay commentedon Oct 12, 2026
Hi @rlomazzimitric, thanks for the feedback. Based on that, issue is more likely tied to your environment rather than a flutterfire bug. Closing this.
rlomazzimitric commentedon Oct 14, 2026
The crash was not in
firebase_core. An internal Windows plugin downloads a third-party C++ library withFetchContent, and that library's CMake forcesCMAKE_BUILD_TYPE=Releaseinto the cache when the variable is empty.With the Visual Studio generator that value has to stay empty.
firebase_coreuses it to choose the prebuiltfirebase_app.lib. The first configure still selected the Debug library, because the plugin runs later. The next configure linkedVS2019/MD/x64/Release/firebase_app.libinto the Debug app (/MDd). Startup then failed with0xC0000005instd::stringinsideApp::RegisterLibrary.The plugin now sets a non-cache placeholder around
FetchContent_MakeAvailableand clears it afterwards, so the third-party project cannot write the cache. Repeated Debug builds keep linking the Debug library, and the app starts.I apologize for opening the issue here as the fault was in another internally developed package.