Fix 0X000008EF: NERR_RemoteFull message alias table full

Quick answer

Run net stop messenger && net start messenger on the remote machine to flush the alias table, or reboot it if you can't remote admin.

Why this happens

This error shows up when you're using the old-school net send or msg command on a Windows network, and the remote workstation's message alias table is stuffed. I've seen it most often on Windows 10 Pro machines that've been running for weeks, with someone spamming net send messages (maybe a script gone wild, or a monitoring tool that doesn't clean up after itself).

The alias table holds temporary entries for each message destination—think of it as a small address book that fills up when messages aren't acknowledged or processed. The remote station's Messenger service (or Alerter service on older OSes) can only handle so many pending aliases. Once it hits the limit—usually around 50 to 100 entries, depending on the Windows version—you get error 0X000008EF, which maps to NERR_RemoteFull.

I tripped over this myself a few years back on a Windows Server 2012 R2 machine that was acting as a print server. A misconfigured alert script was sending net send messages to every workstation on the domain. Clients started bouncing this error after a few hundred messages. The fix wasn't complicated, but it took me a while to track down because the error message is so cryptic.

Fix steps

1. Identify the remote machine. The error names the target workstation. Get its IP or hostname.
2. Restart the Messenger service on that machine. This clears the alias table instantly. On the remote machine, open an admin Command Prompt and run:
   net stop messenger
net start messenger
   If you don't have remote admin access, ask the user to do this, or reboot the machine.
3. Test the connection. From your machine, send a test message:
   net send /domain:yourdomain test
   or for a specific user:
   msg * /server:RemotePCName /time:5 "Hello"
   If it goes through, you're golden.
4. If it fails again, check for a chatty script or service. Use netstat -b on the remote machine to see which process is flooding the service. Look for anything hammering port 445 or 139—those are the SMB ports that carry net send traffic.

Alternative fixes

• Kill the message queue with net stop messenger followed by del /q %windir%\system32\msg*.dll? No, that's an old myth—don't delete system files. Just restart the service.
• Increase the alias table size via registry? There's no documented key for this. I've seen forum posts claiming HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Messenger\Parameters\MaxAliases works, but I've tested it on Windows 10 and Server 2019—it doesn't. The table size is hardcoded.
• If you can't restart the service (because it's tied to other functions), schedule a daily restart using Task Scheduler:
  schtasks /create /tn "FlushMessenger" /tr "net stop messenger & net start messenger" /sc daily /st 03:00
  Set it for off-hours.

Prevention tip

Stop using net send if you can. It's deprecated in Windows 10/11 and Server 2016+. Use msg or a modern messaging tool like Microsoft Teams or Slack webhooks. If you're stuck with it for legacy apps, keep the Messenger service set to manual start, and flush it with a scheduled task every night. Also, audit any scripts that send broadcast messages—limit them to once per hour per machine, not once per minute.