Quick answer
Your Windows Media Services server hit the per-stream or per-server bandwidth limit and dropped the request. Raise the limit in the WMS admin console or in the registry under HKLM\SOFTWARE\Microsoft\Windows Media Services\Limits.
What's actually happening here
NS_E_FILE_BANDWIDTH_LIMIT is a Windows Media Services error. The NS_E_ prefix means "Network Services," the old namespace Microsoft used for the media stack that shipped with Windows Server 2003 through 2008 R2 (and technically still lives as a deprecated role on later versions if you force-installed it). The code translates roughly to: "the requested content needs more bandwidth than the server is willing to give it right now."
The reason this trips when it does is straightforward. WMS tracks bandwidth at two levels. First, per publishing point — the limit you set on a specific stream, usually matching the encoded bitrate plus overhead. Second, per server — the global cap that protects your network link from being saturated by the media role. When a client requests a stream and the projected bandwidth would push either counter over the line, WMS rejects the request instead of degrading quality. It doesn't buffer, doesn't downshift, doesn't warn the client. You just get 0xC00D0030.
Real trigger I've seen more than once: someone encodes a new source at 2.5 Mbps, drops it into the same publishing point that was capped at 2 Mbps six months ago, and the stream works fine for the first viewer. Second viewer connects, both streams together now exceed the server cap, and that client gets the error. The first one keeps playing, which makes it look random. It isn't.
Fix it: raise the bandwidth limit
Do this on the server itself. Remote PowerShell against the WMS WMI provider works too, but the GUI is faster for a one-off.
- Open Server Manager, then Roles, then Streaming Media Services, and launch the Windows Media Services console. On 2008 R2 it's a snap-in you open from Administrative Tools.
- Expand the server node on the left. You'll see Publishing Points. Pick the one throwing the error.
- Right-click it, choose Properties, go to the General tab. Find the Limit the bandwidth field. It's probably set to something like
2,000 Kbps. Change it to match the actual encoded bitrate of your source plus roughly 5–10% headroom. - Still in Properties, open the Performance tab. Check Limit the total bandwidth. If it's enabled, that's your server-wide cap. Raise it. On a 1 Gbps NIC you can comfortably set this to 500,000 Kbps, but be honest about your actual link speed.
- Apply, then restart the WMS service from an elevated command prompt:
net stop wmserver
net start wmserverThe reason step 5 matters: publishing point changes are read on service start for some properties, and connection-level counters don't always reset cleanly on a live service. A restart forces a clean slate.
If the GUI route doesn't stick
Group Policy can override your local changes. If someone in your org pushed a WMS template through GPO, your edits revert at next policy refresh. Check gpresult /h gpreport.html and search for "Windows Media." You want to either edit the policy at the source or block inheritance on that OU.
For stubborn cases, set it directly in the registry. This path works on Server 2003 and 2008 R2; later versions dropped the role entirely, so if you're on 2012+ and seeing this code, you're running something that re-implements the NS_E error space — check the vendor's docs, not Microsoft's.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Media Services\Limits]
"FileBandwidthLimit"=dword:00000000
"TotalBandwidthLimit"=dword:00000000Setting both to 0 removes the cap entirely. Don't do this on a box sharing a link with production traffic. 0 means "no limit," and WMS will happily saturate a 1 Gbps NIC if enough clients ask.
Alternative fixes if raising the limit isn't enough
- Re-encode at a lower bitrate. If you can't raise the cap because the network link is genuinely constrained, drop the source from 2.5 Mbps to 1.5 Mbps using Windows Media Encoder or ffmpeg. A 40% reduction is barely visible on most content and buys real headroom.
- Split publishing points. One stream per publishing point, each with its own cap, lets you control which clients get bandwidth when the server is busy. It's more admin work but the load is predictable.
- Disable the per-publishing-point limit only. Leave the server cap in place as a safety net. Right-click the publishing point, Properties, General, uncheck "Limit the bandwidth" — no, don't just set it to a huge number. Uncheck it. The semantics differ when a client requests a stream with an unknown bitrate.
- Check the
MaxFileSizeandMaxBandwidthvalues in the plugin config. Some third-party WMS plugins enforce their own caps that override the server settings. The event viewer entry for the error usually names the plugin. Look in Event Viewer → Windows Logs → Application for sourceWMServer. - Move to IIS Media Services or a modern stack. WMS was deprecated in Server 2008 R2 and removed afterward. If you're still running it in 2025 because a client's ancient set-top boxes need MMS protocol, that's a conversation worth having. HLS via nginx or IIS with a caching layer is not hard to set up and doesn't have this class of problem.
Prevention
Whatever your current cap is, write it down somewhere. The error almost always shows up because someone added a new source file without checking the publishing point's ceiling against the new bitrate. Before you publish anything, run ffprobe -show_format -show_streams yourfile.wmv and look at the bitrate field. Compare it to the publishing point limit. If it's close, raise the limit before you go live, not after a client complains.
Also: monitor the WMS performance counters. Windows Media Services → Publishing Points → Bandwidth shows current usage per point. Set a PerfMon alert at 80% of your cap. You'll know you're about to hit the wall before any client sees 0xC00D0030.
If the error comes back after a reboot, it's almost certainly Group Policy. Check that first before you touch anything else.