爱华网? There is no specific time guarantee for when a delayed auto-start service starts. If
a client application attempts to use a delayed auto-start service before it has
been started, the attempt fails. Clients that depend on delayed auto-start
services must handle the failure gracefully and either retry the attempt later or call StartService to demand-start the service. If such failures happen frequently, the service is probably not a good candidate for delayed auto-start.
? Delayed auto-start services cannot belong to a load-order group. They can belong
to a stand-alone group.
How to Designate a Service as Delayed Auto-Start
To create a delayed auto-start service, set the delayed auto-start flag. The flag can be set for any start type, but takes effect only for auto-start services. If it is set for an auto-start service, startup is delayed until the boot sequence has finished. With the other start types, the flag is simply ignored.
To set the delayed auto-start flag programmatically, call ChangeServiceConfig2 with the following parameter values. The change takes effect the next time the system is booted:
? Set the dwInfoLevel parameter to
SERVICE_CONFIG_DELAYED_AUTO_START_INFO.
? Set the lpInfo buffer to point to a SERVICE_DELAYED_AUTO_START_INFO
structure. This structure contains a single BOOL member that sets or clears the delayed auto-start flag.
The delayed auto-start flag can be modified only by callers with the
SERVICE_CHANGE_CONFIG access right. By default, only local administrators, power users, and server operators on a domain controller receive this right remotely.
Services and interactive users can obtain the SERVICE_CHANGE_CONFIG access right locally.
For information about service startup features in Windows 7, see “Developing Efficient Background Processes for Windows” on the WHDC Web site.
Service State Change Notifications
In Windows versions 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 introduced 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 for which it requires notification. The client also provides the SCM with a pointer to a callback function. When the specified change occurs, the SCM calls the callback function to notify the client.
The following list contains several notes on the use of NotifyServiceStatusChange. For more information, see the function's reference page on MSDN.
? 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 obtain this right remotely. Services and
interactive users can obtain this right locally.
Other Enhancements
Windows Vista and later Windows versions include several other services
enhancements, most of which improve reliability or ease of administration.
Preshutdown Notifications and Shutdown Ordering
In versions of Windows earlier than Windows Vista, service shutdown starts when the system notifies the SCM that the computer is shutting down. The SCM then has a default time of approximately 20 seconds to shut down all running services before the system terminates the SCM process (Services.exe). This procedure does not always allow services to gracefully shut themselves down.
When the SCM receives the shutdown notification, it in turn sends shutdown
requests to every service serially, in random order. Each service has a wait hint that specifies how long the SCM should wait before it simply shuts down the service. In practice, the SCM waits for the longest wait hint to expire and then returns to its control handler, which shuts the services down. This shutdown model creates two types of problems for services:
? The shutdown order is essentially random. If a service expects other services to
shut down in a particular order, it may fail to shut itself down gracefully.
? Some services might not have sufficient time to clean up adequately before
shutdown. This cleanup often must be performed when the service is started
again, which often results in long service startup times or data inconsistencies.
Windows Vista addressed these service shutdown issues in two ways:
? The SCM delivers a preshutdown notification before the actual shutdown
notification. The preshutdown notification gives services that have a potentially lengthy shutdown procedure more time to shut down gracefully.
