Do you have a roadmap for the month, and anything that needs testing?
> WD Elements 3.5" USB 3.0 hard drive not safely removing. -everything holding handles?
I have several of these and I haven't experienced any issues Safely Removing.
TODO Suggestions
Re: TODO
(I'll just mention, that some time back I was reading up on "some" WD external drive family, not sure just which [Maybe it was an "easy NAS" or some such?], but the product itself was, or at least seemed to be quite a bastardized product - in that it did not behave in expected manners, being atypical to what one would expect such a product to do & behave. [I have a WD "Easystore".])
Re: TODO Suggestions
Thank you for your offer to help with testing.
The current priority is to get the folder sidebar to a usable state.
Group policy support and a config rewrite is next.
If you have a WD Elements I would be grateful if you could test 'safely remove device' with this drive.
Please try indexing the WD Elements HDD as a NTFS index and as a folder index.
From the recent reports of Everything holding handles to the volumes there has been another program holding onto the handle.
Everything would release the handle on request, while the other program did not.
Regex capturing needs more testing due to the recent changes to improve dynamic updates.
The current priority is to get the folder sidebar to a usable state.
Group policy support and a config rewrite is next.
If you have a WD Elements I would be grateful if you could test 'safely remove device' with this drive.
Please try indexing the WD Elements HDD as a NTFS index and as a folder index.
From the recent reports of Everything holding handles to the volumes there has been another program holding onto the handle.
Everything would release the handle on request, while the other program did not.
Regex capturing needs more testing due to the recent changes to improve dynamic updates.
Re: TODO Suggestions
Western Digital
Code: Select all
Everything_handles.TXT (& "Western Digital)
C: is my C: drive
- only thing noted is Everything's "instalDir"
E: is my "Windows" drive (where Windows is installed)
-
ah!...
W:
- is my W:(estern Digital) drive
For whatever reason, W: has (2) handles open to it (from Everything)
- where no other drives/volumes (except as noted above) have any
mention?
As it is currently (after first closing [many] C: prompt windows to W:,
W: still won't Safely Remove
"Windows can't stop your 'Generic volume' device because a
program is still using it. Close any programs..."
(BTW, OpenedFilesView lists nothing open on W:
- well, except for the "$TxfLog..." entries)
(If i have a CMD prompt open to W:, the message is different:
"The device is currently in use. Close any programs or windows that might
be using the device, and try again.")
If i Quit Everything (GUI, only), & even though at that point no handles
are then located to W:, i still can't Safely Remove.
Quitting the Service & no change.
(Windows) Device Properties says: Quick removal (default)
Quitting everything (including Everything), logging out, logging back in, no change.
Reboot the computer & log back in...
"Autoplay" dialog came up, dismissed.
hmmm... now that worked, ejected.
Install Everything Service...
unplug W: & plug back in (no on/off switch or anything)
"Autoplay", dismissed.
drive is there...
Eject, & it Ejects
drive is gone...
unplug W: & plug back in (no on/off switch or anything)
drive is there
start Everything (GUI)
it sees W:
Eject, & it Ejects
drive is gone...
so... what does that tell you... nothing really.
except that it worked, so far, after a computer reboot.
no a/v or anything untoward running (at startup or otherwise)
unplug W: & plug back in (no on/off switch or anything)
drive is there
Everything sees it...
[Everything],
clcl, 7++taskbartweaker, processhacker, vim, win32pad
Salamander, open mplayer, open mpvnet...
Eject, & it Ejects
drive is gone...
nothing unusual.
so... why did it not Safely Remove, initially?
no clue?
but rebooting, then opening all my normal programs,
& it is still Safely Removing.
so... why did it not then Safe Remove, before?
no clue?
(i should have unplugged it prior to rebooting the
computer. thinking that too might have "fixed"
things?)
(Win7, BTW)
(it's been 48 days since i've rebooted)
/if/ it is Everything,
might it be a Property?
> $recy !$i display-name:"
WD easystore 264D USB Device
Volume ...b7d
WD easystore 264D USB Device
Disk ID: {8B9A45B5-BF3A-4197-A436-9EC911649E63}
Type : USB
Status : Online
Path : 0
Target : 0
LUN ID : 0
Location Path : UNAVAILABLE
Current Read-only State : No
Read-only : No
Boot Disk : No
Pagefile Disk : No
Hibernation File Disk : No
Crashdump Disk : No
Clustered Disk : No
Volume ### Ltr Label Fs Type Size Status Info
---------- --- ----------- ----- ---------- ------- --------- --------
* Volume 9 W easystore NTFS Partition 12 TB Healthy
ALPC Port, \RPC Control\OLEA1EA01F6E51B47A1A0E33BF8B85A, 0x434
Desktop, \Default, 0x54
Directory, \KnownDlls, 0x8
...
Event, \KernelObjects\MaximumCommitCondition, 0x168
Event, \BaseNamedObjects\E::Users:RUBEN:AppData:Local:Microsoft:Windows:Explorer:thumbcache_idx.db!rwWriterEvent, 0x47c
Key, HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options, 0x4
...
Key, HKCU, 0x150
...
Key, HKCU\Software\Classes\Applications\mpvnet.exe\shell\open, 0x444
(presumably ? cause i opened mpvnet.exe through Everything, actually no clue, but guessing...?)
Key, HKU, 0x44c
...
Mutant, \Sessions\1\BaseNamedObjects\EVERYTHING_MUTEX_(15), 0x1f8
...
Section, \Sessions\1\BaseNamedObjects\windows_shell_global_counters, 0x14c
...
Section, E:\Windows\Fonts\StaticCache.dat, 0x23c
Section, \BaseNamedObjects\windows_shell_global_counters, 0x2fc
Section, Commit (64 kB), 0x530
Thread, Everything.exe (900): 3408, 0x118
...
WindowStation, \Sessions\1\Windows\WindowStations\WinSta0, 0x50
File, \Device\KsecDD, 0xfc
File, \Device\NamedPipe\Everything Service (1.5a), 0x240
File, C:\DEV\Locate\15.1304, 0x1c
File, E:\Users\RUBEN\AppData\Local\Microsoft\Windows\Explorer\thumbcache_1024.db, 0x4e8 ...
File, E:\Windows, 0x10
File, E:\Windows\Fonts\StaticCache.dat, 0x238
File, E:\Windows\winsxs\x86_microsoft.windows.c..-controls.resources_6595b64144ccf1df_6.0.7600.16385_en-us_581cd2bf5825dde9, 0x4b4
File, E:\Windows\winsxs\x86_microsoft.windows.c..-controls.resources_6595b64144ccf1df_6.0.7600.16385_en-us_581cd2bf5825dde9\comctl32.dll.mui, 0x4b8
File, E:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.24483_none_2b200f664577e14b, 0x154 ...
File, E:\Windows\winsxs\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.24542_none_5c0717c7a00ddc6d, 0x4d8
File, W:, 0x2b4
File, W:, 0x3f4
$TxfLog.blf W:\$Extend\$RmMetadata\$TxfLog\$TxfLog.blf 0x105c 10/14/2020 09:46:22 AM 03/16/2022 07:16:31 PM A 65,536 * * * 0x0012019f 0 4 System Process blf
$TxfLogContainer00000000000000000002 W:\$Extend\$RmMetadata\$TxfLog\$TxfLogContainer00000000000000000002 0x1144 10/14/2020 09:46:22 AM 10/14/2020 09:46:26 AM A 10,485,760 * * * 0x0012019f 0 4 System Process
$TxfLogContainer00000000000000000001 W:\$Extend\$RmMetadata\$TxfLog\$TxfLogContainer00000000000000000001 0x1cf0 10/14/2020 09:46:22 AM 03/16/2022 07:16:31 PM A 10,485,760 * * * 0x0012019f 0 4 System Process
Re: TODO Suggestions
I can't figure yet what the issue here is, except that it can take 8 to 15 seconds for a sleeping drive to spin up. And if I have several sleeping drives, waking up a whole procession of them can take a long time indeed. Here's a silly example. If I have five VeraCrypt/TrueCrypt volumes mounted on 5 sleeping drives, and I click "Dismount All", the program spends a minute thinking about dismounting them and then finally says it cannot once all the drives are awake. Click "Dismount All" again and all 5 immediately dismount.
With Everything (and/or other software), I suspect perhaps a similar thing is occurring. The wake lag is causing handles to hang open causing the eject to fail. Or maybe Everything is performing a scan because it detects the drive is awake or it detects the eject, and so it grabs onto a handle right at the moment of truth? If you are using any blind time delays or timeouts, be sure to boost them to 20 seconds to account for drive wake time.
Re: TODO Suggestions
Everything will not touch a volume for 30 seconds when receiving a volume eject request.
You can control this delay with the monitor_retry_delay ini setting.
Everything might be re-accessing this volume after the long wakeup delay.
If you are able to reproduce the issue could you please send some debug logs:
You can control this delay with the monitor_retry_delay ini setting.
Everything might be re-accessing this volume after the long wakeup delay.
If you are able to reproduce the issue could you please send some debug logs:
- ---make sure the drive is asleep.
- In Everything 1.5, from the Tools menu, under the Debug Submenu, click Start Debug logging.
- Request a dismount.
- wait for the dismount to fail.
- 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