Fix ERROR_INVALID_TASK_NAME 0X0000060E in Windows

You try to create or import a scheduled task, and Windows slaps you with ERROR_INVALID_TASK_NAME (0X0000060E). Annoying, right? The fix is usually simple, but the cause isn't obvious unless you know where Windows draws the line. Let me walk through it.

The Short Fix

Rename the task. You can't use these characters: \ / : * ? " < > |. Also, the full path (folder + task name) must be under 260 characters. If you're importing from an XML file, check the <RegistrationInfo> section for the <URI> element—it holds the full path.

Here's what to do in Task Scheduler:

Open Task Scheduler (taskschd.msc).
Find the task in the left pane (it might be in a folder like \Microsoft\Windows\).
Right-click it, choose Properties.
On the General tab, change the name to something short, alphanumeric, and with spaces only.
Click OK.

If the task won't open at all, delete it and create a new one with a clean name. To delete, run this in PowerShell as admin:

Unregister-ScheduledTask -TaskName "OldBadName" -Confirm:$false

Why This Happens

What's actually happening here is that Windows Task Scheduler is stricter than you'd expect. The error code 0X0000060E maps to ERROR_INVALID_TASK_NAME in winerror.h. Microsoft's documentation says the name must match [^\\/\:*?"<>|]{1,260}—a regex that bans those eight characters and limits total path length to 260 characters. But the real limit is on the task's registered path, which includes folder hierarchy. A task named MyLongTask in folder \Microsoft\Windows\Defrag\ eats up characters fast.

The reason step 3 works is that renaming shortens the path. If your task name alone is under 260 chars but the folder path pushes it over, you'll still get this error. I've seen this most often when exporting tasks from one machine and importing on another with a longer user folder or locale-specific paths.

Less Common Variations

Sometimes the error pops up in unexpected scenarios:

XML import via schtasks.exe: The /XML parameter uses the <URI> in the XML file. If that URI has illegal characters or exceeds 260 chars, you get 0X0000060E. Fix: edit the XML before importing—just change the <URI> value.
Group Policy deployed tasks: Admins push tasks via GPO with names that include domain paths like \CONTOSO\Software\Updates\. Backslashes in the name? That's a direct hit to the banned list. The fix is to ensure the GPO task name uses only underscores and letters.
Third-party backup software (e.g., Acronis, Veeam): These create tasks with auto-generated names that sometimes include a colon or a path separator. I've seen this with Veeam's backup copy jobs on Windows Server 2019—the colon in copy:Daily triggers the error. Recreate the task manually with a clean name.

Prevention

Stop this from biting you again:

Use only letters, digits, hyphens, underscores, and spaces in task names. That's it.
Keep names under 100 characters—leaves room for deep folders.
When exporting tasks, always sanity-check the XML <URI> after export. Open the file in Notepad, look for <URI>, and verify the path.
In scripts, validate task names before calling Register-ScheduledTask. A simple PowerShell check: if ($TaskName -match '[\\/:*?"<>|]') { throw "Invalid chars in task name" }.

That's it. Rename, re-import, and you're done. The error is blunt, but the fix is always about the name.