[Windows] `showNotification` crash with Desktop thread merging (3.32.8)
Describe the bug
When calling showNotification after an invoke call to other C++ Windows native code, the app crashes. Attaching Visual Studio's debugger shows an exception coming from here, but also sometimes from here. I can't reproduce it 100% of the times. Removing the Desktop thread merging opt-in support seems to avoid the crash, but it will be the default behavior in a future release. Latest 3.35 beta also has the same crash. I couldn't get any sample project to reproduce it since it could be conflicting with our own native code. Have you seen something similar happening? Are there any potential improvements that can be made to make sure that those 2 methods don't crash with Desktop thread merging?
For the first method, GPT-5 suggested something like this, and looks like the crashes are either gone or happening with much less frequency:
try {
plugin->notifier.value().Show(notification);
} catch (const winrt::hresult_error& e) {
// Optional: OutputDebugString/printf with e.code().value() and e.message()
// Recreate notifier and retry once
plugin->notifier.reset();
plugin->history.reset();
plugin->notifier = plugin->hasIdentity
? ToastNotificationManager::CreateToastNotifier()
: ToastNotificationManager::CreateToastNotifier(plugin->aumid);
try {
plugin->notifier.value().Show(notification);
} catch (...) {
return false; // prevent crash
}
}
However, the attempts on cancelAll haven't worked so far.
I don't use Flutter for Windows myself so haven't run into this. Would you be able to provide a link to a repository hosting a minimal app that can reproduce the scenario you're describing? This could be a fork of this repository where the example app has been modified to reproduce the issue
I haven't been able to create a sample project where I can reliably reproduce this so far. I'll do another investigation round once I upgrade to Flutter 3.35 in case it still happens there. This is the feature I'm referring to in the original post.
Hm this does sound like something I ran into while developing it. At one point I also had a file to demonstrate the crash, and I managed to get it to be more stable, but I didn't really understand all the implications and we figured it wasn't a problem for most users so we dropped it.
It was a short function called enableMultithreading() that had changed the call to CoInitializeEx(). Here it is: https://github.com/MaikuB/flutter_local_notifications/pull/2366/commits/12b67053d76bbd883852302f94c3ac9ae72e9390.
Here's the short version
// flutter_local_notifications_windows/src/ffi_api.cpp
+ void enableMultithreading() {
+ CoInitializeEx(nullptr, COINIT_MULTITHREADED);
+ }
// flutter_local_notifications_windows/src/ffi_api.h
+ FFI_PLUGIN_EXPORT void enableMultithreading();
// flutter_local_notifications_windows/lib/src/ffi/bindings.dart
+ void enableMultithreading() {
+ return _enableMultithreading();
+ }
+
+ late final _enableMultithreadingPtr =
+ _lookup<ffi.NativeFunction<ffi.Void Function()>>('enableMultithreading');
+ late final _enableMultithreading =
+ _enableMultithreadingPtr.asFunction<void Function()>();
// flutter_local_notifications_windows/lib/src/plugin/base.dart
+ void enableMultithreading();
// flutter_local_notifications_windows/lib/src/plugin/stub.dart
+ @override
+ void enableMultithreading() { }
// flutter_local_notifications_windows/lib/src/plugin/ffi.dart
+ @override
+ void enableMultithreading() => _bindings.enableMultithreading();
When you have that function, try running this file. It should crash without the enableMultithreading() (line 34) but be fine if you include it.
Once you've confirmed that, try calling that function in your own app. If it helps, we can probably put it back in the API again