full path filter triggers anti-virus app and search is extremely slow

[byzod]

using part of path as filter, the result shows instantly as expected

Snipaste_2024-05-25_13-55-38.jpg (111.81 KiB) Viewed 3044 times

Same filter but use full path, I still not get any result after 30 seconds and the cpu usage is push to ~100%

Snipaste_2024-05-25_13-55-23.jpg (113.34 KiB) Viewed 3044 times

Can I fix this by my own or is this a bug?


**
windows 10 x64
only windows defender installed

[void]

Please try disabling icon shell extensions:

• 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:
  icon
• Select: icon_shell_extensions
• Set the value to: false
• Click OK.

Does the issue persist?

[byzod]

anti-virus still eat 100% cpu and search is still slow

[void]

What columns are shown in Everything?

Does the issue persist with only the name, path, size and date modified column?

[byzod]

Yes, it still happens when I use only Name column

btw I tried add

C:\App\Something\Everything\Everything.exe

to exception of windows defender, but it still happens

Snipaste_2024-05-25_15-26-55.jpg (81.67 KiB) Viewed 3033 times

[void]

What is shown under Help -> Troubleshooting information?

[byzod]

What is shown under Help -> Troubleshooting information?

Code: Select all

Everything:	1.5.0.1378a (x64)
OS:	Windows NT 10.0 19044 (x64)
Admin:	0
Service:	1 (connected / installed and running)
Command line:	
Binary:	C:\App\...\Everything\Everything.exe
Profile:	C:\App\...\Everything\Everything-1.5a.ini
Database:	C:\App\...\Everything\Everything-1.5a.db
Instance:	1.5a
Config:	run_in_background=0
Config:	auto_remove_offline_ntfs_volumes=0
Config:	filelist_context_menu=0
Config:	single_click_tray=1
Config:	rename_move_caret_to_selection_end=1
Config:	search_delay=50
Config:	size_format=0
Config:	folder_rescan_timeout=300000
Config:	filter=EVERYTHING
Config:	treeview_everything_expand_button=1
Config:	search_history_days_to_keep=180
Config:	run_history_days_to_keep=180
Config:	search_history_keep_forever=0
Config:	run_history_keep_forever=0
Config:	ntfs_volumes=[{"path":"C:","volume_name":"\\\\?\\Volume{a8}"},{"path":"K:","volume_name":"\\\\?\\Volume{1f}"},{"path":"Q:","volume_name":"\\\\?\\Volume{81}"}]

[void]

Thank you for the logs.

The troubleshooting information shows there's no property indexing and no attribute gathering to blend hidden items.

Is the preview pane visible?



Everything shouldn't be going to disk for your results.

Please check the resource manager to confirm if Everything is going to disk:
Open the Task Manager (Ctrl + Shift + Esc)
Click the Details tab.
Click the Resource Monitor button.
In the Resource Monitor, click the Disk tab.
Select the Everything process (you may have to wait a few seconds for disk activity from Everything.exe)
Is Everything opening any files?
Is Everything opening any files when you search for *.exe path:c:\game\steam\steamapps?



I don't have a good explanation for Microsoft Defender using 100% CPU.



Please make sure you downloaded Everything from https://www.voidtools.com and your Everything.exe is code-signed by voidtools.



Does the following search trigger the same behavior with Microsoft Defender:

c:\game\steam\steamapps



Debug logs might help... I wonder if there's some odd IPC request..

• In Everything 1.5, from the Tools menu, under the Debug submenu, click Console.
  ---this will show a debug console
• In Everything, perform your *.exe path:c:\game\steam\steamapps
• wait for Microsoft Defender to use 100% cpu.
• Right click the console window caption and under the Edit submenu, click Select All.
• Right click the selection to copy.
• Could you please paste the results here.

[byzod]

Is the preview pane visible?

If you mean the alt+p thing, no, I never use it

Please check the resource manager to confirm if Everything is going to disk:
Open the Task Manager (Ctrl + Shift + Esc)
Click the Details tab.
Click the Resource Monitor button.
In the Resource Monitor, click the Disk tab.
Select the Everything process (you may have to wait a few seconds for disk activity from Everything.exe)
Is Everything opening any files?
Is Everything opening any files when you search for *.exe path:c:\game\steam\steamapps?

Seems everything only opens the $mft thing while windows defender (C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.24040.4-0\MsMpEng.exe) has a very high disk I/O
I want to add that this progress is not infinite, everything displays the result like few minutes later but it says zero which is not true (by search

*.exe p:SteamApp

it shows there're 20 results)

1.jpg (233.04 KiB) Viewed 2991 times

Please make sure you downloaded Everything from https://www.voidtools.com and your Everything.exe is code-signed by voidtools.

Just updated 2 days ago from https://www.voidtools.com/Everything-1. ... 8a.x64.zip

Does the following search trigger the same behavior with Microsoft Defender:

c:\game\steam\steamapps

Even worse, everything itself is hurting, it didn't use too much cpu but eat absurd amount of disk i/o and 97% of my ram, the pc lags like hell I have to force close everything...I mean real everything, including task manager and my screenshot application

2.jpg (332.92 KiB) Viewed 2991 times

4.jpg (26.95 KiB) Viewed 2991 times

Debug logs might help... I wonder if there's some odd IPC request..

Log of search

*.exe p:SteamApp

then

*.exe p:C:\Game\Steam\SteamApps

[NotNull]

1. Did you define a macro C in your Bookmarks or Filters?

To Check:
- Menu => Search => Organize Filters
- Check the Marco column for C

- Menu => Bookmarks => Organize Bookmarks
- Check the Marco column for C

If so, what is the search set to for this filter/bookmark?
(content: might causes this disc activity as you have no content indexed)


2. Also check if you redefined path: using a macro.


3. Type the following in the search bar and press ENTER

/define

Check the statusbar if it reports c or path



EDIT: Checked the debug log:
C: is a macro that expands to content:, which will cause files to be loaded in memory for content inspection, which will cause Defender to go in 'overload' mode.
As a quick test, search for the following. It should give instant results:

Code: Select all

*.exe   ?:\game\steam\steamapps

Please find the filter / bookmark that causes this and use a different macro.

[void]

Nice find NotNull,

I think I should disallow a-z for macro names.
( or at least block c )

[byzod]

1. Did you define a macro C in your Bookmarks or Filters?.

I defined c for content:

That's why it lags like shit lol

And p for path, r for regex
It will be a pity I can't use only one letters for this if void decid to block it as alias ;(

You know, that's 100% increase in key pressing...

[NotNull]

You know, that's 100% increase in key pressing...

There is good news too:
If the path contains a backslash, Everything will implicitly assume a path search.
So path:c:\windows (or p:c:\windows) is not needed. c:\windows is enough.

Saves you 100%

[byzod]

You know, that's 100% increase in key pressing...

There is good news too:
If the path contains a backslash, Everything will implicitly assume a path search.
So path:c:\windows (or p:c:\windows) is not needed. c:\windows is enough.

Saves you 100%

Nice!

But will it interfere with other macro?
For example I defined r for regex and want to search stand alone word "catgirl", then I search

r:\bcatgirl

, will everything think I'm search bcatgirl folder of r drive?

[NotNull]

To specify special characters that are part of the regular expression "language" (like a backslash), these characters need to be preceded by a backslash.
Example: C:\\Windows\\notepad\.exe

So it will not interfere. \b will be seen as a word boundary, not as part of a path.

[byzod]

To specify special characters that are part of the regular expression "language" (like a backslash), these characters need to be preceded by a backslash.
Example: C:\\Windows\\notepad\.exe

So it will not interfere. \b will be seen as a word boundary, not as part of a path.

Oh I got it, you're assuming search after void ban single word alias

100% saving for path: yes, but there're still more 1-letter alias I'm using...

c for content as shown in this post

I have to use cc I guess...windows didn't allow 2-letters drive name right?

[byzod]

Sadly I found that

c:

still got expanded in other situations
When I try to search pics not in C: using

pic: !c:

, cpu is burning

So the best solution for now is not to use such abbreviation, I change it to

cc:

at last