NS_E_TOO_MANY_SESS Fix: Windows Media Session Limit

You're seeing NS_E_TOO_MANY_SESS (0XC00D000F) and the server's not accepting new streams. I've hit this more times than I can count. The message says "server session limit exceeded," but nine times out of ten, it's not the hard limit — it's something else.

Before you start tweaking registry values, know this: the default session limit on Windows Media Services (WMS) is 40 concurrent sessions. That's plenty for most internal setups. If you're hitting that, you've got a real problem — or a config bug. Here's how I break it down.

1. Stale Sessions from Clients That Never Disconnect

The most common culprit is clients that don't clean up their socket connections. WMS keeps a session open until the client sends a disconnect or times out. If your clients are behind a NAT or have flaky network, they drop off without proper BYE messages. Those sessions hang around for the default timeout — which on older WMS versions is 20 minutes. 60 clients reconnect a few times and you've hit 40 stuck sessions.

Fix: lower the client timeout so dead sessions get reaped faster. Fire up the WMS admin console, go to Properties, and look for Client Timeout. Set it to 60 seconds instead of the default 1200. That way a dead client gets dropped in a minute, not twenty.

Also check the Connection Limit on the same page. If someone set it to 10 and you've got 12 users, that's your issue. Raise it to 40 or higher if your hardware can handle it. Don't go crazy — each stream eats CPU and bandwidth.

WMS properties: Client Timeout = 60 seconds (default 1200)

If you can't get to the console, use the command line:

netsh wms server properties set clienttimeout 60

That's the quick fix. Test it. If the error still pops, move on.

2. Hard Session Limit Set Too Low

Maybe you actually need more than 40 simultaneous sessions — or someone lowered the max to be "safe." The hard limit is stored in the registry, and it's a DWORD under:

HKLM\SOFTWARE\Microsoft\Windows Media\WMServer\Properties

Look for MaxConcurrentSessions. If it's set to 15, that's your problem. Change it to 100, or 0 for unlimited (not recommended for production, but fine for a test box).

But here's the thing — the hard limit isn't always the bottleneck. I've seen servers with MaxConcurrentSessions set to 1000 and still throw 0XC00D000F because of the per-client limit. That's a different value: MaxConcurrentDisconnects. If that's set low, the server can't process disconnects fast enough, so it thinks it's full.

Set both to reasonable numbers. I usually go with 500 for sessions and 100 for disconnects. Reboot the WMS service afterward — registry changes won't apply until you do.

reg add "HKLM\SOFTWARE\Microsoft\Windows Media\WMServer\Properties" /v MaxConcurrentSessions /t REG_DWORD /d 500 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows Media\WMServer\Properties" /v MaxConcurrentDisconnects /t REG_DWORD /d 100 /f
net stop wmserver && net start wmserver

Watch the event log for WMS Server events. If you see event ID 320, it's definitely the hard limit being hit.

3. Multicast or Broadcast Session Leak

The third cause is less common but drives people mad. It's when you're using multicast or broadcast publishing points, and the sessions don't get cleaned up after the stream ends. This is a known bug in WMS 2008 and 2008 R2, especially with the WMSPRV.DLL module.

You'll know it's this if the error only shows up when you start a new multicast session, not unicast. The session count just keeps climbing even with zero active viewers.

Fix: restart the WMS service to clear the leak, then update the server. That's the band-aid. The real fix is to install the hotfix from Microsoft KB951269 (yes, that old) or move to a current platform. If you're stuck on legacy WMS, schedule a nightly service restart via Task Scheduler.

schtasks /create /tn "WMS Restart" /tr "net stop wmserver & net start wmserver" /sc daily /st 03:00

Also check if you've got multiple publishing points pointing to the same content — that can double-count sessions. Consolidate them.

Quick Reference Table

Start with the timeout fix — it solves 70% of cases. If that doesn't work, check the registry values. And if you're still stuck, look at your multicast setup. You'll have it sorted in ten minutes.