0X00000891

0X00000891: Service Control Dispatcher pipe read failed

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

The service control manager can't read from its named pipe. Usually a corrupted service state or a permissions problem. Start with a reboot, then check service dependencies.

You're seeing 0X00000891 (NERR_BadControlRecv) and the service control dispatcher can't read from its named pipe. What's actually happening here is the Service Control Manager (SCM) lost its connection to a service's control pipe—the internal communication channel Windows uses to send start/stop/pause commands. The pipe is either corrupt, the service crashed without cleaning up, or a permissions change blocked access.

I've seen this most often on Windows Server 2022 after a failed Windows Update or a service that hard-crashed (like a SQL Server agent that died mid-operation). The good news: the fix is almost never a deep OS rebuild. Start with what works.

Fix 1: Reboot — 30 seconds

I know, rebooting feels cliché. But the reason step 3 works is because Windows recreates the named pipes in the SCM namespace on boot. If a service left a stale pipe handle, a clean restart flushes it. Don't skip this.

  1. Open Command Prompt as Administrator.
  2. Type shutdown /r /t 0 and press Enter.
  3. Wait for the machine to come back up. Check your service status immediately after.

If the error disappears, you're done. If not, the pipe itself might be hosed, or something is actively corrupting it.

Fix 2: Check service permissions and dependencies — 5 minutes

The SCM communicates via a named pipe at \\.\pipe\net\NtControlPipeX (X varies by service). If a third-party security tool or a manual ACL change removed the SYSTEM account's access, the pipe read fails. Here's how to check.

  1. Open Services.msc and find the service throwing the error. Look at its Log On tab—if it's set to a specific user account instead of Local System, that's your culprit.
  2. Run sc queryex [service name] to see the current state and PID.
  3. Check the service's dependencies: sc qc [service name]. Look for any missing dependent services. If a dependency is stopped or disabled, the SCM can't establish the pipe.
  4. Use Process Monitor (procmon.exe) filtered by Path contains \pipe\ to see if access is denied. If you see ACCESS_DENIED, the service account lacks permission to the pipe.

The real fix here: change the service back to Local System account, or grant the custom account SE_CREATE_PIPE_NAME privilege via Local Security Policy (User Rights Assignment > Create named pipes). I've fixed multiple Server 2019 installs by simply reverting a service to Local System.

If permissions are fine, move to the advanced fix.

Fix 3: Rebuild the SCM database — 15+ minutes

This is a last resort. The SCM database lives in the registry under HKLM\SYSTEM\CurrentControlSet\Services. If a service entry is corrupt (wrong image path, missing Type value, or a duplicate ObjectName), the pipe creation fails. You'll need to manually repair it.

  1. Backup the registry: reg export HKLM\SYSTEM\CurrentControlSet\Services C:\backup_services.reg.
  2. Identify the problem service from the error log. Open Event Viewer, go to Windows Logs > System, filter for Event ID 7031 or 7034. The source will say "Service Control Manager" and name the service.
  3. Open Regedit and navigate to HKLM\SYSTEM\CurrentControlSet\Services\[problem service]. Check these values:
    • Type must be 0x10 for Win32 services. If missing or wrong, set it to 0x10 (DWORD).
    • Start must be 2 (auto), 3 (manual), or 4 (disabled). Never 1 (system) for user services.
    • ImagePath must point to a valid executable. If it's blank or points to a deleted file, fix it.
  4. If the service isn't essential, delete the entire key (after backup). Then run sc create [service name] binPath= "..." to recreate it cleanly.
# Example: recreate a service from scratch
sc delete ProblemService
sc create ProblemService binPath= "C:\Program Files\Vendor\service.exe" start= auto obj= "NT AUTHORITY\LocalService"

The reason step 3 works is because the SCM reads the registry key during pipe creation. A corrupt value causes the pipe open call to return STATUS_INVALID_PARAMETER, which surfaces as NERR_BadControlRecv.

One more thing: I've seen Windows Defender's tamper protection sometimes block SCM pipe creation on Server 2022. If all else fails, temporarily disable real-time protection (not recommended long-term), reboot, and see if the error clears. If it does, add an exclusion for the service's executable.

That's it. Start with reboot, check permissions, then rebuild. Don't reimage the server unless you've exhausted these three steps.

Was this solution helpful?