| Previous | Next |
| ERROR_PROCESS_IS_PROTECTED | ERROR_DISK_QUOTA_EXCEEDED |
ERROR_SERVICE_NOTIFY_CLIENT_LAGGING
A service notification client lagged behind SCM state
NotifyServiceStatusChange delivers service state notifications through an APC queued to the calling thread. The calling thread must enter an alertable wait to receive the callback. Microsoft documents ERROR_SERVICE_NOTIFY_CLIENT_LAGGING when notification processing is too far behind the current machine service state.
The documented recovery is specific: close the SCM handle, open a new handle, and call NotifyServiceStatusChange again. Also fix the reason for lag. Each notification registration can queue at most one callback, and clients that want continuing updates must register again. Keep the notification thread responsive and in alertable wait; do not run lengthy service-management work directly in the callback. A client that never drains APCs or re-registers incorrectly can lose synchronization with SCM state even though individual services are healthy.
What to inspect
- Close and reopen the SCM handle, then register the notification again.
- Ensure the notification thread performs alertable waits and drains APC callbacks.
- Move expensive work out of the callback and re-register deliberately for later changes.
References
- Microsoft: NotifyServiceStatusChangeW
- Microsoft: QueryServiceStatusEx
- Microsoft: Service Control Manager
Looking for a different code? Search another status or error code.