NS_I_STOP_DISK (0X400D005B): NetShow Admin Stopped Your Disk

What's Actually Happening Here

That NS_I_STOP_DISK (0X400D005B) code isn't an error—it's an informational event. The full message says "A NetShow administrator at network location %1 stopped disk %2". Windows Media Services (the modern name for NetShow) logged this when someone with admin rights manually stopped a disk, which is basically a content source or a broadcast. If you're seeing this in Event Viewer and your streams just died, the real question is: who stopped it, and why?

This happens more often than you'd think in environments where multiple admins manage streaming servers. Someone might have clicked "Stop" in the WMS Manager while trying to restart a service, or a scheduled task ran a script that stopped the disk. It can also appear after a server reboot if the WMS service didn't restart the disk automatically. The good news: it's recoverable. The bad news: if you don't act, your viewers get a black screen.

Step 1: The 30-Second Fix — Restart the Disk from the WMS Manager

If you just need the stream back up right now, do this:

1. Open Windows Media Services (Start > Administrative Tools > Windows Media Services).
2. In the left tree, expand your server name.
3. Find the specific disk or publishing point that's stopped—it'll have a red square icon.
4. Right-click it and choose Start (or hit the play button in the toolbar).

That's it. The disk resumes and the event won't repeat unless someone stops it again. If the disk won't start, you're looking at a permission or dependency problem—move to Step 2.

Why does this work? Because the event is purely a notification of a manual action. Starting the disk flips the state back, and the WMS service continues as if nothing happened. No reboot needed.

Step 2: The 5-Minute Fix — Check Service Permissions and Dependencies

If the disk stops again right after you start it, or it won't start at all, the cause is usually one of these:

• The Windows Media Services service account lost permissions to the content folder.
• A dependent service (like HTTP SSL or Windows Event Log) is disabled or hung.
• Another admin is deliberately stopping it—check for a management script or a scheduled task.

Here's the quick check:

1. Open Services.msc and find Windows Media Services.
2. Right-click > Properties > Log On tab. Note the account (usually LocalSystem or a domain service account).
3. Navigate to the folder where your media files live. Right-click > Properties > Security tab. Make sure that account has at least Read permission on the folder and files.
4. Also check the Dependencies tab—make sure all listed services are running.

If permissions look fine, look for scripts. On the server, run this in an elevated PowerShell to see any scheduled tasks that reference WMS or the disk name:

Get-ScheduledTask | Where-Object {$_.Actions.Execute -match 'wms|net show|disk'} | Format-List TaskName, State, Actions

If you find a task that's stopping the disk, disable it or change its action to Restart instead of Stop. That's the real fix—you don't want to fight an automated process every five minutes.

Step 3: The 15+ Minute Fix — Deep Dive into Event Logs and Registry

Still seeing the event after verifying permissions? Time to find out who's doing it. The event itself gives you a clue—the %1 placeholder in the message shows the network location of the admin. But that often shows as the server's own IP or hostname, which doesn't help.

Here's the approach I use:

1. Open Event Viewer > Windows Logs > System.
2. Filter by event ID 400D005B (enter the hex in the filter, or search for "NS_I_STOP_DISK").
3. Look at the Event Data in the Details tab. You'll see the disk name and the initiating user, if the logs are verbose enough.
4. If the user shows as SYSTEM, it's a service or script. If it shows a domain account, you've got someone doing it manually.

Also check the WMS-specific logs—they're in Microsoft-Windows-MediaServices/Operational. If that log is disabled, enable it now for future tracking:

wevtutil sl Microsoft-Windows-MediaServices/Operational /e:true

For the registry angle: the disk state is stored under HKLM\Software\Microsoft\Windows Media Services\Server\Publishing Points. Each publishing point has a Enabled DWORD value. A value of 0 means stopped. If something set that to 0, that's your culprit.

reg query "HKLM\SOFTWARE\Microsoft\Windows Media Services\Server\Publishing Points" /s /v Enabled

If you find a publishing point with Enabled = 0, and you want it to start automatically, change it to 1:

reg add "HKLM\SOFTWARE\Microsoft\Windows Media Services\Server\Publishing Points\YourPoint" /v Enabled /t REG_DWORD /d 1 /f

Then restart WMS. But be careful—manually editing the registry can cause more problems if you don't know what you're doing. Only do this if you're confident the disk is supposed to be on.

When to Ignore This Event

Honestly, if your streams are working fine and you just saw this event once, ignore it. It's informational. The WMS service logs this every time an admin stops a disk for maintenance. It's not a sign of a failing disk or a hardware issue. Don't go down a rabbit hole chasing a ghost.

The Real-World Trigger

I've seen this most often in two scenarios: a junior admin rebooting the server and then not restarting the publishing point, or a monitoring script that checks disk usage and accidentally sends a stop command to WMS instead of the disk drive. If you have any custom monitoring scripts, audit them for WMS command calls.

Bottom Line

Start the disk from the WMS Manager. If it stops again, check permissions and scheduled tasks. If it still persists, dig into the event logs and the registry. Nine times out of ten, the 30-second fix is all you need. The rest is about preventing it from happening again—which means either fixing permissions or updating that script that's running amok.