Everything prevents ejection of USB drive

[unknownsoldierx]

Windows 10 x64 build 1903
Everything 1.4.1.935 x64
External USB drive is NTFS.

I want Everything to index the drive, and it works great, but I can never eject the drive unless I exit Everything.

[therube]

What type of drive?
Flash "thumbnail" drive? HDD in an enclosure? ...
Size?

[unknownsoldierx]

Western Digital 8TB Elements (USB 3.0 enclusure.)

Drive is already indexed in Everything.

I plug in the drive, and no matter how long i wait, I can't eject the drive until I exit Everything. I can always eject the drive immediately after exiting it.

[unknownsoldierx]

Still hoping for a solution to this.

Still happens every time I try to eject the drive. I've found that it produces an entry in the event log.

The application \Device\HarddiskVolume3\Programs\Everything\Everything.exe with process id 11200 stopped the removal or ejection for the device USB\VID_1058&PID_25A3\37484B585345414E.

[therube]

Try the nightly, viewtopic.php?f=2&t=5718, as that has some changes related to "removals", & see if that makes any difference?


(I rarely reboot, & had gone to "eject" my S: drive, a HDD plugged into a USB adapter, & would only get an "in use" message. [Didn't think to use https://www.nirsoft.net/utils/opened_files_view.html at the time.] Anyhow, on seeing that, I ended up closing everything [including Everything], to no avail. Still couldn't successfully remove the drive. So at that point, I just rebooted. Since restart, I'm back to being able to remove S:, as expected. IOW, in my case, my issue appeared to not be Everything related.)

[ericgl]

I'm using the latest Everything v1.5.0.1315a on two computers. One with Windows 10 x64 en-US and one with Windows 11 x64 en-US.
On both, Everything prevents the safe removal/ejection of many USB drives.
Only after closing Everything, I can safely remove the USB drive.
*Note that the USB drives are indexed and monitored by Everything.

Any solution to this issue?

For a USB drive with 2 partitions, the Debug console shows this:

[void]

Thank you for the issue report.

What type of hardware are you using? (so I can test this my end)

Could you please send some Everything Service debug output:

• From the Start menu, search for:
  regedit
• Right click Registry Editor and click Run as an administrator.
• In the Registry Editor, navigate to:
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Everything (1.5a)
• On the right, right-click ImagePath and click Modify....
• Change the string value data to:
  "C:\Program Files\Everything 1.5a\Everything64.exe" -svc -debug-log
• From the Start menu, search for:
  services
• Right click Services and click Run as an administrator.
• Right click Everything (1.5a) and click Restart.
• In Everything, from the Tools menu, click Exit.
• Restart Everything.
• Attempt to safely remove / eject your USB drive.
  ---
• After safely remove / eject fails:
  ---
• From the Start menu, search for:
  regedit
• Right click Registry Editor and click Run as an administrator.
• In the Registry Editor, navigate to:
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Everything (1.5a)
• On the right, right-click ImagePath and click Modify....
• Change the string value data to:
  "C:\Program Files\Everything 1.5a\Everything64.exe" -svc
• From the Start menu, search for:
  services
• Right click Services and click Run as an administrator.
• Right click Everything (1.5a) and click Restart.
• Please send your C:\Windows\Temp\Everything Service Debug Log.txt to support@voidtools.com

This log will help identify the issue so I can work on a fix.
Everything is most likely missing the system notification for volume removal or is closing and immediately reopening these volumes.



Process Explorer from Microsoft can be used to find programs that have open handles to volumes.

[ericgl]

Hi David,

So I did as you asked.

• Added -debug-log to the registry value ImagePath.

• Restarted the Everything service.

• Restarted the Everything app.

• Tried ejecting an attached USB drive (which has 2 partitions, if that makes any difference).
  Everything64.exe seems to prevent the ejection of the drive.

Everything Service debug log sent. Please check.
* Please note that sometimes after another attempt or two to eject the drive, the USB drive can be safely removed, as if the "lock" gets removed.
The only open handles are by System and Everything. Nothing else.

[void]

Thank you for the debug logs ericgl,

The logs show Everything successfully registers for device events.
Unfortunately, there is no notification received to eject/safely remove the device.

Tried ejecting an attached USB drive (which has 2 partitions, if that makes any difference).
Everything64.exe seems to prevent the ejection of the drive.

I did test a drive with 2 partitions on my end without issue.
Safely removing any of the 2 volumes will cause Everything to close both handles to the two volumes.

It's odd that Everything doesn't receive any notifications on your PC.
I will make some changes to Everything by trying an alternate method for detecting volume removal requests.

[void]

Everything 1.5.0.1319a will now register for device notifications from the Everything search client process (instead of the Everything service)

This should improve detection of requests to safely remove a device.

[ericgl]

Thanks David,

I'll report back after I test thoroughly.

[ericgl]

Well, it still seems to be the same with build 1319.
On first try, Everything seems to be blocking the ejection of the USB drive.
However, sometimes on the 2nd or 3rd try, ejection of the USB drive succeeds.

[void]

Thank you for testing Everything 1319 ericgl,

Could you please send some debug output when Everything prevents the ejection of your USB drive:

• In Everything, from the Tools menu, under the Debug Submenu, click Start Debug Logging.
• Attempt to eject the USB device.
• After ejection fails:
• From the Tools menu, under the Debug Submenu, click Stop Debug Logging.
  ---this will open your Everything Debug Log.txt---
• Could you please send this file to support@voidtools.com

[ericgl]

Debug log sent.

[void]

Thank you for the debug logs ericgl,

I am able to produce the issue here using a device with multiple volumes.
I am working on a fix..

[void]

Everything 1.5.0.1320a fixes an issue with preventing devices from being safely removed.

Everything was sometimes immediately reopening volumes after closing all handles.

[ericgl]

Hi David,

I'm now using Everything v1.5.0 b1321a on Windows 11 Pro x64 en-US 22H2 (build 22621.525).

I'm afraid I'm still having the issue - prevention of USB drive ejection.

"Problem Ejecting USB Attached SCSI (UAS) Mass Storage Device
The device is currently in use..."

The device is NOT in use. No files are open and no data transfer going on.
After closing the Everything app, I still cannot eject the drive properly.

It seems that some files are locked by the "System" process. Something to do with $Extend\$RmMatadata...
Maybe this is a Windows issue, not related to Everything ?

[void]

Thanks for trying 1321a.

After closing the Everything app, I still cannot eject the drive properly.

Sounds like the system is still holding on to a handle..
$RmMatadata\$txf... is related to the USN Journal.


https://superuser.com/questions/491539/how-to-safely-remove-a-device-blocked-by-the-system-process-with-a-handle-on-e
https://social.technet.microsoft.com/Forums/windows/en-US/703d58e6-b7d1-4525-8985-6f6e2b99b6a2/cannot-eject-removable-usb-drive?forum=w7itprogeneral
https://superuser.com/questions/420168/safely-remove-external-usb-drive-fails-due-to-extend

[ericgl]

Hi David,

I believe I finally found the culprit!
I use Symantec Endpoint Protection (SEP) as my Anti-Virus and Firewall solution on my computers.
It places a special protected folder inside the "System Volume Information" on all attached NTFS volumes.
This folder contains a database file which SEP uses for "file reputation lookups": https://community.broadcom.com/symantec ... gestviewer.

For example:
Q:\System Volume Information\EfaSIDat\SYMEFA.DB

So, it seems this behavior locks the volume and prevents it from being ejected.
Sorry to have reported mistakenly about Everything, but it is only because Everything also appears as a locking process.
Please see the attached screenshot from an app I use called Zentimo - I use it to handle USB drives (it's just like the app USB Safely Remove):

[malventano]

Which app is this (to view open handles)?

[ericgl]

The app is called Zentimo (zentimo.com/features.htm).
USB Safely Remove also does the same (safelyremove.com/features.htm).

[void]

Just to clarify for others...

Everything will definitely open handles to your volumes for indexing and monitoring of file system changes.

However, Everything registers for device notifications and will close all these handles when you request to safely remove your device.



If you would like to confirm Everything is closing these volume handles:

• Run Everything in debug mode:
• In Everything, type in the following search and press ENTER:
  /debug
• Look for the following lines in the debug console:
  RegisterDeviceNotification volume_handle <volume_handle>
  RegisterDeviceNotification service_volume_handle <service_volume_handle>
  RegisterDeviceNotification %s failed! <error-code>
  stop ntfs_monitor <drive-path> <service-handle> <monitoring-thread-handle>

[esalkin]

I am using an encryption tool called VeraCrypt. ( https://veracrypt.fr/en/Home.html )
I cannot dismount the encrypted volume do to the open handles.
If I dismount the USB drive then I risk corrupting the VeraCrypt volume.
Is this an issue with Everything not recognizing the encrypted volume is being dismounted?
Or is it an issue with VeraCrypt not sending a correct signal to the system?

If it is a Veracrypt (or other such apps) causing the issue can a function be added to Everything that tells it to release the volume?

Tried with V 1.4 and 1.5 Same results.

[void]

Everything does open handles to your Veracrypt volume to watch it for filename changes.
Everything will release these handles when requested.



Everything is closing handles to my Veracrypt volume when I request a dismount.
The dismount is successful.

Veracrypt broadcasts WM_DEVICECHANGE with DBT_DEVICEREMOVEPENDING and a volume by drive letter.



It is possible Everything will not receive this message if Veracrypt runs as a standard user and Everything is running as admin.

Please make sure Everything and Veracrypt are running as a standard user:

• In Everything, from the Tools menu, click Options.
• Click the General tab on the left.
• Check Store settings and data in %APPDATA%\Everything.
• Uncheck Run as administrator.
• Check Everything Service. (Please make sure this is tick-checked and not square-checked)
• Click OK.
• Exit Everything (right click the Everything tray icon and click Exit).
• Restart Everything.

Veracrypt does not implement support for RegisterDeviceNotification.

(Error 1066: ERROR_SERVICE_SPECIFIC_ERROR - The service has returned a service-specific error code)

There's no way for Everything to receive device notifications for Veracrypt volumes.
This shouldn't matter as Everything will process requests to close handles with DBT_DEVICEREMOVEPENDING.



Some options:

Stop index updating from Everything 1.5 -> Index -> Stop updates.
Unmount your Veracrypt volume.
Resume index updates from Index -> Update indexes.

Exit Everything before you dismount your volume.

Use folder indexing instead of NTFS indexing (Tools -> Options -> NTFS/Folders)
Folder indexing doesn't hold any handles open to your volume.

Disable monitoring on this volume from Tools -> Options -> NTFS -> Veracrypt volume -> Uncheck Monitor changes.



If the issue persists, could you please send a debug log when requesting a dismount.

[ericgl]

esalkin,

I believe I have found the solution to this "blocked ejection" problem.
In the "System Volume Information" of NTFS drives, a file is created called tracking.log.
To investigate this issue, I had to take ownership of this folder to see what's in it on one of my SATA-connected drives - which sometimes refused to get ejected. I know it's not a USB drive, but I have its SATA port set to hot-swap in the UEFI BIOS, so Windows (in theory) should be able to eject it if no file or process from this drive are open.

It seems that the "Distributed Link Tracking Client" service (TrkWks) is the culprit here (EDIT: or so I thought...read on) - It creates this tracking.log file and for some reason keeps an open handle on it - which prevents the drive from getting safely ejected.

Stopping this service and then trying to eject the drive (which previously refused to get ejected) will now work. At least in my case.
Hope this works for you as well.
You can then restart the "TrkWks" service.

EDIT 2024-02-16:
It seems stopping the "TrkWks" service sometimes is NOT enough, or just not the right solution.
Even with the TrkWks service not running, I still had issues ejecting the drive. So after probing some more with procmon, and trying out several ideas, it seems that the fact that Everything64.exe accesses the USN Journal of the drive - may actually be the problem.

I removed the drive from the NTFS index (UNCHECKED "Include in database) which also disables the use of the USN Journal, and added the drive in the "Folders" so it can still be indexed and monitored without the use of the USN Journal.



Now I can properly eject the drive (again). I even started the TrkWks service, and I was still able to safely eject the drive.
Will continue to check to make sure this indeed is the proper solution for now...

I also published my findings on SuperUser: https://superuser.com/a/1829966/554644