Fix 0X00000089: SUBST drive not found on unmount

Quick answer

If you're seeing 0X00000089, it means something (a script, your startup folder, or a scheduled task) tried to run SUBST X: /D on a drive letter that isn't currently substituted. The fix is to check what's launching that removal command and either stop it or wrap it in a test.

What's actually happening here

Windows lets you map a folder to a drive letter using the SUBST command. It's handy for legacy software or quick access. The problem is that SUBST mappings aren't persistent across reboots by design. So people create scripts or registry entries to re-create them at startup. But if that same script also tries to remove the mapping later (maybe at shutdown or logoff), and the mapping was already wiped by something else, you get error 0X00000089.

I've seen this most often on machines where someone set up a persistent drive via REG ADD HKCU\Software\Microsoft\Windows\CurrentVersion\Run with a SUBST command, and then later added a removal call in the same script or in a logoff script. After a manual unmount or a crash, the removal half kicks off and the drive letter is already gone — boom, error.

Step-by-step fix

Identify the culprit
Check Task Scheduler (taskschd.msc) for any tasks that run at logoff or system shutdown. Look for actions containing SUBST or net use. Also open your startup folder (shell:startup) and look for .bat or .vbs files with SUBST commands. The most common offender is a .bat file that does both creation and removal.
Find the removal command
Open that script or task action in Notepad. Search for /D — that's the delete switch for SUBST. Example line: SUBST X: /D. This is what's failing.
Fix the script
The real fix is to check if the drive exists before trying to delete it. Replace the bare SUBST X: /D with this:
```
@echo off
if exist X:\ (SUBST X: /D) else (echo Drive X: not mapped, skipping.)
```
This tests whether the drive letter is currently active. If it's not, the script does nothing. No error.
Or stop the removal entirely
Ask yourself: do you actually need to remove the mapping at shutdown? If the drive mapping was created at startup, Windows itself will clean it up on restart. You might not need the removal step at all. Comment it out with REM.
Test it
Run the fixed script manually. Then log off and log back in. No more 0X00000089.

Alternative fixes if the main one doesn't work

Check for leftover registry entries

Some third-party tools (like old virtual CD-ROM drivers) write SUBST-like entries into HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\DOS Devices. If a persistent drive letter entry is there, and Windows tries to clean it up at boot, you can get this error. Use regedit to browse to that key. Look for any value named X: (substitute your drive letter). Delete it. Back up the key first. Reboot.

Check for a scheduled task that runs on event 6005

Event ID 6005 is “The Event log service was started,” which happens at boot. Some tasks trigger on this event to re-map drives. If that same task also runs a cleanup on shutdown, you get the race condition. Open Task Scheduler, find the task, and change its trigger from “At logon” to “At startup” instead — this ensures the task only runs once, not at both startup and shutdown.

Use a permanent subst alternative

If you're tired of scripting SUBST, there's a cleaner method: create a junction point or a symbolic link. These persist across reboots without any script. Open an admin command prompt and run:

mklink /J C:\MyProject D:\Actual\Path\To\Project

This creates a folder at C:\MyProject that points to the real path. No drive letter needed, no error possible. The trade-off is it's a folder, not a drive letter, so some old software that insists on a drive letter won't work.

Prevention tip

Never include both a SUBST creation and a SUBST /D removal in the same login/logoff script pair. Instead, only create the mapping at startup and let Windows handle the cleanup. If you must remove it at shutdown, always wrap the removal in an existence check — if exist X:\ SUBST X: /D. That single guard clause saves you from this error on every reboot.