BUG: Flowlauncher freezing after typing in one character

[mtdimaria]

Checks

• I have checked that this issue has not already been reported.

• I am using the latest version of Flow Launcher.

• I am using the prerelease version of Flow Launcher.

Problem Description

Every time I open Flow Launcher and begin to type, after the first character is entered the program freezes and I can't exit the program for about 15 seconds. I have restarted the program and the system and neither are fixing the issue.

To Reproduce

1. Open Flow Launcher
2. Type
3. Program freezes

Screenshots

Flow Launcher Version

2.1.3

Windows Build Number

26200.8524

Error Log

Flow.Launcher.2026-06-08.log

[sevenlittlegod]

I encountered the same problem as you. Whenever I typed the first letter, the entire flowlaucher program completely froze. I tried deleting the corrupted registry and removing the PATHs left by the uninstalled applications, but none of these methods worked. Finally, by enabling the "delay search" function of FlowLauncher and setting the delay to 100ms, this problem no longer occurred. You can give it a try.

[sevenlittlegod]

Update: I found the root cause in my case

The 100 ms search delay mentioned in my previous comment was only a workaround. I later captured a full process dump while Flow Launcher 2.1.3 was actually frozen.

In my dump, the WPF UI thread was blocked while handling a WM_GETOBJECT request:

WaitHandle.WaitMultipleIgnoringSyncContext
MS.Internal.Automation.UiaCoreProviderApi.RawUiaHostProviderFromHwnd
ElementProxy.get_HostRawElementProvider
RawUiaReturnRawElementProvider
System.Windows.Interop.HwndTarget.CriticalHandleWMGetobject
WPF Dispatcher
Flow.Launcher.App.Main

CPU usage was very low and there was no managed deadlock. In my case, the direct cause was synchronous UI Automation provider creation blocking the main UI thread, rather than Everything, the Program plugin, .lnk parsing, the registry, Python, or Node.js.

I built a patched version of v2.1.3 that intercepts WM_GETOBJECT only in the main search window's existing HwndSource hook:

private const int WmGetObject = 0x003D;

private IntPtr WndProc(
    IntPtr hwnd,
    int msg,
    IntPtr wParam,
    IntPtr lParam,
    ref bool handled)
{
    switch (msg)
    {
        case WmGetObject:
            handled = true;
            break;

        // Existing message handlers...
    }

    return IntPtr.Zero;
}

After installing this build, I have used Flow Launcher for a full day without a single freeze. The complete test suite also passed: 241/241 tests.

This workaround disables UI Automation/MSAA access to the main search window, so screen readers and UI automation tools will not be able to inspect that window. It may also affect candidate-window positioning in some third-party input methods. Settings and other windows are not affected.

I cannot confirm that every freeze reported here has the same cause, so it would be useful to capture another dump during the freeze and check whether the UI thread has the same CriticalHandleWMGetobject / RawUiaHostProviderFromHwnd stack.

One additional clue: WeType/WeChat input-method components were loaded in my Flow Launcher process, but I cannot prove that they were the sender of the UI Automation request.

[jjw24]

Hi there, please help test if this build addresses the issue:
https://ci.appveyor.com/api/buildjobs/5cy2rdj1qfv45tm9/artifacts/Output%2FPackages%2FFlow-Launcher-Portable.zip
This is a portable version download; you can copy your user data into this and daily drive it to confirm fix.