Windows Flutter app crashing

Help General
1

We’ve been using Flutter 3.19.6 for a while now and decided to update to a more recent version 3.35.4.

On most platforms the app is running fine however on Windows we’re seeing many silent crashes which aren’t getting reported to Sentry.

In the Microsoft Store admin portal I can see the following two errors reported many times.

access_violation_c0000005_flutter_windows.dll!unknown
fatal_user_callback_exception_c000041d_flutter_windows.dll!unknown

We tried rollong back to a slightly older Flutter version 3.27.4, some users reported it helping but we’re still seeing many crash reports. The errors changed to.

access_violation_c0000005_flutter_windows.dll!flutter::flutterwindowsview::getengine
fatal_user_callback_exception_c000041d_flutter_windows.dll!flutter::flutterwindowsview::getengine

For now we’ve rolled back to 3.19.6. I don’t have code to reproduce the error so haven’t created an issue on the Flutter GitHub repo but thought I’d post here in case anyone else is seeing it as well or has any ideas.

"Frame"	"Image"	"Function"	"Offset"
"0"	"flutter_windows.dll"	"flutter::FlutterWindowsView::GetEngine"	"0x0000000000000000"
"1"	"flutter_windows.dll"	"flutter::FlutterWindowsViewController::engine"	"0x0000000000000000"
"2"	"flutter_windows.dll"	"FlutterDesktopViewControllerHandleTopLevelWindowProc"	"0x0000000000000000"
"3"	"invoiceninja.exe"	"-"	"0x0000000000000000"
"4"	"invoiceninja.exe"	"-"	"0x0000000000000000"
"5"	"invoiceninja.exe"	"-"	"0x0000000000000000"
"6"	"user32.dll"	"UserCallWinProcCheckWow"	"0x0000000000000000"
"7"	"user32.dll"	"DispatchClientMessage"	"0x0000000000000000"
"8"	"user32.dll"	"__fnDWORD"	"0x0000000000000000"
"9"	"ntdll.dll"	"KiUserCallbackDispatcherContinue"	"0x0000000000000000"
"10"	"win32u.dll"	"ZwUserDestroyWindow"	"0x0000000000000000"
"11"	"flutter_windows.dll"	"flutter::FlutterWindow::Destroy"	"0x0000000000000000"
"12"	"flutter_windows.dll"	"flutter::FlutterWindow::~FlutterWindow"	"0x0000000000000000"
"13"	"flutter_windows.dll"	"flutter::FlutterWindow::`vector deleting destructor'"	"0x0000000000000000"
"14"	"flutter_windows.dll"	"std::default_delete_flutter::WindowBindingHandler_::operator"	"0x0000000000000000"
"15"	"flutter_windows.dll"	"std::unique_ptr_flutter::WindowBindingHandler,std::default_delete_flutter::WindowBindingHandler_ _::~unique_ptr"	"0x0000000000000000"
"16"	"flutter_windows.dll"	"flutter::FlutterWindowsView::~FlutterWindowsView"	"0x0000000000000000"
"17"	"flutter_windows.dll"	"flutter::FlutterWindowsView::~FlutterWindowsView"	"0x0000000000000000"
"18"	"flutter_windows.dll"	"std::default_delete_flutter::FlutterWindowsView_::operator"	"0x0000000000000000"
"19"	"flutter_windows.dll"	"std::unique_ptr_flutter::FlutterWindowsView,std::default_delete_flutter::FlutterWindowsView_ _::reset"	"0x0000000000000000"
"20"	"flutter_windows.dll"	"flutter::FlutterWindowsViewController::Destroy"	"0x0000000000000000"
"21"	"flutter_windows.dll"	"FlutterDesktopViewControllerDestroy"	"0x0000000000000000"
"22"	"invoiceninja.exe"	"-"	"0x0000000000000000"
"23"	"invoiceninja.exe"	"-"	"0x0000000000000000"
"24"	"invoiceninja.exe"	"-"	"0x0000000000000000"
"25"	"invoiceninja.exe"	"-"	"0x0000000000000000"
"26"	"kernel32.dll"	"BaseThreadInitThunk"	"0x0000000000000000"
"27"	"ntdll.dll"	"RtlUserThreadStart"	"0x0000000000000000"
2

Sharing what ChatGPT suggest as I find the context pretty interesting.

Here’s a distilled analysis based on everything we know about Flutter Windows, your crash traces, the versions you tested, and the patterns in the call stack.

This is very likely a Flutter engine regression (or subtle behavioral change) on Windows between 3.19.x and later versions — specifically around window destruction, semantics/accessibility updates, and GetEngine() returning null.

Below is a breakdown + actionable steps that really help narrow this down and match what others are seeing.

:white_check_mark: What the Crash Trace Tells Us

Your most revealing line is:

access_violation_c0000005_flutter_windows.dll!flutter::FlutterWindowsView::GetEngine

This happens only when GetEngine() is called on a destroyed/deleting engine.
And the follow-up:

fatal_user_callback_exception_c000041d

Confirms it’s happening inside a Win32 window callback, most commonly during:

  • WM_DESTROY
  • WM_SIZE after teardown
  • Accessibility/semantics updates after view destruction

Your later trace shows destruction clearly happening:

flutter::FlutterWindow::Destroy
flutter::FlutterWindowsView::~FlutterWindowsView
FlutterDesktopViewControllerDestroy

This is very consistent with:

A callback (e.g., accessibility, mouse, top-level window proc) firing after the engine/view was already destroyed, triggering GetEngine() on a null pointer.

This is exactly what would produce silent crashes that don’t reach Sentry.

:white_check_mark: Why Flutter 3.19.6 works and 3.27+ / 3.35+ crash

Here’s the important bit:

:check_mark: Flutter 3.22 – 3.27 introduced significant Windows embedding updates:

  • New semantics pipeline (AX 2.0)
  • New view controller lifecycle
  • New engine wiring
  • Win32 message ordering changes
  • Threading model changes for callbacks

These changes have caused real regressions, especially crashes during window teardown.

There are at least three known issues that match your symptom precisely:

:firecracker: Known Flutter Windows Crash Bugs That Match Your Trace

1. AX / Semantics callback after engine destruction

  • Reported many times since 3.22
  • Produces crashes in AccessibilityBridge and GetEngine()
  • Silent crashes
  • Triggered by window minimize/restore or screen reader polling

Your earlier logs also show semantics callbacks in crash logs, so this fits perfectly.

2. Window proc dispatch triggering after teardown

This part of your trace:

FlutterDesktopViewControllerHandleTopLevelWindowProc
UserCallWinProcCheckWow
DispatchClientMessage

Matches known issue: engine destroyed → Win32 still dispatches messages → engine pointer gone → crash.

3. Race condition during engine destruction

PRs landed around 3.27–3.35 modifying:

  • Unique pointer cleanup
  • Order of window destruction vs. engine destruction
  • Timing of message pump shutdown

Your trace shows destruction of:

unique_ptr<FlutterWindowsView>
unique_ptr<WindowBindingHandler>

at the same time messages are still coming in.

:magnifying_glass_tilted_left: Why It Doesn’t Hit Sentry

These crashes happen:

  • Outside Dart
  • Inside native C++
  • Before Flutter error handlers initialize
  • Often on a different thread

Therefore Sentry never sees them.

This is expected.

:police_car_light: Is Anyone Else Seeing This?

Yes.

Many Windows app developers reported:

  • Silent crashes

  • No Sentry reports

  • Crashes only in AOT/release

  • Crash signatures pointing to:

    • FlutterWindowsEngine::Run
    • AccessibilityBridge
    • GetEngine()
    • WindowProc after destroy

Most reports involve Flutter 3.22–3.27–3.35.

Rolling back to 3.19.x is a common fix.

:test_tube: Ways to Narrow It Down (Useful for Flutter GitHub)

If you ever want to file a report, the most valuable tests are these:

1. Disable Flutter sematics on Windows

Semantics is the #1 crash trigger.

Add:

void main() {
  FlutterWindows.instance?.setSemanticsEnabled(false);
  runApp(MyApp());
}

Or set the environment variable:

FLUTTER_A11Y=off

If crashes disappear → this confirms it 100%.

2. Test with Impeller disabled / enabled

Windows Impeller is now default in new versions.

Try forcing:

flutter run -d windows --enable-impeller
flutter run -d windows --no-enable-impeller

Some apps report stability differences.

3. Check for plugin cleanup ordering issues

Plugins that register Win32 callbacks (even indirectly) can trigger this.

Your app uses many plugins:

  • Sentry
  • WindowManager
  • Desktop Drop
  • FDE plugins
    …any of them can accidentally fire after WM_DESTROY.

Try temporarily disabling directory watchers, system tray plugins, etc.

4. Test with --no-tree-shake-icons

Icon tree-shaking + Windows engine has produced regressions in the past.
Rare, but easy to test.

:hammer_and_wrench: Recommended Workaround (Short-term)

:check_mark: Stay on Flutter 3.19.6

This is by far the most stable Windows version until the embedding lifecycle changes stabilize.

:check_mark: Or use 3.22.3, which is better than 3.27/3.35

Several devs report that 3.22.x is stable but later versions regress.

:check_mark: Report to Flutter with:

  • OS version (Win 10/11)
  • Whether Accessibility is enabled
  • Whether the app was minimized or restored
  • Whether window manager plugins are used
  • Crash signature showing GetEngine()

:brain: Summary Conclusion

:backhand_index_pointing_right: This is a known Windows engine regression introduced after Flutter 3.19.
:backhand_index_pointing_right: The crash is caused by callbacks firing after the engine/view is destroyed, especially semantics.
:backhand_index_pointing_right: 3.27–3.35 make it worse due to internal changes.
:backhand_index_pointing_right: No Sentry reporting because it’s native and silent.
:backhand_index_pointing_right: Rolling back to 3.19 is the correct short-term fix.

You are not alone — several Windows devs are hitting this right now.