Fix NS_E_PAGING_ERROR 0xC00D0062 on Windows Media Server

That 0xC00D0062 paging error kills your Windows Media stream dead. Here's the real fix: clear the cache folder and disable the paging file problem on the server.

You're staring at a dead stream and a cryptic hex code, and it's probably 2 AM and a client is breathing down your neck about a broadcast that won't start. Let's fix it.

The Actual Fix

NS_E_PAGING_ERROR means the Windows Media Content Server tried to pull a block of the media file into its internal cache and failed. Nine times out of ten, the culprit is a corrupted cache directory or a disk that can't keep up. Here's what to do, in order.

1. Stop the service and nuke the cache

Open an elevated command prompt. Then:

net stop wmserver
rd /s /q "C:\WMPCache"
rd /s /q "C:\Windows\System32\LogFiles\WMS"
net start wmserver

If the folder doesn't exist under those exact paths, check your WMS config for a custom cache location. You can find it in the MMC snap-in under Server Properties → Cache. Delete whatever's in that folder and restart the service.

2. Check your paging file on the content drive

This is the one that trips people up. If your content drive is also where Windows is managing the paging file, and that drive is nearly full, the Content Server can literally run out of room to page a block. The error is named for paging for a reason.

On the server, right-click This PC → Properties → Advanced system settings → Performance Settings → Advanced → Change. Make sure the paging file isn't sitting on the same physical disk as your media content. Move it to a separate spindle.

3. Verify disk health

Run a quick SMART check. I had a client in Phoenix whose stream would die every 40 minutes like clockwork — turned out the media drive had reallocated sectors that only failed under sustained read load. A cheap SSD swap fixed what three weeks of software troubleshooting couldn't.

wmic diskdrive get model,status,size
chkdsk D: /f

4. Restart the publishing point

After the cache is clean and disk is healthy, restart the specific publishing point from the WMS MMC. Don't just restart the whole service — the publishing point state is what's actually holding the stale block reference.

Why This Fixes It

Windows Media Services pages media blocks on demand. It reads ahead, caches blocks in memory and on disk, and serves them to clients. When the cache directory has a stale or corrupt block index, or when the disk underneath can't fulfill the read, the paging operation returns 0xC00D0062 and the whole stream collapses.

Clearing the cache removes the corrupt index. Moving the page file off the content drive eliminates contention for I/O. And restarting the publishing point forces WMS to rebuild its block map from scratch instead of trusting whatever it had cached before.

Skip the “reinstall Windows Media Services” advice you'll find on old TechNet threads. Unless the binaries are actually corrupted — which is rare — reinstalling just wastes four hours and breaks your publishing points.

Less Common Variations

If you're running this inside a VM

VMware and Hyper-V both have storage drivers that throttle I/O under load. If your content server is virtualized, check your storage queue depth. On Hyper-V, this is the MaximumQueueDepth on the virtual disk. Bump it up. On VMware, check the SCSI controller type — LSI Logic SAS handles concurrent reads much better than the default LSI Logic Parallel for media workloads.

If it only fails with certain files

That points to a bad file, not a server problem. Re-encode the source. WMS chokes on files with malformed ASF headers even when VLC plays them fine. Use Windows Media Encoder or ffmpeg to remux:

ffmpeg -i broken.wmv -c copy -f asf fixed.wmv

If it happens under high concurrent load

You're hitting the per-publishing-point connection limit. Registry path:

HKLM\SOFTWARE\Microsoft\Windows Media Services\Service\PublishingPoints\<your_point>

Look at MaxConnections. Default is 50 for most editions. Raise it, but only after you've confirmed the disk can handle the throughput — otherwise you're just moving the failure from paging to bandwidth.

Prevention

Put your WMS cache on a dedicated disk, never the OS drive.
Keep at least 15% free space on the content drive at all times.
Monitor SMART attributes weekly. A dying drive under streaming load is the number one cause of 0xC00D0062 I see in the field.
Don't share the content drive with SQL logs. Ever. I don't care how small the deployment is.
If you're still on Windows Media Services 2008 on Server 2008 R2, start planning your migration. IIS Smooth Streaming or a commercial CDN will save you from this class of error entirely.

Most 0xC00D0062 hits come down to disk. Fix the disk, clear the cache, and this error stops showing up.