Fix NS_E_DATA_UNIT_EXTENSION_TOO_LARGE 0xC00D0BD9

Quick Answer for Advanced Users

Run: ffmpeg -i input.wmv -map 0 -c copy -metadata:s:0 extension_data= output.wmv to strip oversized ASF Extension Data Object.

What's Actually Happening Here

You're trying to play a WMV or ASF file in Windows Media Player or a WMP-based app and you get 0xC00D0BD9 — the NS_E_DATA_UNIT_EXTENSION_TOO_LARGE error. The exact message says "The Data Unit Extension data was too large to be used."

What's happening under the hood is this: the ASF container format allows each data packet to carry optional extension data (things like timestamps, DRM flags, or custom metadata). The spec says each extension must fit in a 16-bit unsigned integer — that's a max of 65,535 bytes. Some encoders, particularly older ones or buggy third-party tools, write an extension object larger than that. WMP reads the header, sees the size field, and rejects the whole file because it can't allocate that much memory for one extension.

I've seen this most often with files transcoded by old versions of Windows Movie Maker or downloaded from certain streaming sites that inject oversized metadata. It's not a corruption in the video/audio data itself — the file plays fine in VLC or MPC-HC because those players don't enforce the strict ASF spec.

Fix Steps

Install ffmpeg if you don't have it. Grab the latest static build from ffmpeg.org and put it in your PATH. You don't need to compile — just download the Windows build.
Identify the offending file. Right-click the file and check Properties > Details. If the file is under 2GB, it's likely a WMV or ASF. If it's an MP4, you've got a different problem — this error only fires for ASF-based containers.
Run this ffmpeg command (replace input.wmv with your filename):
```
ffmpeg -i input.wmv -map 0 -c copy -bsf:v remove_extradata output.wmv
```
The -bsf:v remove_extradata bitstream filter strips oversized extension data from video packets. If that fails because ffmpeg can't parse the input, try the more aggressive approach:
```
ffmpeg -i input.wmv -map 0 -c copy -fflags +genpts -avoid_negative_ts make_zero output.wmv
```
This re-muxes the file without the extension data. The -fflags +genpts flag regenerates presentation timestamps, which sometimes resets the broken extension size field.
Re-encode as a last resort. If the file still won't play, the header itself is corrupt and copy won't cut it. Use:
```
ffmpeg -i input.wmv -c:v libx264 -preset fast -crf 23 -c:a aac -b:a 128k output.mp4
```
This converts to MP4. You lose the original ASF container but gain a file that works everywhere. The -preset fast keeps encoding time reasonable — don't use ultrafast, it bloats the file size.

Alternative Fixes If ffmpeg Isn't an Option

Use Windows Media Encoder (the old 9 Series version) to re-encode the file. It's abandonware but still available on Microsoft's site. Import the broken file and export to WMV. This strips the oversized extension during re-encoding.
Play in VLC and use its Convert/Save feature to wrap the stream into a new container. Go to Media > Convert/Save, add the file, choose "Video - H.264 + MP3 (MP4)" profile, and save. VLC's ASF demuxer is more lenient than WMP's.
Manually edit the binary header with a hex editor if you know the ASF spec. Locate the Extended Content Description Object (GUID: D2D0A440-E307-11D2-97F0-00A0C95EA850) and check the 16-bit size field at offset 24. If it exceeds 0xFFFF, change it to 0xFFFF. This is risky — one wrong byte and the file is dead — but I've done it in a pinch.

Prevention Tip

Don't use Windows Movie Maker or old third-party ASF encoders that predate the 2010s. Stick with ffmpeg with the -movflags +faststart for MP4 or -asf for WMV output. If you must keep WMV, always test playback in WMP after encoding — VLC will lie and tell you everything is fine.

One more thing: if you're streaming ASF files over HTTP, make sure your server doesn't append custom headers that bloat the extension data. I've seen IIS with custom logging modules accidentally inject oversized metadata into the stream header, causing this exact error on the client side.