ES stopped working

[jo29]

I have a task where es.exe saves a file list periodically. The command is:

Code: Select all

es.exe * -export-efu export.efu

A couple of days ago, it stopped working. The process just sits there for hours with no CPU activity until I force quit it. It leaves behind a 0-byte file named export.efu

The variables in the last few days is a system update (Windows 10).

Everything is running as a UI in the background (not as a service). I tried closing and reopening it, system reboot, but the issue persists.

[horst.epp]

Your example command line works fine here
using the latest versions of es.exe and Everything.
What should a Windows update change here ?
Did you try that a normal es.exe command produces any results ?
______________________________________________________
Windows 11 Home x64 Version 23H2 (OS Build 22631.2792)
Everything 1.5.0.1361a (x64), Everything Toolbar 1.3.2
Es.exe 1.1.0.26

[jo29]

I am using the latest version of both (1024 and 1.1.0.26).

Code: Select all

es.exe

hangs in the same way.

Code: Select all

es.exe -h

works fine and exits.

I tried with a Windows sandbox and things work fine, so it must be something with my current setup.

[jo29]

OK. I tried to reproduce the error in the sandbox:

1. First, I renamed the db file to force Everything to recreate it. The issue persists (outside the sandbox).
2. when I copy over my settings file to Everything inside the sandbox, things work fine.
3. When I copy over my (newly-created) db file, the issue appears in the sandbox.
4. I tried to remove my drives (as folders, not NTFS volumes) one by one, and the issue is with my C:\ drive (es.exe works if I remove it). It contains > 1 million entries if this is relevant.


ETA: more details
5. C:\Users = 490,000 files. However, C:\Users\Default, C:\Users\jo29, C:\Users\Public together are < 35,000 files (!) All numbers according to Everything. Windows Explorer reports much lower numbers.
6. C:\ProgramData = 485,000 files according to Everything. Again, Explorer shows much fewer.
7. When I add these two folders together to Everything, es.exe doesn't work. If only one of them is added, es.exe works.
8. I am starting to think that this has to do with not-really-files reported on scanning or files with too long paths or something screwy with Windows. For example, most of the files in C:\ProgramData have an x on their icon and with Alt+Enter show location beginning with \\?\C:\ and size on disk of 0.

[void]

Please make sure there's some free disk space on the drive where ES is exporting.

Please make sure ES and Everything are both running as a standard user.



Could you please send a mini crash dump when ES appears frozen:

• Wait for ES to hang.
• Download Process Explorer from Microsoft:
  https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer
• In Process Explorer, select the zombie Everything64.exe process.
• Right click Everything.exe and under Create Dump, select Create Mini Dump.
• Choose a filename and click Save.
• Please send this file to support@voidtools.com or send a bug report.

[void]

Requesting all files/folders will take a long time to send over IPC.

Please make sure you specify a search when using ES.



Thank you for the crash dump.
I'm not seeing any IPC requests from Everythings end.
The request may have completed and ES is stuck processing the IPC reply.

Could you please try capturing a debug log, this might help find the issue:

• In Everything 1.5, type in the following search and press ENTER:
  /debug_log
• Run your ES request.
• Wait for ES to hang.
• Let Everything run for a minute.
• Type in the following search and press ENTER:
  /restart
  Please send your %TEMP%\Everything Debug Log.txt file to support@voidtools.com or send a bug report.

[jo29]

Thanks for replying.

I just want to say:

- things were working fine just a couple of days ago with over 2 million files.
- when I tried creating a mini dump of es.exe, it gave the error: "Error configuring dump resources: The system cannot find the file specified."
- Everything itself is working fine. Only es is showing the problem.

[void]

es.exe is limited to 2GB of ram (x86)

The IPC reply uses about 200MB per 1million files.
However, it depends on your filename lengths.

How much memory does ES use before it dies?



I need to compile a x64 version (I have put this on my TODO list)

- when I tried creating a mini dump of es.exe, it gave the error: "Error configuring dump resources: The system cannot find the file specified."

Sounds like ES is dying and the process no longer exists.

[jo29]

How much memory does ES use before it dies?

Around 6MB. It is born dead though, sortof! It doesn't show activity at all.

However, in a sandbox, I removed some drives to see when es.exe works. I found that when it does, it does reach close to 2GB.

Sounds like ES is dying and the process no longer exists.

But the process is right there for hours if I don't kill it

[void]

Thank you for the logs.

2023-12-11 11:24:14.246: SIZE CHECK 2111479146 2111479146 diff 0 count 2251025

wow, the IPC reply is over 2GB.
This reply is too large for the ES client.



I wonder why the reply is soo large.
It should be under 400MB.

Have you created an es.ini?
-Please try an Everything search for:
exact:es.ini

Maybe you are requesting more than filenames?

[jo29]

Have you created an es.ini?
-Please try an Everything search for:
exact:es.ini

Nothing.

Maybe you are requesting more than filenames?

I don't do it through es, but in Everything I also index some other parameters.

[void]

Please try an -IPC1 request:

ES.exe -ipc1 * -export-efu export.efu

Does this also fail?

[jo29]

Does this also fail?

Yes.

[void]

Some ideas:

If you need to export the data now, please try the GUI: File -> Export...
-How large is this exported file?



Please try the following ES export:

ES.exe path:len:^>=260 -export-efu export.efu

This will save paths longer than 260 characters.
Please check the exported file for any erroneous filenames.

I'm guessing there's filenames that are thousands of characters..
How many lines in this exported file?

[jo29]

If you need to export the data now, please try the GUI: File -> Export...


-How large is this exported file?

1GB

A few days ago (before the system update?), the es output file was ~150MB.

Please try the following ES export:

ES.exe path:len:^>=260 -export-efu export.efu

Still hangs.

But I tried "path:len:>=260" in Everything. 860,000 results (!) Most of them in two places:

C:\ProgramData\Microsoft\Windows\Containers\BaseImages\
C:\Users\All Users\Microsoft\Windows\Containers\BaseImages\

I'm guessing there's filenames that are thousands of characters..

True. I did one file. > 1000 characters.

[jo29]

Here is one example:

Code: Select all

\\?\C:\Users\All Users\Microsoft\Windows\Containers\BaseImages\{UUID}\BaseLayer\Files\Users\All Users\Microsoft\Windows\Containers\BaseImages\{UUID}\BaseLayer\Files\Users\All Users\Microsoft\Windows\Containers\BaseImages\{UUID}\BaseLayer\Files\Users\All Users\Microsoft\Windows\Containers\BaseImages\{UUID}\BaseLayer\Files\Users\All Users\Microsoft\Windows\Containers\BaseImages\{UUID}\BaseLayer\Files\Users\All Users\Microsoft\Windows\Containers\BaseImages\{UUID}\BaseLayer\Files\Users\All Users\Microsoft\Windows\Containers\BaseImages\{UUID}\BaseLayer\Files\Users\All Users\Microsoft\Windows\Containers\BaseImages\{UUID}\BaseLayer\Files\Users\All Users\Microsoft\Windows\Containers\BaseImages\{UUID}\BaseLayer\Files\Users\All Users\Microsoft\Windows\Containers\BaseImages\{UUID}\BaseLayer\Files\Users\All Users\Microsoft\Windows\Containers\BaseImages\{UUID}\BaseLayer\Files\Windows\System32\DriverStore\en-US\prnms008.inf_loc

{UUID} is 36 characters.

8. I am starting to think that this has to do with not-really-files reported on scanning or files with too long paths or something screwy with Windows. For example, most of the files in C:\ProgramData have an x on their icon and with Alt+Enter show location beginning with \\?\C:\ and size on disk of 0.

[void]

But I tried "path:len:>=260" in Everything. 860,000 results (!) Most of them in two places:

C:\ProgramData\Microsoft\Windows\Containers\BaseImages\
C:\Users\All Users\Microsoft\Windows\Containers\BaseImages\

This would explain the large IPC request.

To exclude these folders:

• In Everything, from the Tools menu, click Options.
• Click the Exclude tab on the left.
• Click Add....
• Select C:\ProgramData\Microsoft\Windows\Containers\BaseImages and click OK.
• Click Add....
• Select C:\Users\All Users\Microsoft\Windows\Containers\BaseImages and click OK.
• Click OK.

[jo29]

I did and it works now (es uses ~1.1GB RAM). Thanks.

This is an issue with Windows, isn't it? There are recursive shortcuts inside these two folders that I am guessing happened either due to the update or due to using Windows Sandbox.

[void]

No idea.

These files are created by Windows and are real.

I have no idea if they can be deleted.

I am guessing they are from an update.

[jo29]

I noticed that in the ini, there is

Code: Select all

C:\\ProgramData\\Microsoft\\Windows\\Containers\\BaseImages\\{UUID}\\BaseLayer

under ntfs_volume_paths, although, the include in db box is unchecked

860,000

Down to a meager 417,000 now . The ones in C:\Users\All Users\Microsoft\Windows\Containers\BaseImages\ won't go away for some reason. I tried to exclude

C:\Users\All Users\Microsoft\Windows\Containers\BaseImages\

and

C:\Users\All Users\Microsoft\Windows\Containers\BaseImages\*

but nothing.

[void]

Please try manually adding C:\Users\All Users\Microsoft\Windows\Containers\BaseImages as the UI likely doesn't have permission:

• In Everything, from the Tools menu, click Options.
• Click the Exclude tab on the left.
• Click Add Filter....
• Set the filter to:
  C:\Users\All Users\Microsoft\Windows\Containers\BaseImages
• Click OK.
• Click OK.

[void]

C:\\ProgramData\\Microsoft\\Windows\\Containers\\BaseImages\\{UUID}\\BaseLayer

Please try removing this NTFS volume:

• In Everything, from the Tools menu, click Options.
• Click the NTFS tab on the left.
• Select any offline NTFS volume. (are any listed as offline?)
• Click Remove.
• Click OK.

[jo29]

Please try removing this NTFS volume:

Greyed out.

I tried exiting Everything, removing it from the ini but it reappeared.

Filter

That's what I tried. It worked for the ProgramData folder but not the All Users folder.

[jo29]

Code: Select all

*\BaseLayer\Files

worked for both folders.

[void]

C:\\ProgramData\\Microsoft\\Windows\\Containers\\BaseImages\\{UUID}\\BaseLayer

Please try excluding this NTFS volume:

• In Everything, from the Tools menu, click Options.
• Click the NTFS tab on the left.
• Select the C:\\ProgramData\\Microsoft\\Windows\\Containers\\BaseImages\\{UUID}\\BaseLayer NTFS volume. (What is this shown as?)
• Uncheck Include in database.
• Click OK.

[jo29]

C:\\ProgramData\\Microsoft\\Windows\\Containers\\BaseImages\\{UUID}\\BaseLayer

Please try excluding this NTFS volume:

• In Everything, from the Tools menu, click Options.
• Click the NTFS tab on the left.
• Select the C:\\ProgramData\\Microsoft\\Windows\\Containers\\BaseImages\\{UUID}\\BaseLayer NTFS volume. (What is this shown as?)
• Uncheck Include in database.
• Click OK.

It is (and was) off.

[void]

Everything 1.5.0.1362a will now automatically remove offline NTFS volumes by default.

This is now required as it looks like Microsoft is mounting several different base images.



To automatically remove offline volumes:

• In Everything, from the Tools menu, click Options.
• Click the NTFS tab on the left.
• Check Automatically remove offline volumes.
• Click OK.

[void]

Added ES-1.1.0.27 (x64)