Free Windows tool
Which program is stopping you from ejecting your drive?
Windows refuses a “safely remove” when an application still holds the drive open, and it writes down exactly which application it was. Eject Doctor reads that record, names the culprit, and can ask it to close and then retry the eject.
- Free
- No install
- No admin rights
- Windows PowerShell
Get it
Free, and yours to keep
One zip file. Unzip it anywhere, run the installer for a desktop shortcut, and double-click. There is nothing to buy, no account to make, no licence key, no trial clock and no telemetry.
- Download
eject-doctor.zip— 56,230 bytes, sha25661e805d691b7e7efbea9b7bbf33e82c1eaa4d2b66a8bb73a0864514c5c982020.- Inside
EjectDoctor.ps1(the window, the console report and the self test),EjectDoctor.Core.psm1(all the logic, headless and testable),Install-EjectDoctor.ps1(icon and desktop shortcut),EjectDoctor.ico, aREADME.mdthat states the limits below, and a screenshot.- Needs
- Windows, and the Windows PowerShell that already ships with it (5.1). No admin rights, no installer, no runtime to download, no network connection. To re-point the shortcut after moving the folder, re-run
Install-EjectDoctor.ps1. - Safe to try
- Closing a blocker is graceful only: the app sends
WM_CLOSEto the blocker’s window and waits. It never force-kills, because killing a vault or a database mid-write is how you damage the thing you were trying to protect.
The download is served from this page’s own directory. Nothing here loads a font, a script or an image from anywhere else.
How it works
It asks Windows instead of guessing
Every other tool of this kind hunts for processes that look like they might be holding a drive. This one goes and reads the accusation.
It reads the veto record
When an eject is refused, the PnP manager writes Kernel-PnP event 225 to the System log, naming the application, its process id, its command line and the device instance that was vetoed. Eject Doctor reads the structured event data rather than the English message text, so it keeps working on a non-English Windows.
It identifies drives by device, not by letter
Drive letters are recycled every time you swap a disk. The app matches on the USB serial token, which appears both in the drive’s storage path and in the veto record — so an old record for a different disk that once sat on D: is never blamed on whatever is plugged into D: today.
It ejects the way the tray does
The eject uses CM_Request_Device_Eject — the same call the notification-area Safely Remove Hardware icon makes. External drives often present themselves to Windows as Fixed disks, in which case Explorer offers no right-click Eject at all, so the tray path is the one that has to work.
It closes the blocker politely
Close blocker & eject sends a normal close request to the blocking app and waits. If that app asks you to confirm — a vault asking whether to lock and quit, say — you confirm it and the eject retries. Nothing is killed from underneath you.
The window
Five controls, and a status card
- External drive
- Pick which attached drive to look at.
- Refresh
- Re-scan the drives and re-read the block history.
- Attempt eject
- Ask Windows to eject, and report what actually happened.
- Close blocker & eject
- Politely close the blocking app, then retry the eject.
- Watch (5 s)
- Keep an eye on the log and tell you the moment an eject is refused.
There is also a console mode, for scripts and for machines with no desktop: powershell -File .\EjectDoctor.ps1 -Console, with -Drive D:, -AttemptEject and -CloseBlocker available on it.
Status
What has been measured, and what has not
- All 25 self-test checks pass. The suite runs with no side effects and takes about half a minute:
powershell -File .\EjectDoctor.ps1 -SelfTest. Several of those checks fail on purpose if the logic regresses. - The diagnosis path is verified end to end on a real machine. On the machine this was written on, the tool found the external disk, read ten recorded vetoes for it, and named
Cryptomator.exe— including its process id and the command line holding the vault open — matching it by USB serial. - The checks that matter are the negative ones. The suite asserts that a veto for a different disk on the same drive letter does not match, and that no historical record is attributed to the current drive on a letter coincidence alone. A tool that blames the wrong program is worse than one that says nothing.
- The “ejected successfully” path has not been watched happen with a live drive. The request → veto → identify → report path is verified, and the unit that decides the drive is gone is checked separately, but doing the real thing would unmount whatever drive is connected, so it has deliberately not been done. Treat the first eject you run as the test.
Plainly
What this is not
- It is not a drive-repair tool and not a data-recovery tool. It tells you who is holding a drive and asks them to let go; it does not touch the disk itself.
- It is not a background service and not a driver. It does nothing at all until you open it, and it has no network code.
- It only offers drives that have a drive letter. A USB disk mounted without one still has to be ejected from the tray.
- It cannot report a block that Windows never recorded: the veto record only exists because an eject was actually refused. If nothing has ever been refused, there is nothing to show — press Attempt eject to produce a fresh verdict.
- An unreadable USB identity falls back to the drive letter, and those weaker matches are labelled
drive-letterin the text report so you can see the evidence is thin. - History comes from the System event log, so it reaches back only as far as that log’s retention window.
Take it, and tell us what it got wrong
It is free and it is small, and the most useful thing you can send back is a case where it named the wrong program — or refused to name anything when Windows had plainly recorded a block. That is the failure this tool exists to not have.