Windows fatal exception 0x8001010D (RPC_E_CANTCALLOUT_ININPUTSYNCCALL) during startup, intermittent and sometimes fatal to the bar

[Ferocious5885]

Environment

• YASB v2.0.5
• Python 3.14.6 (bundled)
• Windows 11

Summary

Twice in one session I hit Windows fatal exception: code 0x8001010d (RPC_E_CANTCALLOUT_ININPUTSYNCCALL, "an outgoing call cannot be made since the application is dispatching an input-synchronous call"). This is a COM reentrancy error: a COM-touching Win32 call is being made from a thread while Windows considers it mid-dispatch of a synchronous input call, most likely colliding with the global hotkey hook (HotkeyListener) or notification listener that's also active at that point.

It hit two different call sites on two different occasions:

1. Main thread, during app-bar creation (killed the bar, required restart):

Current thread (most recent call first):
  File "src\core\utils\win32\app_bar.py", line 147 in register_new
  File "src\core\utils\win32\app_bar.py", line 107 in create_appbar
  File "src\core\bar.py", line 173 in update_app_bar
  File "src\core\bar.py", line 128 in __init__
  File "src\core\bar_manager.py", line 257 in create_bar
  File "src\core\bar_manager.py", line 162 in initialize_bars
  File "main.py", line 144 in main_async

2. UpdateChecker background thread, during SSL context creation at boot (non-fatal to the bar, but the update check silently failed):

Thread [UpdateChecker] (most recent call first):
  File "C:\...\Lib\ssl.py", line 438 in __new__
  File "C:\...\Lib\ssl.py", line 698 in create_default_context
  File "src\core\utils\update_service.py", line 207 in _fetch_release_data
  File "src\core\utils\update_service.py", line 256 in check_for_updates
  File "src\core\utils\update_service.py", line 403 in _check_for_update

Both occurred right around bar startup/restart, when several Win32/COM-touching services (HotkeyListener, WindowsNotificationEventListener, TaskbarWindowManager, appbar registration, and the background update checker) are all initializing concurrently.

Impact: Case 1 killed the bar and required a full restart. Case 2 didn't crash the process but the update check silently failed.

Ask: Is there known reentrancy protection around the COM/Win32 calls made from these background threads at startup? Serializing appbar registration and the update check away from the hotkey-hook window's message dispatch (or catching/retrying on this specific HRESULT) would likely fix it.

[yasb-support]

Hey, thanks for the detailed report — I dug through the current code to check your question, and I can confirm: no, there's no reentrancy protection (or retry) around these calls today. Here's what I found:

1. AppBar registration — zero error handling. In src/core/utils/win32/app_bar.py, register_new() calls SHAppBarMessage(ABM_NEW, ...) with no HRESULT check, no retry, and no guarding at all. It's invoked synchronously from Bar.__init__() → update_app_bar() → create_appbar() on the main thread during BarManager.initialize_bars(). That's exactly why your case 1 was fatal to the bar: there's nothing between SHAppBarMessage failing and the exception unwinding __init__ and killing the whole initialization.

2. Update checker — generic catch only, no HRESULT retry. The background thread in src/core/utils/update_service.py (_check_for_update) does wrap everything in try/except Exception and logs "Background update check failed: ...", so a normal Python-level exception would be swallowed. But 0x8001010D is raised as a Windows fatal exception, which isn't reliably catchable there, and there's definitely no retry on this specific error code.

3. Startup is fully concurrent. The flow is: bars are created (appbar registration happens here) → _start_hotkey_listener() starts the HotkeyListener QThread with its GetMessageW loop → run_listeners_in_threads() starts the widget event listeners (which do CoInitialize + SetWinEventHook) → and only then is start_update_checker() fired off. Nothing serializes these against the hotkey-hook message dispatch, so your hypothesis about the collision window matches the code.

So yes — both of your suggested mitigations (catching/retrying RPC_E_CANTCALLOUT_ININPUTSYNCCALL around the SHAppBarMessage calls and SSL context creation, or serializing the Win32/COM work away from the hotkey/event-listener message loops) are valid and currently absent. I've flagged this for the maintainers to investigate — hopefully they can add some protection here.

One small tip while you wait: since you're on v2.0.5, if you don't use hotkeys you can leave keybindings unset — per the Keybindings docs the HotkeyListener isn't even started then, which removes one of the concurrent COM-touching threads from the startup window and may make the crash much less likely to trigger.

YASB Support Bot

[amnweb]

The log is real but the conclusions in it aren't.

"Windows fatal exception" is faulthandler logging a first-chance exception. It prints the traceback and execution continues - it doesn't mean anything crashed.

The UpdateChecker block isn't a second crash. faulthandler dumps every thread when it fires, and the one that actually faulted is labelled "Current thread". Yours says "Thread [UpdateChecker]", so that's a background thread doing normal work inside ssl.create_default_context. Nothing there touches COM. It's not even from the same dump - the update checker doesn't start until after initialize_bars() has returned.

HotkeyListener isn't a hook either. It's RegisterHotKey on its own thread and it doesn't start until all bars are created, so it can't be involved in that traceback.

Can you attach the full yasb.log? What matters is what comes after the dump:

• an "Exception during application startup" entry means the bar died there and I can work from the traceback
• the log carrying on normally means the exception was harmless
• the log just stopping, with no shutdown messages, means a silent crash - and the log can't tell us anything more, because the process died in native code before Python could write anything

That last case is why the next build adds yasbc enable-crash-dumps.

[Ferocious5885]

Attached the full yasb.log. It's continuous from 2026-08-01 21:24 through today with no rotation, so it covers the original report plus everything since.

Went through it against your three cases:

• Checked the 08-02 08:10:38 occurrence (closest to my original report): log continues completely normally afterward, weather-fetch entries keep firing every ~10 min for 20+ min with no gap. That's your "harmless" case.
• There's a fresh occurrence tonight (08-04 20:25:25), about 17s after that session started. The log has no lines after the dump, which looks like your "silent stop" case at first glance, but the yasb process is still alive right now, responding, with a valid MainWindowHandle ("YasbBar"). So the bar is fine; the log just hasn't logged anything else since (nothing else was due to fire yet).
• About 30 total 0x8001010d occurrences since 08-01. I didn't find a single instance of "Exception during application startup" in the whole file, so nothing here actually demonstrates the bar-killing case from my report title. Every occurrence I checked recovered cleanly.

So it looks like this fault is consistently harmless in my environment, for whatever that's worth. Happy to turn on crash dumps once that build is out if you still want a case-3 sample.

yasb.log

[amnweb]

The one that settles it for me is the very first dump, 08-01 21:24:40. That's inside the setup wizard on your first run - no bar, no appbar, no listeners, no update checker yet. Nothing there to collide with. And the config file gets written 2.5 minutes later, so the process was clearly fine.

The frame it points at is just wizard.exec(), which is the dialog's message loop. Same as run_forever in the other 21. It's the main thread pumping messages, not a call site. faulthandler prints whatever Python frame it can find when the fault is below it in COM.

Small thing on the 08-04 one - there is a line after that dump, the weather fetch at 20:35:09, it's just the last one in the file so far.

One thing I'd like to ask you about: four sessions end with no shutdown line at all - 08-01 22:02, 22:05, 22:07 and 08-03 16:40. Each has a new YASB start right after, so the process was gone. Quitting from the tray, the menu, yasbc stop or the updater all log a line first, and none of those did. Three of them are inside six minutes on install night, so my guess is you were killing it while setting things up. Does that sound right?

If yes, there's nothing here. If not, those four are the only real candidates and I'd want a crash dump from one.

[amnweb]

@Ferocious5885 download the latest release and enable dump. Run yasbc enable-crash-dumps. The dump files should appear in your yasb config folder.

[Ferocious5885]

On the four no-shutdown sessions: I checked my own command history from that install night rather than relying on memory.

Three of them (08-01 22:05, 22:07, 22:08, all within about three minutes) are fully explained: I was rebinding a hotkey (testing Win+Space for quick_launch) and had to fully restart yasb to pick up the new registration, so I ran taskkill /IM yasb.exe /F followed by relaunch each time. All three gaps in the log line up with those kills to the second. Nothing to chase there.

The fourth (08-03 16:40) isn't actually a silent-crash case at all, I think this one's a false alarm. The log shows a complete, graceful sequence right at that timestamp: "Screens updated. Re-initialising all bars." -> "Reloading Application because of screen update." -> HotkeyListener/WindowsNotificationEventListener/TaskbarWindowManager all stopping cleanly -> new startup line. Some monitor/display change on my end triggered a legitimate self-reload, not a crash. Same pattern repeats at 16:34 that day too.

So none of the four are real candidates, sorry that doesn't get you a repro.

Update on the update: installed v2.0.6 and ran yasbc enable-crash-dumps. Found a real, reproducible crash along the way, different from this issue's fault but maybe related in spirit. If you run the MSI installer while yasb.exe is still running, msiexec uses RestartManager to try to gracefully close it first, and that shutdown path throws an unhandled exception:

2026-08-06 20:06:10,010 [INFO] [MainThread] [root/bar_manager.py:111]: Stopping HotkeyListener...
2026-08-06 20:06:10,011 [INFO] [MainThread] [root/bar_manager.py:119]: Stopping WindowsNotificationEventListener...
2026-08-06 20:06:10,012 [INFO] [MainThread] [taskbar_window_manager/window_manager.py:205]: TaskbarWindowManager stopped
2026-08-06 20:06:10,124 [ERROR] [MainThread] [qasync._QEventLoop/__init__.py:770]: Exception in callback Task.task_wakeup()
handle: <Handle Task.task_wakeup()>
Traceback (most recent call last):
  File "C:\hostedtoolcache\windows\Python\3.14.6\x64\Lib\asyncio\events.py", line 94, in _run
RuntimeError: loop <QIOCPEventLoop running=False closed=False debug=False> is not the running loop
2026-08-06 20:06:10,125 [ERROR] [MainThread] [root/main.py:205]: Exception during application startup
Traceback (most recent call last):
  File "main.py", line 203, in <module>
  File "main.py", line 100, in main
  File "D:\a\yasb\yasb\venv\Lib\site-packages\qasync\__init__.py", line 435, in run_until_complete
RuntimeError: Event loop stopped before Future completed.

That's a genuine "Exception during application startup" entry (well, really shutdown, but that's the label yasb logs it under), fully reproducible: just run the installer with yasb still open. Different exception than 0x8001010D and a different trigger, but might be worth a look since it's the same family of "teardown races with the event loop" issue. Stopping yasb with yasbc stop before installing avoids it.

After getting v2.0.6 installed cleanly and dumps enabled, I restarted the bar and it came up fine (MainWindowHandle valid, responding). The 0x8001010d fault actually fired again on this very restart, and as expected, no dump got written since nothing crashed, consistent with the "harmless" read on this fault. Will report back if a real dump ever lands in the folder.

[amnweb]

I can't reproduce this. If you run the MSI installer while YASB is running, the installer will ask you to close the app that's open, and then give you options to retry.

Or you can ignore them, but in that case it will probably let you know to restart the PC after that. That's how MSI installer works. I can't reproduce anything like what you have in the logs on my end, so show me the full config file and let me know which machine you ran all this on. Did you build from source, or are you using a downloaded installer?