NetShow Admin Killed Your Session: Fix 0X400D005D

This Error Means an Admin Hit the Kill Switch

You're streaming, everything's fine, then boom—session dropped. The error code 0X400D005D with message NS_I_KILL_USERSESSION tells you exactly what happened: a NetShow administrator (someone with server access) manually ended your session. This isn't a network glitch or a corrupted file. It's a person (or a script) telling the server to boot you.

The Real Fix: Check the Server Logs

Before you do anything else, understand this: you can't fix this from your client machine. The fix lives on the server running Windows Media Services (WMS). If you're an end user, forward this article to your IT admin. If you're the admin, here's what to do.

1. Open the Windows Media Services management console.
   On the server, go to Start > Administrative Tools > Windows Media Services. If you don't see it, the role isn't installed—install it via Server Manager under Streaming Media Services.
2. Find the publishing point or multicast station.
   In the left pane, expand the server name, then click Publishing Points (for unicast) or Multicast Stations (for multicast). The session that got killed is associated with one of these.
3. Open the properties and look at the logging tab.
   Right-click the publishing point and choose Properties. Click the Logging tab. You'll see a checkbox labeled Enable logging. Make sure it's checked—if it isn't, you won't see who killed the session.
4. Check the WMS log files.
   By default, logs are in C:\WINDOWS\System32\Windows Media\Logs (on older Server 2003/2008) or C:\ProgramData\Microsoft\Windows Media\Logs (Server 2008 R2 and newer). Open the most recent log file (they're .log or .csv). Look for an entry with NS_I_KILL_USERSESSION and note the admin-name field.
5. Identify who terminated the session.
   The log entry shows admin-name and user-session-id. If it says SYSTEM or LOCAL SERVICE, it was a script, a scheduled task, or a plugin. If it shows a domain account, that's the person who clicked "Terminate".
6. Ask the admin why they did it.
   Talk to whoever's name appears. Common reasons: they were testing, they saw you as a rogue connection, or they misclicked. If it's a script, check the task scheduler or any custom management tools.

After you identify the cause, you can decide the next step. If it was accidental, you're done. If it's a recurring script, you'll need to disable or modify it.

Why This Worked

The error isn't a code-level bug. It's a deliberate action. The WMS server logs the exact event and the account that triggered it. By reading those logs, you move from guessing to knowing. Once you know the source, you address the human or automated process, not the server settings.

Less Common Variations of the Same Issue

Sometimes you'll see NS_I_KILL_USERSESSION paired with a different %1 and %2 in the event viewer. The %1 is the network location (IP or server name), and %2 is the session ID. If the %1 shows an unexpected server (like a different machine), that means the session was terminated by a remote admin console—same fix applies, just check the logs on that remote server.

Another variation: your session gets killed repeatedly, every few minutes. This usually means a scheduled script is running that checks for idle sessions or certain client IPs and boots them. Look in Task Scheduler on the WMS server for any task that calls net stop WMServer or uses the WMSAdmin command line tool.

Common script trigger:
WMSAdmin.exe /Kill /SessionID:12345

This command appears in scheduled tasks or batch files.

If you're on a managed network (like a school or corporate LAN), the admin might have a custom application that monitors streaming and kills sessions based on bandwidth limits. That's harder to trace—you'll need the app's own logs.

Prevention: Stop This From Happening Again

Since the server admin controls the kill switch, prevention is about governance, not technical tweaks. Here's what I tell the teams I train:

• Enable detailed WMS logging and keep logs for at least 30 days. Without logs, you're blind.
• Restrict who can kill sessions. In WMS, go to Authorization under the server's properties. Limit the Administrator group to only specific domain accounts, not all domain admins.
• If you're a client, ask your admin to whitelist your IP or user account so automated scripts skip you. Most admins will do this if you explain the error.
• For multicast streams, set a longer client timeout in the multicast station properties. Default is 5 minutes idle—bump it to 30 if you get killed during pauses.
• Monitor the WMS event log (Event ID 400) for NS_I_KILL_USERSESSION and set up an alert. When it happens, you'll know immediately who did it.

One last opinion: don't try to kill the kill switch by stopping the WMS service or removing admin permissions. That'll break streaming for everyone. The goal isn't to disable management—it's to make sure only the right people terminate sessions for the right reasons.

If the error keeps happening after you've checked logs and talked to the admin, you're likely dealing with a rogue script or a misconfigured third-party management tool. Pull the event log for the last 24 hours and look for repeating NS_I_KILL_USERSESSION entries with the same admin-name. That's your smoking gun.