Fix NS_E_INVALID_TIMECODE (0XC00D1BD6) on Windows

You're trying to play a video – maybe an old MP4 you captured from a camcorder or something downloaded from a less-than-reliable source – and Windows Media Player throws that 0XC00D1BD6 error. It stops dead. I've been there. Annoying as hell.

The one-line fix (ffmpeg re-mux)

Open a command prompt or PowerShell in the folder with your broken video. Run this:

ffmpeg -i broken_video.mp4 -c copy -map 0 fixed_video.mp4

If you don't have ffmpeg installed, grab it from ffmpeg.org or use a package manager like Chocolatey (choco install ffmpeg). The binary is all you need – no GUI required.

Replace broken_video.mp4 with your file's name. The output fixed_video.mp4 will play fine. That's it.

Why this works

What's actually happening here is that your video file has a corrupt or incomplete moov atom – that's the index at the beginning of an MP4 container that Media Player reads first. Without a valid moov atom, the player can't map timecodes to frames, so it throws NS_E_INVALID_TIMECODE. The file's raw video and audio data is almost certainly fine; the container structure is just messed up.

The ffmpeg command above does a re-mux. The -c copy flag tells ffmpeg to copy all video and audio streams without re-encoding – that's why it's fast (seconds, not minutes) and lossless. The -map 0 copies every stream. ffmpeg reads the file, constructs a fresh moov atom based on what it actually finds in the data, and writes it out correctly. Windows Media Player (and practically any other player) then reads that new index and happily plays the file.

The reason step 3 works is that ffmpeg doesn't trust the original index at all – it scans the entire file stream-by-stream and rebuilds the metadata from scratch. This is the same approach that fixes “moov atom not found” errors in QuickTime and “corrupt file” warnings in VLC.

Less common variations with the same root cause

Error appears only after seeking (scrubbing the timeline)

If the video plays for a few seconds but errors out when you skip ahead, the moov atom might be partially valid but missing keyframes or duration info. Same fix: re-mux with ffmpeg.

Error pops up in Windows Media Player but the file plays fine in VLC or MPC-HC

VLC is more tolerant of broken headers – it guesses and pushes through. Windows Media Player is stricter. The file still has a problem; the fix is still the same re-mux. Don't assume VLC's ability to play it means the file is healthy.

Multiple files from the same source all show the error

This usually points to a bad recording session or a corrupted download. If you have a batch, run this in a loop:

for %f in (*.mp4) do ffmpeg -i "%f" -c copy -map 0 "fixed_%f"

That'll re-mux every MP4 in the folder. Be careful about disk space – you'll have two copies until you delete the originals.

Error on an AVI or MKV file

Rare, but the same principle applies. The container's index is corrupted. Use ffmpeg -i input.avi -c copy output.avi (or .mkv). For AVI, you can also try avconv with the same flags.

Prevention

This isn't something you can fully prevent, but you can reduce the odds:

Don't interrupt video transfers. If you're copying a video off a camera or a slow USB drive, wait until it finishes. A partial copy often leaves a broken moov atom.
Use a proper download manager for large web videos. Chrome's default downloader can produce truncated files if the connection drops.
Check downloads with ffprobe – it's part of ffmpeg. Run ffprobe file.mp4 and if it spits warnings about “moov atom not found” or “invalid timescale,” re-download or re-mux immediately.
Keep ffmpeg handy. I have it in my PATH on every machine. It's like a Swiss Army knife for video problems – you'll use it for more than just this error.

That's it. Re-mux, play, move on.