EjectUSB

EjectUSB
Version 1.6
Designed to be a simple utility to close all programs running from a specified drive or folder and then attempt ejection if a drive was specified. Extended functionality includes flushing the file cache, closing Explorer windows and removing registry entries and Recent Document shortcuts referencing the specified drive or folder.

Documentation and an example configuration file are included in the ZIP. The source code is available as a separate download.

TrueCrypt and combination flash card / flash drives support will be made available via configuration files after sufficient testing has been conducted.

See EjectUSB in action!
» Watch the flash video

Release Version 1.6:
» Download EjectUSB (259 kilobytes, 115270 downloads)
» Source Code (26 kilobytes, 9186 downloads)


Change Log:
Version 1.6
- Bug fix: EjectUSB no longer triggers file access errors on WinXP when run from read-only media when trying to load its hourglass tray icon.
- Bug fix: Sysinternals registry keys are no longer erroneously deleted.

Version 1.5 (161498 downloads)
- Bug fix: EjectUSB's ejection success message will more reliably appear on Vista.
- Bug fix: EjectUSB's ejection success message will only disappear when the ejected drive is unplugged instead of disappearing when any USB device is unplugged.
- Bug fix: EjectUSB will no longer display an error if WMI functions fail.
- Improvement: EjectUSB's ejection success message now displays the ejected drive's name.
- Addition: Added /ini command line argument to allow a settings file to be specified.
- Addition: Added /settings command line argument to display a settings interface window.
- Addition: Included Settings.bat with the download to make adjusting settings easier.
- Change: Modified the manifest information.

Version 1.4 (88989 downloads)
- Bug fix: Graceful program closing no longer only targets programs with a visible window.
- Bug fix: Flushing file buffers can no longer cause ejection to fail.
- Improvement: Dead tray icon cleanup is more resilient and slightly faster.
- Improvement: EjectUSB can now generate its own ejection success message. This will make ejection seem much faster on most computers.
- Addition: Added NoFakedMsg setting to the configuration file format.

Version 1.3 (107575 downloads)
- Bug fix: Program closing on Win9x works again (was broken in 1.2).
- Bug fix: Fixed issues on Win9x when running EjectUSB from a drive's root folder.
- Improvement: Implemented hybrid batch scripting. This provides theorhetical support for TrueCrypt and combination flash card / flash drives as well as conditional operations.
- Improvement: EjectUSB can now interface with EjectMedia.exe to eject flash cards / CDs.
- Improvement: Implemented support for Subst.
- Addition: Added DoNotSubst and NoRedirect settings to the configuration file format.
- Addition: Added /nobat command line argument to disable use of the hybrid batch file (if present). Meant to be used within the hybrid batch file if starting another instance of EjectUSB to prevent infinite loops.

Version 1.2 (4933 downloads)
- Bug fix: Improved handling of relative paths (\ and ..).
- Improvement: Implemented API-based ejection.
- Improvement: Implemented file cache flushing. Requires admin privileges.
- Improvement: EjectUSB can now interface with Sync (from Sysinternals) to flush the file cache (instead of using its own internal file cache flushing function). Requires admin privileges.
- Improvement: Improved command line argument parsing; drive letter or folder path no longer are required at all and no longer must be the first command line argument.
- Improvement: Efficiency improvements related to DLL calls.
- Addition: Added DoNotFlush and NoEjectAPI settings to the configuration file format.
- Change: RemoveDrive.exe is called with the -L switch to loop until successful ejection. This can be aborted by closing the RemoveDrive.exe console window.
- Change: DevEject.exe is now launched hidden.
- Change: Added current version number to EjectUSB.exe version info.

Version 1.1 (3413 downloads)
- Bug fix: Improved ejection capability via EjectUSB's own internal ejection routine.
- Bug fix: Improved command line argument and input parsing for handle.exe; there were some formatting differences between the output on Win9x and WinXP.
- Bug fix: TimeToWait is now a maximum per ''phase'' rather than per program; in rare cases EjectUSB could wait for multiple minutes on closing programs with the default TimeToWait value of 5 (seconds).
- Bug fix: Cleaning up dead tray icons was triggered by faulty criteria; in simple terms, dead tray icon cleanup was occuring when it didn't need to (wasting up to 1 second).
- Improvement: Minor efficiency improvements related to the previous two changes.
- Improvement: EjectUSB can now interface with Unlocker to close open file handles; simply UniExtract the Unlocker installer and put Unlocker.exe and UnlockerDriver5.sys in the same folder as EjectUSB. Unlocker requires admin privileges and doesn't work on Win9x.
- Improvement: Added a FAQ section to the documentation.
- Change: Slight change to the EjectUSB logo.
- Change: Separated the source code into its own ZIP file. Source code for EjectUSB will always be released with each version of EjectUSB.

Version 1.0 (1695 downloads)
- Initial release.

[ 07 August, 2009 ] • [ William Hedrick ] • [Bookmark and Share]

Comments (141)

[ Page 7 of 8 ] • [ << | < | 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 | > | >> ]

I have noticed that the entirety of my HKCU\Sysinternals registry key has been getting removed lately. I have been running ProcMon for the last few days waiting for it to show the event.

Today, I got a hit: EjectUSB.exe. I downloaded the source, and sure enough, I found:
RegDelete("HKEY_CURRENT_USER\Software\Sysinternals") in code where it uses sync.exe and handle.exe. I don't have AutoIt or a debugger (yet), but apparently the guard logic preceding the delete has a flaw. I have Sync and Handle in the same directory as EjectUSB, but all are on my C: drive. Cleaning up after a one-time use of Sync or Handle makes sense as part of removing them, but not if they are permanently installed.
[ 31 July, 2009 ] • [ larry ] • [ 13:34:17 ]

thank you very much mate..... : )
[ 01 August, 2009 ] • [ Ax ] • [ 08:31:13 ]

Thanks for the heads up larry, the issue will be resolved in version 1.6.

Edit - To be fair, the code does have a safety mechanism to keep it from removing the registry entry if it already existed. For what you're saying to occur, the safety would have to be failing, so I'll be looking into it intensively. In the mean time, I'd like you to double-check that EjectUSB is the culprit: run a Sysinternals tool and accept its EULA, check the registry to be sure an entry was added, then use EjectUSB (with Sync or Handle present) and again check the registry.
[ 01 August, 2009 ] • [ William Hedrick ] • [ 17:30:54 ]

The HKCU\Software\Sysinternals key does exist, and the EulaAccepted value is present for Sync and Handle (and about 20 others). I've only just spent my first few minutes with AutoIt, but I think the problem is that the Default value of the keys is NOT set, so RegRead() actually returns @error of "-1" rather than the "0" expected by the script. If the key does not exist at all, it returns "1"

Thanks for the quick response!
[ 02 August, 2009 ] • [ larry ] • [ 20:54:21 ]

EjectUSB checks RegRead for an @error of 0 and if it's NOT 0, it deletes the key. A zero should occur if the key exists. For the safety to fail, the key must exist, but RegRead must be setting an @error value of NOT 0. So, that must be what's occuring; my initial guess is that RegRead is returning an @error <> 0 for a key that has a default value (@=-). I'll get it fixed and release 1.6 within a couple days. This will just be a bug fix release (fixed read-only errors, false positive virus results, erroneously deleting the Sysinternals key), with additional functionality pushed back to 1.7 after I can do further testing.

Edit - I realize that's basically what you said, but I think it was worth restating. Rather than the script deleting the key on an error, I'll have it delete it only if it's not found.
[ 03 August, 2009 ] • [ William Hedrick ] • [ 01:25:37 ]

Thanks again for the quick response, and for the excellent utility!
[ 03 August, 2009 ] • [ larry ] • [ 08:55:37 ]

For those that are curious, the issue came about due to a difference between Win9x and the NT/XP line; RegRead returns 0 for a key with an empty (default) value on 9x, but returns -1 on XP.
[ 03 August, 2009 ] • [ William Hedrick ] • [ 17:23:50 ]

@2nd comment:
Good app. Just don't run it on C. RTFM!
[ 09 August, 2009 ] • [ Firefox ] • [ 09:03:48 ]

Happily use sincece ver.1.4
Great app!
[ 28 August, 2009 ] • [ Sander ] • [ 06:04:17 ]

Brilliant! Works a charm! THANKYOU
[ 01 September, 2009 ] • [ Andrew ] • [ 23:47:16 ]

How do I use this utility?
I know that must insert it in USB Pen.
[ 28 September, 2009 ] • [ AAA ] • [ 21:20:41 ]

@AAA

Decompress EjectUSB.zip into an USB key. To configure, click on Settings.bat.
[ 29 September, 2009 ] • [ Rockey2009 ] • [ 17:05:20 ]

Ouppsss!!!

To close your USB key, click on EjectUSB.exe. That's it!
[ 29 September, 2009 ] • [ Rockey2009 ] • [ 17:07:28 ]

Hello William,

Can you advise if your utility works with any operating system?
[ 02 October, 2009 ] • [ Morgan ] • [ 05:16:58 ]

Well, EjectUSB is designed to work with nearly any version of Windows, ranging from Windows 98 to Windows Vista (and it should work on Windows 7, though I haven't personally verified as much). It's unlikely that it works on Windows 95, and I haven't tested it on Windows NT.

EjectUSB won't work on any variants of Linux, BeOS, etc.
[ 02 October, 2009 ] • [ William Hedrick ] • [ 10:34:13 ]

I am newbie. Can you advise what should I do if I want EjectUSB to not to forcibly close programs with unsaved documents? Can EjectUSB work like what Windows do with such programs when it shuts down?
[ 22 October, 2009 ] • [ Simon ] • [ 02:29:23 ]

I have the same question as Simon. Today, at work, we had to evacuate the building for a fire (luckily it wasn't a real one), and I used EjectUSB to eject my USB. However, when I put my USB back in afterwards, I noticed that my Opera and Firefox tabs were gone. I presume it's because EjectUSB doesn't "gracefully" close programs (even thought I have "NoGraceful=0" in the ini).

Is it possible to send a WM_CLOSE event (0x10) to each window? I'm not sure if you know AutoHotkey, but the below code would send this event and close the specified window. The "hwnd" is the window handle. If the notepad file wasn't saved, the user would be prompted to save. This way, shutting down our flash drive can be similar to shutting down your computer. Of course, this could be opt-in, so to ensure backward compatibility.

[code]
hwnd := WinExist("Untitled - Notepad")
WM_CLOSE := 0x10
SendMessage, WM_CLOSE, 0, 0,, ahk_id %hwnd%

MsgBox, % ErrorLevel
[/code]
[ 12 January, 2010 ] • [ Matthew Brennan ] • [ 17:54:48 ]

That's basically what ''Graceful'' closing is in EjectUSB, Matthew (search the source code for ''WinClose''). It first tries to send close commands to all windows of programs running from the drive you're trying to eject (it does this fairly aggressively, often also closing any ''save on exit'' dialog boxes); a second pass then forcefully quits all programs that failed to exit. The next version of EjectUSB is planned to have the option to wait for user interaction if any ''save on exit'' dialogs pop up after the graceful closing pass; this won't be the default behavior, as EjectUSB is intended to eject a drive quickly, not wait on you to save things that you hadn't. I intend to make it slightly more tolerant of programs that are slow to exit to avoid problems with saving settings.

I also expect an option to have EjectUSB sit in the system tray, ready to be right clicked and to pick ''Eject Drive'' from a little menu, will be ready for the next version.
[ 27 January, 2010 ] • [ William Hedrick ] • [ 12:44:39 ]

Hello Mathew.
I have some suggestions:
After trying to gracefully terminate programs and during the second cycle could you please pop a msgbox for every application that hasn't exited asking the user whether he want's to forcefully close it or not? Also you could make this msgbox automatically take yes as an answer after a fixed amount of time.
Keep it up! :-)
[ 29 January, 2010 ] • [ Tritonio ] • [ 08:10:06 ]

Hello William,

Thank you so much for this nifty little gem! I use it every day.

I would like to put a bid in for Simon & Matthew's request as well. Specifically Firefox Portable. It self-cleans some files from the C:|temp directory, but does so after a few seconds. EjectUSB closes FFP too fast somehow, even with "NoGraceful=0". I'd love to see an .ini setting to the effect of "wait x seconds after program close before ejecting drive".

Keep up the great work!
[ 05 February, 2010 ] • [ Viscouse ] • [ 09:03:32 ]

[ Page 7 of 8 ] • [ << | < | 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 | > | >> ]

Add Comment