0X0000088A

Fix 0X0000088A: Service not responding to NERR_ServiceCtlTimeout

Server & Cloud Intermediate 👁 1 views 📅 Jun 8, 2026

This error fires when Windows can't stop or restart a server service within its timeout window. Usually the service is stuck mid-transition.

When this error hits

You're on a Windows Server 2019 or 2022 box, maybe running DNS or DHCP roles. You open Services.msc, right-click a service — say the DNS Server service — and hit Restart. A dialog appears: Windows could not stop the service on Local Computer. The service is not responding to the control function. Error 0X0000088A: NERR_ServiceCtlTimeout. The service icon might show a Stopping state that never finishes. That's the exact trigger.

What's actually happening

The Service Control Manager (SCM) sent a stop or pause command to the service process, then waited for a reply. Each service has a default timeout of 30 seconds (per the ServicesPipeTimeout registry value). If the service doesn't acknowledge the command within that window, the SCM throws 0X0000088A. The service isn't dead — it's hung in a transitional state. Most often the service thread that handles control requests (the HandlerEx callback) is blocked on some internal operation: a pending RPC call, a stuck lock, or a slow file I/O. The SCM can't force-kill it because the service is still technically alive. You're stuck in a limbo.

The fix

Don't bother trying to stop the service again from the GUI — it'll fail. The SCM already gave up on it. Here's the sequence that works:

  1. Kill the process from Task Manager
    Open Task Manager (Ctrl+Shift+Esc), go to the Details tab. Find the service's process — for DNS it's dns.exe, for DHCP it's dhcpsrv.exe. Right-click and select End task. If it won't die, use taskkill /f /im dns.exe from an admin Command Prompt. Windows will then notice the process is gone and update the service state to Stopped within seconds.
  2. Clear the stuck state
    Even after killing the process, the SCM might still show Stopping. Run this command in an admin prompt:
    sc queryex <service_name>
    Replace <service_name> with the actual name — for DNS it's DNS, for DHCP it's DHCPServer. You'll see STATE : 3 STOP_PENDING. If so, run:
    sc stop <service_name>
    This forces the SCM to finalize the stop state now that the process is truly gone.
  3. Start the service clean
    Now start it fresh:
    sc start <service_name>
    Or use the Services GUI — it should respond normally.

Why step 3 works

The reason sc stop succeeds after killing the process is because the SCM checks whether the service process handle is still valid. Once the process is dead, the handle becomes invalid, and sc stop concludes that the service has stopped — it updates the state machine without waiting for a reply. If you skip step 2 and just try to start, the SCM might refuse because it still thinks the service is in Stop Pending.

Preventing it from happening again

If this keeps recurring with the same service, you've got a deeper problem. Check the service's own logs — DNS has event logs under DNS Server in Event Viewer. The root cause is usually one of these:

  • The service is waiting on a network resource that's slow or unreachable (e.g., an upstream DNS server timing out).
  • The service holds a lock on a database file (like DHCP's dhcp.mdb) that's being accessed by another process.
  • A custom third-party service with a poorly written HandlerEx callback that doesn't return quickly.

You can also extend the SCM timeout if you're sure the service just needs more time. Add this registry value:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServicesPipeTimeout

Set it to a DWORD value in milliseconds — 60000 gives 60 seconds. Reboot to apply. I've used this for backups that take a while to drain in-flight operations. But it's a band-aid; fix the real hang.

What to check if it still fails

If the process refuses to die via taskkill /f, you're dealing with a kernel-mode driver or system thread that's stuck. Reboot the server. For a critical service (like DNS on a domain controller), plan a maintenance window. If the error appears on startup, your service is failing during its initialization — check Application event logs for errors just before the 0X0000088A entry. Look for Event ID 7000 or 7009, which indicate a service failed to start or didn't respond in time.

Was this solution helpful?