Everything freezes for while when opening an executable file

[vsub]

Is this a windows thing or there is something I can do on the Everything side
Every time I try to open a program that was not run yet since restart or not started for a while and maybe windows removes it from memory,everything freezes for 1-2 seconds while maybe windows is scanning the excutable(just a guess)

You cannot move\minimize\interact the everything window for a short time

[void]

What Anti-Virus are you using?

I wonder if this is a stall in Everything launching or an update after the launch..
Could you please capture a debug log:

• In Everything, from the Tools menu, under the Debug submenu, click Start Debug Logging.
• Launch an new executable from Everything.
  --Make sure Everything hangs for a couple seconds.
• From the Tools menu, under the Debug submenu, click Stop Debug Logging.
  --This will open your %TEMP%\Everything Debug Log.txt
• Could you please send this file in a bug report.

Some ideas..
Please try disabling shell_execute_invoke_id_list:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  execute
• Select: shell_execute_invoke_id_list
• Set the value to: false
• Click OK.

This will prevent the system from building a context menu and invoking the default item which might be causing the trouble.

shell_execute_invoke_id_list



Please try disabling shell_execute_id_list:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  execute
• Select: shell_execute_id_list
• Set the value to: false
• Click OK.

Disabling shell_execute_id_list will make Everything fallback to a simple system call to execute files by filename.

shell_execute_id_list

[vsub]

I am using Windows Defender
I tried disabling both options and restart Everything
I am running the file by double clicking

Do you see anything suspicious

Code: Select all

2026-07-21 09:00:41.660: exec: first expr "%1"
2026-07-21 09:00:41.661: exec: command "%1"
2026-07-21 09:00:41.661: exec: fullfilename D:\Data\mpv\mpv.exe
2026-07-21 09:00:41.661: exec: "D:\Data\mpv\mpv.exe"
2026-07-21 09:00:41.661: exec: shellexecute file:D:\Data\mpv\mpv.exe param:
2026-07-21 09:00:41.661: shellexecute pidl 0000000000000000
2026-07-21 09:00:41.662: Directory 'D:\Data\mpv'
2026-07-21 09:00:41.662: File 'D:\Data\mpv\mpv.exe'
2026-07-21 09:00:41.662: Mask 00000100
2026-07-21 09:00:41.662: Enter ShellExecute
2026-07-21 09:00:41.663: UI 0000004e 0000000000000000 0000000000efc958
2026-07-21 09:00:41.663: NOTIFY 0 -9
2026-07-21 09:00:44.849: PIPE READ 8

During that 3 seconds delay,Everything is inresponsive and exactly at that time(after the 3 seconds),the mpv window appears
As I said,it happen once when I run processes I did not run yet or not run in a while
If I try to run the same process after running it and then closing it,there is no freeze at all

[void]

Nothing looks suspicious here.

Everything is stuck waiting for the OS to execute the file.

I will look into adding an option to execute files in a separate thread.

[therube]

What version of Everything?
Is this a new issue or an ongoing issue?
If new, was there a particular Everything version where it manifested?


(On my end, Win7, I run mpv.net all the time. I have no A/V, rarely restart.
Everything, & most everything I use is always open.
There are certainly times when I might not use a particular program for an extended period of time, but I've never run into issues on opening said program.)

Code: Select all

2026-07-21 12:09:13.780: COMMAND 41512
2026-07-21 12:09:13.780: exec: first expr $exec("C:\WLIB\PLAYERS\mpv.net\mpvnet.exe" %*)
2026-07-21 12:09:13.780: exec: command $exec("C:\WLIB\PLAYERS\mpv.net\mpvnet.exe" %*)
2026-07-21 12:09:13.780: exec: fullfilename "C:\out\o4jzt9.aac.m4a"
2026-07-21 12:09:13.780: exec: depth 0 
2026-07-21 12:09:13.780: exec: exec "C:\WLIB\PLAYERS\mpv.net\mpvnet.exe" %*)
2026-07-21 12:09:13.780: exec: depth 1 
2026-07-21 12:09:13.780: exec: "C:\WLIB\PLAYERS\mpv.net\mpvnet.exe" "C:\out\o4jzt9.aac.m4a"
2026-07-21 12:09:13.780: exec: shellexecute file:C:\WLIB\PLAYERS\mpv.net\mpvnet.exe param:"C:\out\o4jzt9.aac.m4a"
2026-07-21 12:09:13.780: Parameters '"C:\out\o4jzt9.aac.m4a"'
2026-07-21 12:09:13.780: Directory 'C:\WLIB\PLAYERS\mpv.net'
2026-07-21 12:09:13.780: File 'C:\WLIB\PLAYERS\mpv.net\mpvnet.exe'
2026-07-21 12:09:13.780: Mask 00000100
2026-07-21 12:09:13.780: Enter ShellExecute
2026-07-21 12:09:13.800: ShellExecute OK
2026-07-21 12:09:13.800: set 1 run history in 0.000105 seconds

[vsub]

I am using the latest 1.5 version
As far as I can remember,it was always like this but I can be wrong
What i have noticed is the bigger the executable file,the longer it make everything to be inresponsive

If I run something like this

#IfWinActive,ahk_exe Everything.exe
$NumpadEnter::
KeyWait,NumpadEnter
ControlGetFocus,Ctrl,A
If ( Ctrl = "SysListView321" )
{
ControlGetText,File, EVERYTHING_RESULT_LIST_FOCUS1, A
SplitPath, File,,Dir
Run,% File,% Dir
}
Else
Send,% A_ThisHotkey
Return

There is no freezing at all

[Herkules97]

I have noticed this too, but I haven't updated the program for the instance where it started happening.
Some shortcuts I run freeze the window. Mostly for 2 seconds.
In my case it's applied to 2 recently installed video games.

It may always be 2 seconds?

The only possible lead I have is that the device those games are on takes about 2 seconds to start running ever since I made it an external device and nothing is touching it. It used to not happen because I used to run OBSS's output to it I assume.
It's an M.2 SSD so it doesn't have to spin up. Maybe that's why it can consistently be 2 seconds.

Might be a separate issue if your last reply suggests it doesn't happen through other means.

[void]

Everything 1.5.0.1419b adds a shell_execute_thread advanced option.

When enabled, Everything will execute items in a background thread.

To enable shell_execute_thread:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  execute
• Select: shell_execute_thread
• Set the value to: true
• Click OK.

Please let me know if you have any troubles with Everything after enabling.
I will look into making this enabled by default if there's no issues.

Enabling shell_execute_thread might have the following issues that need to be tested:
There might be focus issues if you launch a program that requires UAC.
If you cancel the UAC prompt or no new window is shown, focus is unlikely to return back to Everything.
If there is an error executing an item, the error message might appear under Everything.
After closing the error message, focus is unlikely to return back to Everything.

shell_execute_thread

[vsub]

Works great,there is no freezing now,thanks
I don't use uac btw,it's turned off

[therube]

To be clear, with shell_execute_thread=false, you still have the issue?

I don't use uac

Then that begs the question, if you leave shell_execute_thread=false, & enable UAC, do you still have the delay?
(Do you still have the delay after enabling UAC & restarting Everything, with shell_execute_thread=false?)

[vsub]

To be clear, with shell_execute_thread=false, you still have the issue?

Yes,Everything window is unresponsive for few seconds with that option set to false

I don't use uac

Then that begs the question, if you leave shell_execute_thread=false, & enable UAC, do you still have the delay?
(Do you still have the delay after enabling UAC & restarting Everything, with shell_execute_thread=false?)

The uac window appears only when you try to run a program that attempts to change the windows settings and programs live mpv does not trigger the uac
And even if it did,how can I tell if the everything window is unresponsive if the uac window is on top of it

[void]

Just to clarify, there might be issues if you enable shell_execute_thread.

When shell_execute_thread is enabled, Everything tells the system there's no UI when executing items.

This means errors messages and focus might behave poorly after executing an item from Everything.
Please let me know if you have any troubles.

edit:
Enabling shell_execute_thread might have the following issues that need to be tested:
There might be focus issues if you launch a program that requires UAC.
If you cancel the UAC prompt or no new window is shown, focus is unlikely to return back to Everything.
If there is an error executing an item, the error message might appear under Everything.
After closing the error message, focus is unlikely to return back to Everything.

[vsub]

I don't see any problems,I set the UAC to the highest mode and tried running few programs that triggers uac

The only way to trigger the problems you mention is if the Everything window is set to be on top(View=>On Top)but the same thing happens even if the shell_execute_thread is not enabled

I keep the on top settings to Never because I don't need the window to be on top