Fix 0x000008EC: Messenger Service Not Started Error

What 0x000008EC Actually Means

0x000008EC is just 2284 in decimal, and Windows maps that to NERR_MsgNotStarted. Translation: something tried to talk to the Messenger service — usually net send, a monitoring agent, or an old backup tool — and the service wasn't running. The caller gets back a generic failure that looks like a permissions problem but isn't.

I had a client last month whose entire alerting pipeline died because of this. Their NOC dashboard used net send to page on-call staff about disk failures. Worked for years. Then a Windows update reset the Messenger service startup type to Disabled, and nobody noticed until a RAID array degraded and no page went out. That's the kind of thing this error hides behind.

Here's the troubleshooting flow. Start at step one. Stop when you're fixed.

Step 1: The 30-Second Check

Open an elevated command prompt (right-click Command Prompt, Run as administrator) and run:

sc query messenger

You'll get one of three results:

• STATE : 4 RUNNING — it's up. Your error is coming from somewhere else, probably a remote machine.
• STATE : 1 STOPPED — it exists but isn't running. Jump to Step 2.
• [SC] OpenService FAILED 1060 — the service doesn't exist at all. Jump to Step 3.

If it says STOPPED, just try this right now:

net start messenger

On most systems that works and you're done. On others you'll get "The service cannot be started, either because it is disabled or because it has no enabled devices associated with it." That error means the startup type got flipped to Disabled — usually by a security hardening script or a Group Policy pushing a baseline.

Step 2: The 5-Minute Fix — Flip Startup Type Back

Open Services.msc (Win+R, type services.msc, Enter). Scroll to Messenger. If you don't see it, skip to Step 3.

Right-click it, Properties. You'll probably see Startup type: Disabled. Change it to Automatic or Manual. I use Manual for workstations and Automatic for servers that actively send alerts. Click Apply, then Start.

If the Change Startup Type dropdown is greyed out, Group Policy is locking it. That's the case on a lot of domain-joined boxes after a CIS or STIG baseline gets applied. Check:

rsop.msc

Look under Computer Configuration → Windows Settings → Security Settings → System Services. If Messenger is listed with a startup mode of Disabled, that's your culprit. Fix it in the GPO, run gpupdate /force, reboot if needed.

Same thing via command line if you prefer:

sc config messenger start= auto
sc start messenger

The space after start= matters. I've seen people lose 20 minutes on that alone.

Step 3: The Advanced Fix — Service Is Gone or Being Killed

If Service Control Manager doesn't know about Messenger at all, you're on a modern Windows build (10 1709+, Server 2019+) where Microsoft removed the service entirely. It was deprecated years ago because it's an unauthenticated broadcast protocol and a giant spam vector. You can't "enable" something that isn't installed.

Confirm by checking the registry:

reg query HKLM\SYSTEM\CurrentControlSet\Services\Messenger

If that returns "The system was unable to find the specified registry key or value," the service binary is gone. No amount of sc create will bring it back cleanly. You'd be rebuilding the service from an older DLL and that's a bad idea on a supported OS.

The real fix is to stop using Messenger. Whatever app is throwing 0x000008EC needs to move to a supported alerting path. Options ranked by how much pain they cause:

1. Replace net send with msg. Microsoft shipped msg.exe as the modern replacement. Syntax is close enough that most scripts convert in minutes: msg * "Disk alert on SRV-01". It uses RPC instead of the Messenger service, so it works on every current Windows build.
2. Point monitoring at a real channel. If you're using an old version of Nagios, PRTG, or a homegrown script that shells out to net send, reconfigure the notification handler to use SMTP, Teams webhooks, or Slack. Fifteen minutes of config beats six months of fighting a removed API.
3. If you absolutely need Messenger (legacy line-of-business app, industrial control system, ancient ERP), keep it on an isolated subnet running Server 2008 R2 or 2012 R2. Don't try to bolt it onto a modern host. I've watched people waste entire weeks on this and never get a stable result.

Remote Senders Get the Same Error Differently

Worth mentioning because it trips people up: if a remote machine sends you net send traffic and your Messenger service is stopped, you don't see the error — they do. The error code 0x000008EC appears on the sender's side. So if a client tells you "our alert tool is broken," check the Messenger service on the receiving machine, not the sender.

Also check the firewall. Messenger uses UDP 135, 137, 138 and TCP 139, 445. On a modern network those are usually blocked at the edge, which means even a running Messenger service won't receive anything from across a subnet.

Quick Reference

If you're still relying on Messenger for anything in production, that's the real problem. Fix the alerting pipeline, not just the service.

Nine times out of ten, this error means somebody's hardening script disabled Messenger and forgot to tell anyone. The fix takes 30 seconds once you know where to look. The tenth time means you're on a modern OS and it's time to let the service die — Microsoft killed it for a reason, and fighting that is a waste of your afternoon.