0XC00D0061

NS_E_ALLOCATE_FILE_FAIL (0XC00D0061) Fix: Server Can't Allocate Block File

Server & Cloud Intermediate 👁 1 views 📅 May 28, 2026

Windows Media server chokes when it can't create a block file—usually a disk space, permissions, or path issue. Here's how to fix it fast.

1. The Disk Is Full (This Is Almost Always It)

I know this error is infuriating—especially when you're mid-stream. But 9 times out of 10, the NetShow Video Server fires NS_E_ALLOCATE_FILE_FAIL (0XC00D0061) because the drive where it's trying to write the .tmp or .wms block file has zero space left. The server needs room to create temporary block files—sometimes hundreds of MB—especially during live streams or high-bitrate on-demand playback.

Here's the quick check:

  1. Open File Explorer and check the drive where Windows Media Services is installed. Typically that's C:\, but it could be a dedicated data drive.
  2. Right-click the drive and go to Properties. If free space is under 500 MB, that's your culprit.
  3. Open Task Manager > Performance tab and confirm disk usage isn't pegged at 100%.

The fix is obvious but often overlooked: free up space. Delete old logs from C:\WINDOWS\system32\LogFiles\WMS. Move archived streams off the system drive. Run cleanmgr (the built-in Disk Cleanup tool) and check Temporary files. If you're running Windows Server 2019 or 2022, also check the WinSxS folder—it's a space hog.

If you can't free enough space, move your content directory to a bigger volume. In the Windows Media Services console, right-click your publishing point, go to Properties, and change the Content directory path.

2. NTFS Permissions Blocking Temporary File Creation

This tripped me up the first time too. Even with plenty of disk space, the service account running Windows Media Services might not have Write permission on the directory where block files are created. The error pops up when the server tries to allocate a %1 block file named %2 (the exact filenames vary by scenario) and gets slapped down by NTFS ACLs.

Check which account runs the service:

  1. Open Services.msc.
  2. Find Windows Media Services (or NetShow Video Server on older builds).
  3. Right-click > Properties > Log On tab. Note the account—usually NT AUTHORITY\NETWORK SERVICE or NT AUTHORITY\LOCAL SYSTEM.
  4. Navigate to the content directory (like C:\WMSContent or whatever you set). Right-click it > Properties > Security tab.
  5. Click Edit. Add the service account if it's not there. Grant Modify and Write permissions. If you're paranoid, start with Write only.
  6. Click OK and restart the service from the Services console.

I've seen this happen when admins move the content folder to a network share (which you absolutely shouldn't do—stick with local drives) and the share permissions don't match. Keep everything local and NTFS-only.

3. Corrupted or Misconfigured Registry Path for Block Allocation

Less common but real: the server looks for a registry key that tells it where to create block files, and that key is missing or points to an invalid path. This usually happens after a failed update or manual registry editing gone wrong.

The key in question lives under:

HKLM\SOFTWARE\Microsoft\Windows Media\Server\Properties

Look for a value named BlockFileTempPath. If it's not there, the server defaults to %WINDIR%\Temp. That's fine, but if that drive is full (see cause #1) or the service account can't write there (see cause #2), you'll get the same error. If the value exists and points to something wild like X:\nonexistent, you've found the problem.

To fix it:

  1. Open Regedit as Administrator.
  2. Navigate to HKLM\SOFTWARE\Microsoft\Windows Media\Server\Properties.
  3. If BlockFileTempPath is missing, create a new String Value with that exact name. Set it to a valid, empty folder on a local drive with plenty of space—like C:\WMSContent\Temp.
  4. Make sure that folder exists and has the service account's Write permission.
  5. Close Regedit and restart Windows Media Services.

Double-check the service account's identity from step 1 under cause #2. If you changed it recently, that can also invalidate the temp path permissions.

Pro tip from my help desk days: If you're still stuck, use Process Monitor (ProcMon) from Sysinternals. Filter by the WMS service PID and look for ACCESS DENIED or NAME NOT FOUND events on .tmp or .wms file operations. It'll show you exactly which path failed and why.

Quick-Reference Summary Table

Cause Symptom Fix Time Priority
Disk space full Drive shows < 500 MB free, error occurs on any stream 5–15 mins Check first
NTFS permissions wrong Error after moving content directory or changing service account 10–20 mins Check second
Registry temp path bad Error persists after disk & permissions check, path points to invalid drive 10–15 mins Check third

Start with disk space. Fix that, and 90% of these errors vanish. If not, move to permissions, then the registry. Your stream will be back up in no time.

Was this solution helpful?