Fix ERROR_DIRECTORY 0x0000010B: Invalid Directory Name

You're trying to run something — a scheduled task, a service, a robocopy job, maybe just a plain old cd in Command Prompt — and Windows slaps you with ERROR_DIRECTORY (0x0000010B), also known as error 267. The message reads "The directory name is invalid."

Translation: the path you handed Windows doesn't resolve to a real folder. Either the drive isn't there, the folder moved, or the syntax is off by one character. That's it. There's no driver corruption, no registry gremlin, no need to reinstall anything. It's a path problem 95% of the time.

The most common real-world trigger I see: a mapped network drive (say Z:\) that worked fine yesterday, but today the user logged in before the network came up, so Z: doesn't exist yet. Anything pointing at it — a batch file, a scheduled task, a shortcut — immediately throws 0x0000010B. Same thing happens with subst drives after a reboot.

Work through the sections below in order. Stop as soon as it's fixed.

Fix 1: The 30-Second Check

Before you touch anything, verify the path actually exists right now.

1. Press Win + R, type the folder path from your error, and hit Enter.
2. If Explorer opens the folder, the path is fine and you can skip to Fix 2.
3. If Explorer throws its own error or opens a different location, the path is dead. That's your answer.

Now check for the two syntax landmines that cause most of these errors:

• Trailing backslash on a root drive. C:\ is fine. C:\\ is not. Neither is \\server\share\ in some APIs.
• Quotes in the wrong place. If your path has spaces, the quote needs to wrap the whole thing: "C:\Program Files\My App". Not C:\"Program Files"\My App.

After correcting the syntax, run the command again. You should see it start working immediately — no reboot, no re-login.

Fix 2: The 5-Minute Fix (Missing Drive Letter)

If the path looks clean but the drive itself is missing, this is your problem. Open Command Prompt and check what drives Windows actually sees:

wmic logicaldisk get name,description,providername

Look for the drive letter in your failing path. If it's a mapped network drive and it's not listed, that's your bug. Reconnect it:

net use Z: \\fileserver\share /persistent:yes

You should see "The command completed successfully." Now retry your original command. It should run without 0x0000010B.

If the drive is a subst drive (a fake letter pointing to a real folder), check with:

subst

If your letter isn't in the list, recreate it:

subst Z: C:\Projects\Build

Here's the catch nobody tells you: subst drives vanish on every reboot. If a scheduled task depends on one, it'll fail forever until you either recreate the subst at startup or stop using subst entirely. The real fix is to change the task to point at the real path.

Fix 3: The 15-Minute Fix (Tasks, Services, and UNC Paths)

If the path exists when you're logged in but the error only shows up from a scheduled task or a Windows service, you've hit a different animal. Services and scheduled tasks often run as SYSTEM or a service account, and those accounts don't see your mapped drives. Mapped drives are per-user, per-session. SYSTEM has no Z:.

Two ways to fix this:

Option A: Switch to a UNC path

Instead of Z:\Backups, use \\fileserver\Backups. The service account needs permission on the share, but this is the clean answer. It works regardless of who's logged in.

Option B: Give the service account its own mapping

You can add a mapping under the service account's context, but honestly, this is fragile. UNC is better. If you must use a drive letter, set it up as a startup script that runs as the service account.

For scheduled tasks, open Task Scheduler, find the task, and check the Start in (optional) field on the Actions tab. I've seen dozens of tasks fail with 0x0000010B because the "Start in" folder was deleted six months ago and nobody noticed. Clear it, or point it at a folder that exists.

Quick sanity test: run the task manually by right-clicking and choosing Run. If it succeeds manually but fails on schedule, it's a permissions or path-visibility issue, not a syntax problem.

Fix 4: Long Paths and Special Characters

Two edge cases that trip people up:

That trailing space one is nasty. A folder named Data (with a space) looks identical to Data in Explorer. Your batch script tries to open C:\Data, Windows says the directory name is invalid, and you stare at the screen for twenty minutes. Run dir /x in the parent folder to reveal the truth:

dir /x C:\

The 8.3 short name column will show you what's really there.

When It's None of the Above

If you've checked the path, the drive, the permissions, and the syntax, and it still fails — open Event Viewer and look under Windows Logs > Application right after the failure. The process name there tells you which component is really throwing the error, which is often not the one you thought. Nine times out of ten it's still a path. The tenth time, it's a permissions issue on the parent folder that's masking itself as an invalid directory.

Check that the account running the command has List folder contents on every folder in the chain, not just the target. A missing permission on C:\Projects will make C:\Projects\Build\Output look invalid, even though the Output folder itself is fine.