[Windows] Panic in EventLoopThreadExecutor::execute_in_thread (Re-entrancy / Destroyed state)

[kanatapple]

Describe the bug
We are experiencing panics in our production environment (Tauri application) originating from tao::platform_impl::platform::event_loop::EventLoopThreadExecutor::execute_in_thread on the Windows backend.

Based on the panic messages, it appears to be related to internal state management within the Windows event loop runner, specifically involving re-entrancy checks or accessing the event loop state after it has been destroyed.

Steps To Reproduce
Steps to reproduce the behavior. It must use tao directly and not tauri.

1. This issue is observed in a production Tauri application (v2.8.5).
2. Due to the nature of the error (likely a race condition or specific timing during window destruction/heavy load), we have not been able to isolate a minimal reproduction using tao directly yet.
3. However, the stack traces collected point directly to tao's internal logic on Windows, suggesting unsafe state transitions during the event loop processing.

Expected behavior
The event loop should handle state transitions gracefully. Even if an event handler is re-entrant or the state is destroyed, it should ideally not cause a hard panic that crashes the application.

Screenshots
N/A (See stack trace details in "Additional context")

Platform and Versions (please complete the following information):
OS: Windows 10.0.26100 x86_64
Rustc: 1.89.0
Tao version: 0.34.3

Additional context
We have identified three distinct panic messages/locations in the stack traces that seem to stem from the same root cause:

1. Re-entrancy / No Handler:
   "either event handler is re-entrant (likely), or no event handler is registered (very unlikely)"
   Location: src/platform_impl/windows/event_loop/runner.rs:244

2. Assertion Failure:
   "assertion failed: flush_paint_messages(None, &subclass_input.event_loop_runner)"
   Location: src/platform_impl/windows/event_loop.rs:2344

3. Invalid State Transition:
   "cannot move state from Destroyed"
   Location: src/platform_impl/windows/event_loop/runner.rs:368

It appears that the event loop is attempting to access state or flush messages after the runner state has arguably become invalid or destroyed.

---

Full tauri info output:

[✔] Environment
    - OS: Windows 10.0.26100 x86_64 (X64)
    ✔ WebView2: 144.0.3719.93
    ✔ MSVC:
        - Visual Studio Professional 2017
        - Visual Studio Professional 2019
    ✔ rustc: 1.89.0 (29483883e 2025-08-04)
    ✔ cargo: 1.89.0 (c24e10642 2025-06-23)
    ✔ rustup: 1.28.2 (e4f3ad6f8 2025-04-28)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 22.14.0
    - yarn: 1.22.22
    - npm: 10.9.2

[-] Packages
    - tauri 🦀: 2.8.5
    - tauri-build 🦀: 2.4.1
    - wry 🦀: 0.53.3
    - tao 🦀: 0.34.3
    - @tauri-apps/api : 2.2.0
    - @tauri-apps/cli : 2.2.2

[-] Plugins
    - tauri-plugin-updater 🦀: 2.9.0
    - @tauri-apps/plugin-updater : not installed!
    - tauri-plugin-fs 🦀: 2.4.2
    - @tauri-apps/plugin-fs : not installed!
    - tauri-plugin-log 🦀: 2.7.0
    - @tauri-apps/plugin-log : not installed!
    - tauri-plugin-http 🦀: 2.5.2
    - @tauri-apps/plugin-http : not installed!
    - tauri-plugin-dialog 🦀: 2.4.0
    - @tauri-apps/plugin-dialog : 2.0.0

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
    - framework: Vue.js
    - bundler: Vite

[thomaseizinger]

We are seeing similar crash reports. Here is one of the stacktraces:

panic: cannot move state from Destroyed
  Firezone            0x7ff65312a640 backtrace::capture::Backtrace::new
  Firezone            0x7ff65312a53f backtrace::capture::Backtrace::new
  Firezone            0x7ff653bf5f2f sentry_panic::PanicIntegration::event_from_panic_info
  Firezone            0x7ff653bf5a0f std::sync::once::Once::call_once_force::{{closure}}
  Firezone            0x7ff653bf8b23 sentry_panic::PanicIntegration::setup
  Firezone            0x7ff653c47ee0 std::panic::PanicHookInfo::new (boxed.rs:2220)
  Firezone            0x7ff653c47ee0 std::panicking::panic_with_hook (panicking.rs:833)
  Firezone            0x7ff653c47c59 std::panicking::panic_handler::closure$0 (panicking.rs:691)
  Firezone            0x7ff653c41f2e std::sys::backtrace::__rust_end_short_backtrace<T> (backtrace.rs:176)
  Firezone            0x7ff653c2c23d std::panicking::panic_handler (panicking.rs:689)
  Firezone            0x7ff653e78f6c core::panicking::panic_fmt (panicking.rs:80)
  Firezone            0x7ff6533ce8f8 tao::platform_impl::platform::event_loop::runner::EventLoopRunner<T>::move_state_to<T> (runner.rs:368)
  Firezone            0x7ff6533c2ed0 tao::platform_impl::platform::event_loop::runner::EventLoopRunner<T>::main_events_cleared (runner.rs:230)
  Firezone            0x7ff6533c2ed0 tao::platform_impl::platform::event_loop::flush_paint_messages<T> (event_loop.rs:824)
  Firezone            0x7ff6533cbab1 tao::platform_impl::platform::event_loop::thread_event_target_callback::closure$0 (event_loop.rs:2372)
  Firezone            0x7ff6533cbab1 core::ops::function::FnOnce::call_once (function.rs:250)
  Firezone            0x7ff6533cbab1 core::panic::unwind_safe::impl$25::call_once (unwind_safe.rs:274)
  Firezone            0x7ff6533cbab1 std::panicking::catch_unwind::do_call (panicking.rs:581)
  Firezone            0x7ff6533cbab1 std::panicking::catch_unwind (panicking.rs:544)
  Firezone            0x7ff6533cbab1 std::panic::catch_unwind (panic.rs:359)
  Firezone            0x7ff6533cbab1 tao::platform_impl::platform::event_loop::runner::EventLoopRunner<T>::catch_unwind (runner.rs:156)
  Firezone            0x7ff6533cbab1 tao::platform_impl::platform::event_loop::thread_event_target_callback<T> (event_loop.rs:2475)
  comctl32            0x7ffa8963cec7 CallNextSubclassProc
  comctl32            0x7ffa8963cc9e MasterSubclassProc
  user32              0x7ffaa8177845 UserCallWinProcCheckWow
  user32              0x7ffaa81770cb DispatchClientMessage
  user32              0x7ffaa81a7e92 _fnDWORD
  ntdll               0x7ffaaa305be3 KiUserCallbackDispatch
  win32u              0x7ffaa7f118c3 ZwUserDispatchMessage
  user32              0x7ffaa8175507 DispatchMessageWorker
  Firezone            0x7ff65327e418 windows::Win32::UI::WindowsAndMessaging::DispatchMessageW (mod.rs:577)
  Firezone            0x7ff65327e418 tao::platform_impl::platform::event_loop::EventLoop<T>::run_return (event_loop.rs:268)
  Firezone            0x7ff65327e418 tao::platform::run_return::impl$0::run_return (run_return.rs:48)
  Firezone            0x7ff65327e418 tauri_runtime_wry::impl$45::run_return (lib.rs:3096)
  Firezone            0x7ff65327e418 tauri::app::App<T>::run_return (app.rs:1288)
  Firezone            0x7ff65327e418 firezone_gui_client::gui::run (gui.rs:430)
  Firezone            0x7ff6537df005 firezone_gui_client::try_main (firezone-gui-client.rs:162)
  Firezone            0x7ff6537d2a0e firezone_gui_client::main (firezone-gui-client.rs:33)
  Firezone            0x7ff6537e7325 core::ops::function::FnOnce::call_once (function.rs:250)
  Firezone            0x7ff6537e7325 std::sys::backtrace::__rust_begin_short_backtrace<T> (backtrace.rs:160)
  Firezone            0x7ff653c30c1e core::ops::function::impls::impl$2::call_once (function.rs:287)
  Firezone            0x7ff653c30c1e std::panicking::catch_unwind::do_call (panicking.rs:581)
  Firezone            0x7ff653c30c1e std::panicking::catch_unwind (panicking.rs:544)
  Firezone            0x7ff653c30c1e std::panic::catch_unwind (panic.rs:359)
  Firezone            0x7ff653c30c1e std::rt::lang_start_internal::closure$0 (rt.rs:175)
  Firezone            0x7ff653c30c1e std::panicking::catch_unwind::do_call (panicking.rs:581)
  Firezone            0x7ff653c30c1e std::panicking::catch_unwind (panicking.rs:544)
  Firezone            0x7ff653c30c1e std::panic::catch_unwind (panic.rs:359)
  Firezone            0x7ff653c30c1e std::rt::lang_start_internal (rt.rs:171)
  Firezone            0x7ff653819d6b main
  Firezone            0x7ff653e7421f invoke_main (exe_common.inl:78)
  Firezone            0x7ff653e7421f __scrt_common_main_seh (exe_common.inl:288)
  KERNEL32.DLL        0x7ffaa85fe8d6 BaseThreadInitThunk
  ntdll               0x7ffaaa22c53b RtlUserThreadStart

For what its worth, this seems to be more likely within the first few minutes of the application starting although be do also have crash reports from instances where the application has been running for days.

[Legend-Master]

I think 2 will be solved if we could adopt rust-windowing/winit#2767. That PR is quite big though so I'm not sure if we could if ever find time to bring it in...