NS_I_KILL_CONNECTION (0X400D005E): NetShow Admin Aborted Connection

What NS_I_KILL_CONNECTION Actually Means

You're looking at event ID 0X400D005E in your Windows Media Services logs, and the message reads "A NetShow administrator at network location %1 aborted obsolete connection %2 from the system." That sounds like someone or something is deliberately killing streams. But what's actually happening here is much less dramatic.

This informational event fires when Windows Media Services (WMS) terminates an older client connection to make room for a new connection from the same client identifier. The system uses the term "obsolete" because it assumes the old session is stale — the client likely reconnected after a network blip or the player restarted. This isn't an error. It's a status code indicating the server cleaned up a duplicate session.

The code itself is NS_I_KILL_CONNECTION, and the numeric value 0X400D005E lives in the "informational" range. You'll see it in the Windows Media Services event log under WMS source, not in the System or Application logs. If you're running Windows Server 2008 R2 or later with the Streaming Media Services role, this pops up regularly under normal load.

Most Common Cause: Normal Session Reuse

The most common trigger is a client reconnecting to the same stream within a short window. Say a user watching a live multicast stream on Windows Media Player clicks Stop, then Play again. The player sends a new connection request with the same client ID that the server still thinks is active. WMS sees the new request, kills the old session, and logs 0X400D005E.

The fix is nothing. Really. Don't go chasing registry keys or firewall rules. If the stream works fine for viewers, this event is harmless noise. The only reason to touch anything is if you're drowning in these events and they're filling your logs, making it hard to spot actual errors.

To reduce log noise, you can adjust the WMS logging level. Open the WMS management console, go to your publishing point properties, and under the Logging tab, uncheck "Informational events." This keeps warnings and errors visible while suppressing status messages like NS_I_KILL_CONNECTION.

# PowerShell command to disable informational logging for a specific publishing point
$pp = Get-WMSPublishingPoint -Name "YourStreamName"
$pp.Logging.LogInformational = $false
$pp.Put()

This change takes effect immediately. Test by restarting a client stream — you'll see no more informational events in the log.

Second Most Common Cause: Stale Client Sessions After Network Failure

When a client's network drops momentarily — say a WiFi disconnection of 5-10 seconds — the server doesn't immediately mark that session as dead. WMS uses a keep-alive timeout, defaulting to 60 seconds. If the client reconnects within that window and the server hasn't cleaned up the old session, you get the same 0X400D005E event.

This is especially common with mobile clients on unreliable connections. The player reconnects faster than the server's timeout, so the server kills the supposed "duplicate" session.

The real fix here is reducing the keep-alive timeout so stale sessions get cleaned up faster, preventing these events from occurring in the first place. But be careful — setting it too low (under 10 seconds) can cause unnecessary disconnections on slightly laggy networks.

Navigate to the WMS server properties in the console. Under the Publishing Points tab, find "Client connection timeout." The default is 60 seconds. Drop it to 20-30 seconds for most environments. This tells the server: if we don't hear from the client in 20 seconds, consider the session dead. When the client reconnects after a brief blip, it creates a brand new session instead of triggering a duplicate-kill.

# PowerShell to adjust client connection timeout (in seconds)
$server = Get-WMSServer
$server.PublishingPoints.ClientConnectionTimeout = 30
$server.Put()

Test with a simulated network drop. Kill WiFi on a client, wait 10 seconds, reconnect. Without this change, you'd see 0X400D005E. After the change, the old session expires cleanly before the new one arrives.

Third Most Common Cause: Third-Party Streaming Clients with Fixed Client IDs

Some non-Microsoft streaming clients (like VLC or custom embedded players) don't generate unique session IDs per connection. They reuse the same identifier every time they connect. WMS interprets this as the same client coming back, and it dutifully kills the old connection for the new one.

This isn't a bug in WMS — it's following the protocol spec. But it can flood your event log if you have many such clients connecting repeatedly (e.g., digital signage players that reconnect on a schedule).

The fix depends on what you control. If you manage the client code, change it so each connection uses a unique client ID — typically a GUID or a timestamped hash. With VLC, you can't change this behavior directly; it's baked into how VLC generates RTSP requests.

If you can't modify the client, your only practical option is to suppress informational logging as described in the first fix. Alternatively, you can filter the WMS event log view to exclude event ID 0X400D005E using Windows Event Viewer's custom views or PowerShell:

# Create a custom event log query that excludes 0X400D005E
$query = @"

  
    *[System[(EventID != 1073741918)]]
  

"@
Get-WinEvent -FilterXml $query

Note: EventID 1073741918 is the decimal equivalent of 0X400D005E. This filter hides the informational noise while keeping everything else visible.

Quick-Reference Summary

Don't waste time trying to "fix" 0X400D005E as if it were a real error. It's a signpost, not a problem. Only act when the frequency bothers you or masks actual failures.