I apologize (well, potentially). Before I posted previously, Everything did fail to index a new file I'd just created. But since then, I haven't had an issue. So the previous fix may have at least partially solved the problem.

Sorry--I only use it a few times a day, so it takes time for me to establish patterns. I test for a living, and don't have the wherewithal to do it off-hours as well.

Difference in .efu files: 2060 entries (!)
Compare file contents: 2261 difference(s) foundThe difference in entries is usually between 200 and a few thousand entries.
The number of entries often differs by about 1250.

Not immediately in the index are usually files from the following folders:
C:\Program Files (x86)\Norton 360\... -> example below...
C:\ProgramData\Norton\...
C:\Program Files\WindowsApps\... -> example below...

Examples - the following two files were only visible in Everything after "Force Rebuild":

The following questions arise for me:
- How can it be that I find a just created text file (D:\Daten\y.txt) IMMEDIATELY in Everything and
other files from drive C: with an older date are not in the index?
- Could it be that Everything has no access to these files for some reason?

It sounds like the NTFS monitors are working, except some files are missed.

Could you please run Everything in debug mode, you don't have to send me any of the logs..

Just look for lines in red like the following:
unable to update ntfs folder: ABC: folder not found
unable to update ntfs folder: ABC: parent 0123456701234567 not found
folder name ABC already exist, yet FRN 0123456701234567 doesn't
unable to remove ntfs folder: 0123456701234567: file not found
unable to rename ntfs folder: 0123456701234567: move into child
unable to rename ntfs folder: 0123456701234567: not found
unable to rename ntfs folder: 0123456701234567: new parent not found
unable to add ntfs file: ABC.txt: parent 0123456701234567 not found
unable to remove ntfs file: ABC: file not found

Lines in red and errors in grey: No colors available in Everything Debug Log.txt.I did not find any of the above entries (hints for errors) in the Everything Debug Log.txt file.

The only thing I noticed was a couple of those entries:
2019-10-22 13:36:36.014: CreateFileW(): GetLastError(): 5: Failed to open volume \\?\Volume{126add44-5607-11e3-ba64-806e6f6e6963}
but I think you had classified such entries as irrelevant in another case.

It sounds like the NTFS monitors are working, except some files are missed.

Could you please run Everything in debug mode, you don't have to send me any of the logs..

Just look for lines in red like the following:
unable to update ntfs folder: ABC: folder not found
unable to update ntfs folder: ABC: parent 0123456701234567 not found
folder name ABC already exist, yet FRN 0123456701234567 doesn't
unable to remove ntfs folder: 0123456701234567: file not found
unable to rename ntfs folder: 0123456701234567: move into child
unable to rename ntfs folder: 0123456701234567: not found
unable to rename ntfs folder: 0123456701234567: new parent not found
unable to add ntfs file: ABC.txt: parent 0123456701234567 not found
unable to remove ntfs file: ABC: file not found

I did not find "usn journal failed", "bad cb", "record overflow", "bad file name offset", or "bad record length" entries, nor "read usn journal". I was a bit confused by your reference to "red" and "grey".

I shut down Everything after 7 minutes, since it was still "Updating database...", and I'm perhaps overly paranoid about wear and tear on my 6-year-old SSD.

Result after checking the *Everything Debug Log.txt files:None of the above error messages are contained in these files.

Result after checking the file: Everything Service Debug Log.txt ... renamed to:
20191026@115729_Everything Service Debug Log.txt 7.003.185 26.10.2019 11:57None of the above error messages are contained in this file.

On my other internal (data-)hard disks (D:, I:, J:) I haven't missed any entries yet.
The PC is always used as a user and not as an administrator.

Notnull wrote:I guess you also have to enable the debug console ( Ctrl-` to enable /disable it )
That will open a console window. Do not close it with the [X] in that window, but use a Ctrl-` in the Everything window instead.

I think this variant of debug logging doesn't have a console window.
The last time I saw one was in the topic "Everything - portable use",
in which an Everything.exe was previously specially prepared by the author.

Nevertheless I would be interested in this shortcut:
Could this shortcut be used to extract the content from a console window (with rapidly changing screen content)?
to the clipboard?

Does the shortcut refer to an English keyboard layout? (Here: German keyboard layout).
Which keys would I have to press at the same time on a German keyboard?

Nevertheless I would be interested in this shortcut:
Could this shortcut be used to extract the content from a console window (with rapidly changing screen content)?
to the clipboard?

Use the mouse to selct some text in the console window.
Conhost.exe (the program responsible for all input/output to/from console applications) on Win10 will halt all further screen output until you press ESCAPE.

You do not have the required permissions to view the files attached to this post.

... Use the mouse to selct some text in the console window.
Conhost.exe (the program responsible for all input/output to/from console applications) on Win10
will halt all further screen output until you press ESCAPE.

This can work, but my experience has shown that it usually doesn't work for me.
With CTRL+A this works reliably and afterwards with CTRL+C I can get the whole screen content,
and then filter in EmEditor for desired entries.

I assume that the console content is reflected in the Everything Debug Log.txt file.
Everything has now been clarified for me on this topic (debugging console).
Thanks again.

This error occurs when a new folder is created, but that folder already exists in the Everything database (by name) with a different FRN.
This may occur if this folder was deleted and recreated and Everything missed the deletion. Again, I would need to see the full logs.
Folder FRNs can not change once a folder is created.
This CachedFiles folder has a very high Sequence Number (0x057f), so it looks like it is deleted and recreated often.

For future release I'll make sure Everything just removes the old inconsistent folder and re-adds it with the correct FRN. This may help pick up new changes, but not fix the underlying issue.

This is a empty NTFS record. Everything and Windows will ignore this file record.

Thank you for that information.

Due to the number of entries, they probably cannot be related to those entries,
which I miss (usually 1250+ entries - only on drive C: in the above stated directories)
AND receive after a "Force rebuild"(!).