STATUS_INVALID_TASK_NAME (0XC0000500) – Task Scheduler name is garbage

When does 0XC0000500 actually show up?

You'll see this error code in three places:

• Task Scheduler GUI – you try to create a task, click OK, and get a popup saying the task name is invalid.
• PowerShell – Register-ScheduledTask throws STATUS_INVALID_TASK_NAME immediately after you hit Enter.
• schtasks.exe – the old command-line tool returns exit code 0xC0000500 when you pass a name with a space or a dot at the start.

I've also seen this in Windows Event Viewer under Microsoft-Windows-TaskScheduler/Operational with Event ID 102 when a third-party app tries to register a task with a trailing newline in its name. That one took me hours to spot.

Why Windows rejects the name – the real root cause

What's actually happening here is that Windows Task Scheduler validates task names against a hard-coded set of rules. The error code 0XC0000500 is the kernel-level response when the name fails that check. It's not a network issue, not a permissions problem – it's purely a string validation failure.

The rules are:

• Task names cannot be empty or blank.
• They cannot be longer than 259 characters (same as a file path limit).
• They cannot contain any of these characters: \ / : * ? " < > | (the same ones Windows bans in filenames).
• They cannot start or end with a space or a dot (period).
• They cannot consist entirely of dots or spaces.
• If you're using XML task registration (common in Group Policy or MDM), the element's version attribute must be present and valid – this one trips people up constantly.

The reason step 3 works is that Task Scheduler internally maps names to a folder path under %WINDIR%\System32\Tasks. A name with a backslash would look like a subfolder, so Windows blocks it outright. Dots at the start mimic hidden files – also blocked.

Fix it – numbered steps

Step 1: Check your task name character by character

Open a command prompt and run this to see if the name itself is the problem:

echo "MyTask" | findstr /R "^[.*\\/:*?\"<>|].*$"

Replace MyTask with your actual task name. If you get any output, that character is the culprit. The banned set is: \ / : * ? " < > |. Yes, the pipe character is banned too – I've seen people paste a pipe from a copied XML attribute.

Step 2: Remove leading/trailing spaces or dots

This is the #1 cause. Your name might look fine in the GUI but have a trailing space from a copy-paste. Open PowerShell and run:

$name = "YourTaskName "
$name.Length
$name.Trim().Length

If the lengths differ, you have whitespace at the ends. Use $name.Trim() when you register the task.

Step 3: If you're using XML, validate it offline

Many people get this error when deploying via GPO or Intune. The XML must have a valid version attribute on the root element. The correct format is:

<Task version="1.4" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">

If you omit the version attribute, Windows silently fails with 0XC0000500. No warning, no log – just the error. Validate your XML against the official schema before importing.

Step 4: Re-register using schtasks (bypasses some GUI bugs)

The Task Scheduler GUI itself has a bug in Windows 10 21H2 and Windows 11 22H2 where it sometimes appends a hidden Unicode character (U+FEFF, the BOM) to the task name. Go around it with schtasks:

schtasks /Create /TN "MyCleanTask" /TR "calc.exe" /SC ONCE /ST 12:00

If that works but the GUI didn't, you've hit the BOM bug. Copy the task name from the command line back into the GUI – the BOM won't transfer.

Step 5: Check the Task Scheduler folder path length

The full path to the task under %WINDIR%\System32\Tasks plus the task name cannot exceed 260 characters. If you've nested the task in a deep folder structure (e.g., CompanyName\Department\SubTeam\Project\TaskName), you'll hit this limit. Move the task to a shallower folder.

What to check if it still fails

• Hidden characters from non-English keyboards. An Arabic or Cyrillic letter that looks like "A" might not be the ASCII 'A'. Open the name in a hex editor or use Format-Hex in PowerShell to spot anything outside 0x20-0x7E.
• Group Policy precedence. If you're using GPO to deploy tasks, a conflicting policy might be overriding your task name with a broken one. Run gpresult /H report.html and check Administrative Templates > Task Scheduler.
• Antivirus interference. Some AV software (looking at you, McAfee) hooks Task Scheduler and injects its own validation that's stricter than Microsoft's. Disable the AV temporarily, recreate the task, then re-enable it. If that works, add an exclusion for the %WINDIR%\System32\Tasks folder.
• Corrupted task store. In rare cases, the %WINDIR%\System32\Tasks directory itself gets corrupted. Run sfc /scannow from an admin command prompt, then DISM /Online /Cleanup-Image /RestoreHealth.

If you're still stuck after all that, your best bet is to create the exact same task on a fresh Windows VM and export its XML. Compare that XML to yours – the difference will be obvious.