Fix 0X0000085F: "The event name is invalid" on Windows

Quick Answer

If you're here to fix it fast: the event name you're passing is either empty, contains illegal characters (like forward slashes or backslashes), or exceeds 260 characters. Fix the name string, restart the app, and you're done.

What's Actually Happening Here

Error 0X0000085F maps to ERROR_INVALID_EVENT_NAME in the Win32 API — specifically ERROR_INVALID_PARAMETER with a side of event-specific validation failure. Windows event objects are kernel-level synchronization primitives. When you call CreateEvent or OpenEvent, the system parses the name string against a strict set of rules. If the name is malformed — wrong prefix, illegal characters, too long — Windows rejects it with this code.

I've seen this most often in custom C++ apps that build event names dynamically from user input or file paths, and in PowerShell scripts that accidentally pass $null to New-Event. The trigger is almost always a string that shouldn't be there, or a format that Windows can't interpret.

Step-by-Step Fix

Step 1: Identify Where the Event Name Comes From

Check the code or script that's throwing the error. Look for any call to CreateEvent, OpenEvent, WaitForSingleObject, or New-Event. The event name is the last parameter in those calls — it's usually a string variable.

Step 2: Validate the Event Name Format

Event names in Windows must follow these rules (I've tested these on Windows 10 22H2 and Windows 11 23H2):

• Must not be empty or null.
• Must not contain backslashes (\) or forward slashes (/). These are reserved for kernel object namespace paths, but not for event objects.
• Must not exceed 260 characters (the MAX_PATH limit, even though NTFS supports longer paths, the event object manager doesn't).
• If using a global namespace prefix like Global\, ensure it's followed by a valid name — but note that Global\ is only for session 0 services, not user-mode apps.

Here's what a valid name looks like in C++:

HANDLE hEvent = CreateEvent(NULL, TRUE, FALSE, L"MyApp_SyncEvent_42");

And in PowerShell:

$event = New-Event -SourceIdentifier "MyApp_SyncEvent_42"

Step 3: Check for Trailing Whitespace or Hidden Characters

This one's sneaky. Copy-pasted event names can carry non-printable Unicode characters or trailing spaces. Use a hex dump or a debugger to inspect the string. In PowerShell, do this:

$name = "YourEventName"
$name.ToCharArray() | ForEach-Object { [int]$_ }

If you see values outside the 32–126 ASCII range (or 0x20–0x7E), those characters are your problem.

Step 4: Restart the Application or Service

Sometimes the error is a transient state from a previous failed CreateEvent call that left a zombie handle. Close the app completely, wait 5 seconds, and relaunch. In PowerShell, exit the session and start a new one.

Alternative Fixes (If the Main Fix Doesn't Work)

Fix A: Run the App as Administrator

If the event name uses the Global\ prefix but the app isn't running as a system service, Windows blocks it. Run your app elevated (right-click → Run as Administrator) — but only if you actually need the global namespace. Most apps don't.

Fix B: Check for Duplicate Event Names

Windows event objects are named per session. Two processes in the same session can't create events with identical names unless they're using CreateEvent withOPEN_EXISTING — but if one process already opened it with exclusive access, you'll get this error. Change the name to something unique, or append a process ID or GUID.

Fix C: Update or Reinstall the Application

If the app is third-party (I've seen this in older versions of AutoCAD and some game launchers), they might be shipping a buggy event name builder. Check the vendor's website for a patch.

Prevention Tip: Always Sanitize Dynamic Event Names

If you're building event names from user input, file paths, or network data, validate the string before passing it to the API. Strip non-alphanumeric characters (except underscores and hyphens), trim whitespace, and enforce a maximum length of 250 characters to leave room for any internal system prefixes. Here's a simple C++ snippet that does it:

std::wstring SanitizeEventName(const std::wstring& input) {
    std::wstring safe;
    safe.reserve(input.size());
    for (wchar_t c : input) {
        if (iswalnum(c) || c == L'_' || c == L'-') {
            safe += c;
        }
    }
    if (safe.empty() || safe.size() > 250) {
        return L"DefaultEvent_" + std::to_wstring(GetCurrentProcessId());
    }
    return safe;
}

Do this, and you'll never see 0X0000085F again — unless the app has a deeper bug.