Auto-start services to be started only after Windows has finished its own startup process. Specifically, a delayed auto-start service is activated roughly two minutes after regular auto-start services. The Service Control Manager (SCM) also creates the main service thread with a lower priority, ensuring that any logged on user isn't notably impacted by delayed auto-start services. The priority is set back to normal after the service updates its state indicating that it is running. You can force a delayed auto-start service to start sooner by using the StartService function if it turns out that it hasn't started by the time your application needs to make use of it.
Example: Windows Security Center Service(wscsvc) starts a Automatic delayed start Service.
Sample Code:
bool ChangeDelayedAutoStart( SC_HANDLE service, bool delayed)
{
ASSERT(0 != service);
SERVICE_DELAYED_AUTO_START_INFO info = { delayed };
return 0 != ::ChangeServiceConfig2(
service,
SERVICE_CONFIG_DELAYED_AUTO_START_INFO,
&info);
}
Service State Change Notifications
Earlier than Windows Vista, the only way for a client to determine whether a service had changed its status or been created or deleted was to use the service query API—such as the QueryServiceStatusEx function—and poll the status of the service. This was not the best approach because these polling loops reduced system performance. In addition, polling loops have historically been a significant source of bugs.
Windows Vista introduces a new function, NotifyServiceStatusChange, which allows the SCM to notify a client when a specified service is created, is deleted, or changes its status.
How to Have a Client Notified When a Service's State Changes:
To register for state change notifications, a client calls NotifyServiceStatusChange to specify the service and change that they want to be notified of. They also provide the SCM with a pointer to a callback function. When the specified change takes place, the SCM calls the callback function to notify the caller.
The following list contains several notes on the use of NotifyServiceStatusChange. For more information, see the function's reference page, which is listed in "Resources" at the end of this paper.
· NotifyServiceStatusChange can be used by local or remote clients.
· The callback function is called only once. If the client wants a subsequent notification for this change, the client must call NotifyServiceStatusChange again and reregister the callback function.
· The callback function is normally called after a transition to the specified state has occurred. There is an exception to this rule for the first time that the caller invokes NotifyServiceStatusChange. In that case, if the service is already in the specified state, SCM calls the callback function.
· Clients can cancel the notification by calling CloseServiceHandle to close the service handle.
· Clients should not exit the thread that they used to call NotifyServiceStatusChange unless the callback function has been called or they have canceled the notification. Otherwise, they will create a memory leak.
· If one or more services hold open handles to a service, the service is not deleted until the next time the system is booted. If this is the case, no delete notification is sent.
Note: A caller must have the SERVICE_QUERY_STATUS access right to call NotifyServiceStatusChange. By default, only administrators, power users, and server operators on a domain controller can get this right remotely. Services and interactive users can get this right locally.
ref:
