Windows Flutter app crashing

hillel · November 13, 2025, 9:48am

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"

hillel · November 13, 2025, 9:52am

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.

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.

Why Flutter 3.19.6 works and 3.27+ / 3.35+ crash

Here’s the important bit:

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:

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.

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.

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.

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.

Recommended Workaround (Short-term)

Stay on Flutter 3.19.6

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

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.

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()

Summary Conclusion

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

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

alichaabane98 · January 8, 2026, 8:42am

Hi everyone,
I wanted to share our experience because it looks very similar to what’s described here, and maybe it helps confirm patterns.

I have a Flutter Windows POS / sales application used daily in production.

Context

Flutter version: 3.35.1 (stable)
Windows only (no macOS / Linux issues)
App is stable on all our machines (dev PCs, test PCs, other client PCs)
Only ONE client PC shows intermittent crashes

Crash behavior

Not crashing on startup
Not reproducible on demand
App can run 2–5 hours without any issue
Then suddenly:
- app freezes or closes
- sometimes shows “Not responding”
- sometimes disappears silently
Nothing is reported to Sentry (native crash)

The user often continues working normally after reopening the app.

Additionally:

When a crash occurs, Windows sometimes generates a crash dump file that is 0 KB
The crash appears random and is difficult to correlate with any specific user action
After refactoring large parts of the app (calculations, listeners, dispose, lifecycle handling), the crashes were reduced, but still only happen on this specific client PC
The same build runs without issues on my PC and other developers’ PCs

What makes this suspicious

Same build, same installer, same data
Other PCs (even weaker hardware) do not crash
Crashes only happen on this specific PC
Windows Reliability Monitor and Event Viewer show:
- LiveKernelEvent
- WATCHDOG
- occasional GPU / Display related warnings
This points to kernel / GPU driver level, not Dart exceptions

Hardware / OS of the problematic PC

CPU: Intel Celeron J6412
GPU: Intel UHD Graphics
Driver version: 31.0.101.1999 (2022)
OS: Windows 11 IoT Enterprise LTSC 24H2
App often stays idle between operations (typical POS usage)

Things i tested

Heavy refactoring & performance optimizations
Checked listeners, dispose, lifecycle, isolates
Downgrade Flutter → not feasible due to Dart / dependency constraints
Disabled Impeller and GPU usage:

setx FLUTTER_ENGINE_SWITCHES "--enable-impeller=false --disable-gpu"
setx FLUTTER_A11Y "off"

→ significantly reduced crashes, but not 100%

This strongly suggests a GPU / driver / Windows interaction issue, not a Flutter framework bug in isolation.

Current hypothesis

Windows + Intel UHD driver + long-running Flutter app
GPU watchdog (TDR) triggering after long uptime
Flutter just happens to be the foreground app when it occurs

Next steps I’m taking

Updating Intel GPU driver to 31.0.101.2115
Disabling automatic driver updates from Windows Update
Monitoring Reliability Monitor after the update

If anyone else has seen Windows-only crashes after hours of use, especially on Intel UHD / low-power CPUs, I’d be very interested to hear:

GPU model & driver version
Windows build
Whether disabling Impeller / GPU helped

Thanks for sharing this thread — it already helped us narrow things down.

mihalycsaba · January 8, 2026, 12:30pm

hillel:

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

Did you try this? I think this is only needed for accessibility, so you can turn it off, probably unnecessary for a POS

alichaabane98 · January 8, 2026, 12:34pm

Yes already i ran these two insturctions and it reduced the crashes on that specific pc… but i donno if there s a radical solution or something help .

PS: for my pc win 11 pro + 32gb + i7 9th gen and ssd it works well even for my friend pc win 11 pro + 16gb + i7 10th gen
just for my client pc that i mentioned …

alichaabane98 · January 11, 2026, 1:08pm

Hi Guys,

We may have finally found the cause of this. On affected machines, disabling the HID-compliant touchscreen device in Windows Device Manager completely stopped the crashes.

We’re running this in production now to confirm, but after ~2 days of testing so far the crashes have not reappeared. We’ll report back once it’s fully confirmed.

mihalycsaba · January 13, 2026, 6:58am

I can’t find anything about this https://github.com/flutter/flutter/issues?q=is%3Aissue%20HID%20compliant%20touchscreen

Might be worth opening an issue.

alichaabane98 · January 13, 2026, 7:26am

I just said from my own experience that after doing that in production machine for my client bc it was last solution i didn t touch. my pc and a lot of other pc don t have touchscreen and works well app without random crash in my case its a POS App windows flutter and to trigger fastly the crash was to add some rows in datatable products and remove some of them and sometimes all and reinsert some products one by one (not only by barcode scanning but also by adding them through search description or code of product) so if TOUCHSCREEN HID ENABLED DIRECTLY APP CRASHED after that simple test… if disabled and restart pc no longer exists and as i said i tested now for 2 days i wait another day to confirm 100% reason . i did all other friends solutions but not helped.

Flutter: 3.38.5
Dart: 3.10.4

mihalycsaba · January 13, 2026, 8:43am

Do you have any logs?

filip · January 13, 2026, 10:07am

FWIW, I think this the kind of issue that should definitely be reported at flutter/flutter. I think it was Ian who once told me that the team would rather have incomplete knowledge about a serious bug than no knowledge at all. I share this view.

If you do report it, please share the link here. I’ll subscribe to that issue.

alichaabane98 · January 13, 2026, 10:10am

1drv.ms/u/c/903446f6791a8688/IQCBPQbQd_hCT5zA_99Kx_QIAaa_Sq9DjT1Cu2Q_uCO7wYY?e=psx6z7

a dump windows crash is here u can use windbg or anyother tool … i did all solutions as i said and finally the disabling of touchscreen (that my client rarely use it bc he use keyboard and mouse)

i hope one from team of flutter find a way… so now to continue working i force client to dont enable TOUCHSCREEN HID Pilot (i need later to find a way to manage touchscreen by myself influtter)

loic-sharma · January 17, 2026, 5:49pm

The stack trace in the original message looks like your Windows app is exiting, which causes the Flutter engine to shut down and destroy itself. However, some Windows event loop message is sent during shutdown which attempts to use the engine, which has been destroyed - this triggers the crash.

If we can figure out which event loop message triggers the crash, that’d be helpful. We likely need to update the logic for this event to gracefully handle the case where this message is sent during shutdown.

disabling the HID-compliant touchscreen device in Windows Device Manager completely stopped the crashes

This is good info. This might mean we’re somehow receiving touch events during shutdown. I wouldn’t be surprised if the Windows embedder assumes that scenario wouldn’t happen.

hillel · January 18, 2026, 7:02am

Thanks for your response! I haven’t been able to reproduce the crash myself but reports from many users are that it happens during a specific action in the app. I’d assume something is causing the app to crash, not that the app is exiting.

If you can provide any advice on further debugging I’m very happy to invest more time on this.

alichaabane98 · February 5, 2026, 1:42pm

Yes, exactly after trying and knocking all doors (scenarios) i ve got that its the issue in my case bc POS flutter windows app i insert in datatable some products exple 5 products inserted i remove later some of them and try insert again :
1- if HID touchscreen enabled (thats my case in client prod machine) : directly crash without noise
2- after i disable it now i have 20 days 0 crashs !

Please is there any solutions to bypass the issue bc now i forced my client to disable touchscreen on his pc

Rick · March 8, 2026, 10:15pm

github.com/flutter/flutter

Windows: Silent native crashes caused by HID touchscreen input (flutter_windows.dll)

opened 08:30AM - 06 Feb 26 UTC

alichaabane

waiting for customer response engine platform-windows team-windows

### Steps to reproduce 1. Use a **Windows PC with a HID-compliant touchscreen e…nabled** *(Device Manager → Human Interface Devices → HID-compliant touchscreen)* 2. Install and run a **Flutter Windows application** - Tested with **Flutter ≥ 3.35 (explicitly tested on 3.35.1 and 3.38.5 )** 3. Let the application run normally - The app may remain stable for minutes or hours 4. Perform rapid UI updates, for example: - Insert multiple rows into a `DataTable` - Remove some or all rows - Reinsert rows (via keyboard or search, not necessarily touch input) 5. Observe the application behavior. ### Important If the **HID-compliant touchscreen device is disabled**, the same steps **do not reproduce the crash**. ### Expected results - The Flutter Windows app should continue running normally. - No crash or freeze should occur regardless of whether a touchscreen is present. - Touch / pointer events should be safely ignored if the engine or view is in teardown. ### Actual results - The app freezes or closes silently. - No Dart exception is thrown. - The crash is not reported to Sentry or Flutter error handlers. - Windows may show “Not responding” or generate a 0 KB crash dump. - Disabling the HID-compliant touchscreen device completely stops the crashes (20+ days in production). ### Code sample ## Minimal Reproducible Sample At this time, I’m unfortunately **unable to provide a minimal reproducible sample**. This issue: - Only reproduces on **specific Windows machines** - Requires **HID-compliant touchscreen hardware** - Is triggered by **native input events**, not a specific Dart API - Does **not** reproduce reliably on developer machines without touchscreen support I’m actively working to isolate a minimal reproduction case and will update this repository / issue as soon as one becomes available. That said, the issue can be **reliably reproduced on affected machines by following the “Steps to Reproduce” section above**, on systems with a HID-compliant touchscreen enabled. <details open> <summary>Code sample</summary> ```dart // No minimal repro available yet. // The crash happens in native code (flutter_windows.dll) // and is hardware / input-device dependent. ``` ### Screenshots or Video <details open> <summary>Screenshots / Video demonstration</summary> No screenshots / video </details> ### Logs <details open> <summary>Logs</summary> No Dart or Flutter logs are produced. A Windows crash dump from an affected machine is available here: - **OneDrive link:** [1drv.ms/u/c/903446f6791a8688/IQCBPQbQd_hCT5zA_99Kx_QIAaa_Sq9DjT1Cu2Q_uCO7wYY?e=psx6z7](https://1drv.ms/u/c/903446f6791a8688/IQCBPQbQd_hCT5zA_99Kx_QIAaa_Sq9DjT1Cu2Q_uCO7wYY?e=psx6z7) ### Flutter Doctor output <details open> <summary>Doctor output</summary> Flutter 3.38.5 • channel stable Dart 3.10.4 Windows 11 > Note: Full `flutter doctor -v` output can be provided if required. </details>