LGUG2Z/komorebi · critical

could not start winput message loop

Error message

could not start winput message loop

What it means

listen_for_movements starts the winput Windows message loop (used for focus-follows-mouse) in a spawned thread and panics if message_loop::start() fails. The winput library requires a runnable Win32 message pump in the calling thread; failure indicates a Windows API error creating the message window.

Source

Thrown at komorebi/src/process_movement.rs:17

use std::sync::Arc;

use parking_lot::Mutex;
use winput::Action;
use winput::message_loop;
use winput::message_loop::Event;

use crate::core::FocusFollowsMouseImplementation;

use crate::window_manager::WindowManager;

#[tracing::instrument]
pub fn listen_for_movements(wm: Arc<Mutex<WindowManager>>) {
    std::thread::spawn(move || {
        let mut ignore_movement = false;

        let receiver = message_loop::start().expect("could not start winput message loop");

        loop {
            let focus_follows_mouse = wm.lock().focus_follows_mouse;
            if matches!(
                focus_follows_mouse,
                Some(FocusFollowsMouseImplementation::Komorebi)
            ) {
                match receiver.next_event() {
                    // Don't want to send any raise events while we are dragging or resizing
                    Event::MouseButton { action, .. } => match action {
                        Action::Press => ignore_movement = true,
                        Action::Release => ignore_movement = false,
                    },
                    Event::MouseMoveRelative { .. } if !ignore_movement => {
                        match wm.lock().raise_window_at_cursor_pos() {
                            Ok(()) => {}
                            Err(error) => tracing::error!("{}", error),
                        }

View on GitHub (pinned to e0709f02bf)

Solutions

1. Run komorebi from an interactive user session (normal login), not a service or SSH session
2. Ensure komorebi autostarts via the user's startup folder/registry Run key
3. Reboot/re-login to fix a broken Win32 session
4. Verify komorebi version matches your Windows build; upgrade komorebi if winput failures persist

Example fix

// before
let receiver = message_loop::start().expect("could not start winput message loop");
// after
let receiver = match message_loop::start() {
    Ok(r) => r,
    Err(e) => { tracing::error!("could not start winput message loop: {e}"); return; }
};

// before launching komorebi, confirm an interactive desktop session exists (PowerShell)
if ([System.Windows.Forms.SystemInformation]::Interactive) { start komorebi } else { throw "no interactive session" }

When it happens

Trigger: message_loop::start() returning Err when the Win32 message queue/window cannot be created — e.g. running in a non-interactive session (service, SSH, session 0).

Common situations: Launching komorebi from a scheduled task or service without an interactive desktop; remote sessions without UI access; corrupted Windows user session.

Related errors

• could not send message on winevent_listener::event_tx
• could not subscribe to komorebi notifications
• no home directory found
• creating RENDER_FACTORY failed
• there is no home directory

AI-assisted analysis of LGUG2Z/komorebi@e0709f02bf (2026-09-06). Data as JSON: /api/errors/8b020420f0c32af8. Report an issue: GitHub.