NS_E_PLAYLIST_PARSE_FAILURE (0XC00D14B6): Parsing Fix

1. Malformed Playlist File (Most Common)

What's actually happening here is Windows Media Player (WMP) receives a playlist — typically an M3U or ASX file from an IIS or Apache server — and chokes because the file doesn't follow the spec. The server streams the file, WMP tries to parse it, and bails with 0XC00D14B6.

I've seen this most often on IIS 7.5 through 10 serving M3U playlists that have stray Windows line endings (\r\n) mixed with Unix ones (\n). WMP's parser is picky: it expects each entry to be on its own line, no trailing whitespace, and no BOM (byte order mark) at the start.

Real-world trigger: You set up an IIS server to serve a playlist for an IPTV stream. You edited the M3U in Notepad, saved it as UTF-8 with BOM, and now every client gets this error.

Fix:

1. Open the playlist file in a proper code editor (Notepad++ or VS Code). Avoid Notepad — it adds BOM on UTF-8 saves.
2. Check the first line: #EXTM3U must be present (for M3U). No spaces before it.
3. Strip any BOM: In Notepad++, go to Encoding → Encode in UTF-8 without BOM.
4. Verify each line ends with a simple \n (LF). Convert all \r\n to \n using Replace All.
5. For ASX files, ensure they're valid XML. WMP expects at the root.

After saving, test with a local WMP instance. If it parses locally, the file is good — the problem is on the server side.

2. Wrong MIME Type on the Server

The reason step 1 often fails? The server sends the playlist with the wrong Content-Type header. IIS in particular won't serve unknown file extensions — it returns a 404.3 or just a binary stream that WMP can't interpret.

WMP expects these MIME types:

.m3u  →  audio/x-mpegurl
.m3u8 →  audio/x-mpegurl (or application/vnd.apple.mpegurl for HLS)
.asx  →  video/x-ms-asf
.wpl  →  application/vnd.ms-wpl

Real-world trigger: You host a .m3u playlist on IIS 10 for a radio station. Clients hit the URL directly, but IIS returns application/octet-stream because .m3u isn't in the MIME map. WMP gets confused and fires 0xC00D14B6.

Fix:

1. Open IIS Manager, select your server or site.
2. Double-click MIME Types.
3. Click Add. Enter file extension .m3u and MIME type audio/x-mpegurl. Click OK.
4. Repeat for any other playlist extensions you serve.
5. Run iisreset from an admin command prompt to apply changes.

On Apache or Nginx, add the equivalent to your mime.types file. For Apache, it's typically in /etc/mime.types. For Nginx, add a types block in your server config.

3. Broken UTF-8 Encoding or BOM Issues

This is a sneaky variant of cause #1, but worth its own section because it's so common with Windows-based editors. When WMP sees a UTF-8 BOM (0xEF,0xBB,0xBF) at the start of a playlist file, it often interprets those three bytes as garbage text and fails parsing.

I've hit this on Windows Server 2019 where an admin used PowerShell's Out-File cmdlet, which defaults to UTF-16 LE with BOM. WMP doesn't support UTF-16 for playlists — it expects 8-bit encoding. The result? Parse failure.

Real-world trigger: You run a PowerShell script to auto-generate an M3U playlist and pipe to Out-File playlist.m3u. The file gets saved as UTF-16. Clients get 0xC00D14B6.

Fix:

1. Always save playlist files as UTF-8 without BOM. In PowerShell, use:
   $content | Out-File -FilePath playlist.m3u -Encoding UTF8NoBOM
2. In Python, open with open('playlist.m3u', 'w', encoding='utf-8'). The default is usually fine, but avoid utf-8-sig unless you want the BOM.
3. To check if a file has a BOM, use a hex editor or run file playlist.m3u on Linux. If it says UTF-8 Unicode (with BOM), strip it.
4. On the command line, sed -i '1s/^\xEF\xBB\xBF//' playlist.m3u on Linux removes the BOM in place.

After removing the BOM, the parser sees #EXTM3U as the very first bytes and everything works.

Quick-Reference Summary Table