Observed (Windows 11, izba 0.1.0 @02f4b02, 2026-09-12)
Relaunching the desktop app produced two live izba-app.exe processes 14 s apart: the first (12:14:12) never created its webview — 4 threads, main thread parked in a user-mode wait, a 16×16 untitled window, ~41 MB — and stayed resident; the second (12:14:26) came up normally. The user saw the first launch "not start" and launched again.
No tauri-plugin-single-instance is registered (app/src-tauri/src/lib.rs), so nothing focuses the existing window or refuses a duplicate, and nothing detects an instance stuck before webview creation.
Ask
- Register the single-instance plugin: a second launch focuses the running window instead of spawning a sibling.
- Find why the first instance can park before webview creation (WebView2 user-data-folder lock from the instance that had just been closed is the leading suspect) and either bound the wait or surface it.
Threads of the stuck instance: main Wait/UserRequest (1.17 s CPU), one more UserRequest, two EventPairLow. No app log exists to say where it parked — worth adding one.
Observed (Windows 11, izba 0.1.0 @02f4b02, 2026-09-12)
Relaunching the desktop app produced two live
izba-app.exeprocesses 14 s apart: the first (12:14:12) never created its webview — 4 threads, main thread parked in a user-mode wait, a 16×16 untitled window, ~41 MB — and stayed resident; the second (12:14:26) came up normally. The user saw the first launch "not start" and launched again.No
tauri-plugin-single-instanceis registered (app/src-tauri/src/lib.rs), so nothing focuses the existing window or refuses a duplicate, and nothing detects an instance stuck before webview creation.Ask
Threads of the stuck instance: main
Wait/UserRequest(1.17 s CPU), one moreUserRequest, twoEventPairLow. No app log exists to say where it parked — worth adding one.