You're setting up a publishing point or configuring the Windows Media Encoder, you point it at a log file location, and it spits out NS_E_INVALID_LOG_URL (0XC00D1585). The session won't start. Nothing gets logged. You stare at a path that looks perfectly fine.
I've hit this on everything from Windows Server 2008 R2 boxes running WMS to a small office that tried pointing a media server log at a NAS share. The error is blunt: the URL you gave for the log can't be resolved or written to. That's it. Nine times out of ten it's one of three things.
Cause 1: The log path points to a location that doesn't exist or isn't local
This is the one that gets almost everyone. Windows Media Services and the Encoder want a local file path by default. People type in a UNC path like \\NAS01\logs\stream because that's where they want the logs to live, and the service account doesn't have write access to it — or the share name resolves differently under the service context than it does under your logged-in user.
Had a client last month, a small radio station doing online streaming from a Windows Server 2016 box. They pointed the publishing point log at a mapped drive Z:\logs. It worked when Bob was logged in. The second Bob went home, the service ran under NetworkService, couldn't see the mapped drive, and every stream start threw 0XC00D1585. Classic.
The fix: use a local path. Period. Something like C:\inetpub\logs\wms or D:\StreamLogs. Create the folder first, then point the setting at it.
mkdir C:\StreamLogs
icacls C:\StreamLogs /grant "NETWORK SERVICE:(OI)(CI)M"
icacls C:\StreamLogs /grant "IIS_IUSRS:(OI)(CI)M"
If you absolutely must log to a network share, use the UNC in the service properties and grant the machine account (DOMAIN\SERVERNAME$) write access on the share. Mapped drives are a trap — skip them entirely.
Cause 2: The path is syntactically wrong — missing extension, bad characters, or an http:// prefix where a file path belongs
The field is called a "log URL" and that trips people up. They think it wants http://myserver/logs. It doesn't. It wants a filesystem path, and it wants a filename with an extension.
Things that fail with NS_E_INVALID_LOG_URL every single time:
http://server/logs/— wrong scheme, wrong conceptC:\StreamLogs\— trailing backslash, no filenameC:\StreamLogs\stream— no.logextensionC:\Stream Logs\stream.log— space in the folder name trips some WMS versionsC:\StreamLogs\2024-06-14.log— hyphens are fine, but colons and pipes aren't
Use a plain path with a .log extension and no weird characters. This works:
C:\StreamLogs\wms.logIf you want per-day logs, WMS handles rotation through the Rollover period setting, not by you putting a date in the filename.
Cause 3: The file or folder is locked, read-only, or owned by something that isn't the service account
Less common but nastier to diagnose. The path is fine, the syntax is fine, but the service can't write. Reasons I've seen:
- An old process still has the log file open (a hung wmplayer, a leftover wmserver.exe child process).
- The folder got restored from backup with read-only flags inherited from the archive.
- Someone changed ownership to their own admin account and stripped the service SID.
- Antivirus locked the file mid-write and the encoder never recovered.
Check what account the service is actually running as, then check effective permissions on the folder:
sc qc WMServer
icacls C:\StreamLogs
If write is missing for the service account, grant it explicitly. If the folder is read-only, clear the flag recursively:
attrib -R C:\StreamLogs\*.* /s
And if you suspect a lock, kill the encoder, wait, and try again. In one case the only thing that cleared it was a full reboot because an orphaned process refused to die from Task Manager. Annoying but real.
Note: On Windows Server with UAC and file virtualization, don't test this by writing with Notepad as your admin account and calling it good. The service runs under a different token. Test with PsExec -s -u "NT AUTHORITY\NETWORK SERVICE" cmd.exe and try to create a file in the folder from there. If you can't, the service can't either.
Quick reference
| Symptom | Likely cause | Fix |
|---|---|---|
| Path looks valid but error persists | Service account can't see mapped drive / UNC | Switch to local path, or grant machine account access on the share |
| Path starts with http:// or has no .log extension | Malformed log URL string | Use a local filesystem path ending in .log, e.g. C:\StreamLogs\wms.log |
| Worked yesterday, fails today | File locked, folder read-only, or ownership changed | Kill hanging processes, clear read-only with attrib, re-grant service account write |
| Fails immediately on 64-bit Windows Server | Old WMS component writing to Program Files\Windows Media Services\Logs | Move log dir out of Program Files to a plain folder like D:\StreamLogs |
| Error clears after reboot, comes back later | Antivirus or backup agent locking the log | Exclude the log folder from real-time scanning and VSS snapshots |
The order to check things: is the path local, is it syntactically a file path with .log, can the service account write there. Fix in that order and you'll stop seeing 0XC00D1585. If all three are clean and it still fails, you've got a corrupted WMS configuration node — export your publishing points, uninstall the Windows Media Services role, and reinstall it. That's rare, but I've seen it twice in fifteen years on systems that had been upgraded across two Windows versions.