The Service Control Manager maintains its database of installed services in the configuration registry. The information in the registry is organized to allow for the recovery of a system that failed to boot due to bad service configuration. If during boot, a service which is crucial to the system fails to start, the Service Control Manager will instigate a reboot with a saved last-known-good service configuration.
The Service Control Manager shares a registry tree with the NT boot process. The layout of the registry is described in the NT Boot Configuration Specification, Revision 0.3, March 5, 1992.
The Service Control Manager maintains two well-known service databases in the registry:
ServicesActive
The currently active database which the Service Control Manager uses to manage services, and setup/configuration programs modify to reconfigure services. HKEY_LOCAL_SYSTEM\Services is the registry path to this database, and HKEY_LOCAL_SYSTEM\Services\<ServiceName> is the registry key path to an installed service where <ServiceName> is the name of the service.
ServicesFailed
Usually is empty, except when the system fails to boot, this is the configuration that caused the failure. The registry path to this database is HKEY_LOCAL_MACHINE\System\Control_Set_XXX\Services, where XXX is the value saved in the HKEY_LOCAL_MACHINE\System\Select key under the value name “Failed”.
The system is initially installed with ServicesActive pointing to an original service tree. A clone of this same tree is saved away as the last-known-good tree so that the Service Control Manager can fallback to this tree if changes made to the ServicesActive tree causes the system to not boot.
When the system is rebooted with a modified ServicesActive tree, a boot verification program can replace the last-known-good configuration with the one that has just successfully booted by calling the UpdateServiceLastKnownGood function. The new last-known-good configuration is actually cloned from the modified ServicesActive tree before any service is started because once a service is started, it could potentially modify the ServicesActive tree for self-tuning purposes.
If boot fails because a crucial service fails to start, the Service Control Manager automatically reboots the system after it had set ServicesFailed to point to the failed tree, and ServicesActive to point to the previously saved last-known-good tree.
If the Service Control Manager had fallen back to last-known-good configuration and a service still fails to start (e.g. net card was removed but last-known-good configuration specifies to load it), then there is no other configuration to fall back on. The Service Control Manager will ignore all service start failures and press on. Since the boot-strap devices and the Win32 subsystem start before the Service Control Manager, the system is still likely to boot.