Automatically Starting Services

During system boot, the SCM starts all auto-start services and the services on which they depend. For example, if an auto-start service depends on a demand-start service, the demand-start service is also started automatically.

The load order is determined by the following:

The order of groups in the load ordering group list. This information is stored in the ServiceGroupOrder value in the following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control

To specify the load ordering group for a service, use the lpLoadOrderGroup parameter of the CreateService or ChangeServiceConfig function.

The order of services within a group specified in the tags order vector. This information is stored in the GroupOrderList value in the following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control

The dependencies listed for each service.

When the boot is complete, the system executes the boot verification program specified by the BootVerificationProgram value of the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control.

By default, this value is not set. The system simply reports that the boot was successful after the first user has logged on. You can supply a boot verification program that checks the system for problems and reports the boot status to the SCM using the NotifyBootConfigStatus function.

After a successful boot, the system saves a clone of the database in the last-known-good (LKG) configuration. The system can restore this copy of the database if changes made to the active database cause the system reboot to fail. The following is the registry key for this database:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSetXXX\Services

where XXX is the value saved in the following registry value: HKEY_LOCAL_MACHINE\System\Select\LastKnownGood.

If an auto-start service with a SERVICE_ERROR_CRITICAL error control level fails to start, the SCM reboots the computer using the LKG configuration. If the LKG configuration is already being used, the boot fails.

An auto-start service can be configured as a delayed auto-start service by calling the ChangeServiceConfig2 function with SERVICE_CONFIG_DELAYED_AUTO_START_INFO. This change takes effect after the next system boot. For more information, see SERVICE_DELAYED_AUTO_START_INFO.

“Automatic” vs “Automatic (Delayed start)”

When installing Windows services there are two options for automatically starting a Windows service on Windows startup. One is Automatic, and the other is Automatic (Delayed start). What is the difference between these two in detail?

For example, if you’re creating the installer with wixtoolset, the ServiceConfig element has the DelayedAutoStart attribute. How will that effect what happens when services are started at boot time?

1 Answer 1

In short, services set to Automatic will start during the boot process, while services set to start as Delayed will start shortly after boot.

Starting your service Delayed improves the boot performance of your server and has security benefits which are outlined in the article Adriano linked to in the comments.

Update: «shortly after boot» is actually 2 minutes after the last «automatic» service has started, by default. This can be configured by a registry key, according to Windows Internals and other sources (3,4).

The registry keys of interest (At least in some versions of windows) are:

• HKLM\SYSTEM\CurrentControlSet\services\ \DelayedAutostart will have the value 1 if delayed, 0 if not.
• HKLM\SYSTEM\CurrentControlSet\services\AutoStartDelay or HKLM\SYSTEM\CurrentControlSet\Control\AutoStartDelay (on Windows 10): decimal number of seconds to wait, may need to create this one. Applies globally to all Delayed services.

Automatically Start Windows Service on Install

I have a Windows service and an MSI installer (setup project) for it. The setup project has custom actions for install and uninstall with args of /install and /uninstall respectively.

I would like the service to start immediately after the install. All my service does is starts a process. When the service is stopped, it does process.Close(); .

I have tried doing

The process starts, but the event log message saying the service has started doesn’t show. When stopping I get the error Error stopping process: System.InvalidOperationException: No process is associated with this object. .

If I don’t use the service controller to start and use Services.msc instead, it works as expected when stopping.

Is there a way to have the process start immediately and have my start/stop methods work as expected?

3 Answers 3

You don’t say what operating system you are using, but I remember running into this when developing an installer app last year. I beleive this is a security restriction in Windows 7, Server 2003/2008, and possibly Vista, as installation program cannot start any application program that it installs. If you set the service for Automatic Startup, then it should start the next time the system restarts.

I think what you’re saying is that there are two issues are going on here. The first issue is that the service doesn’t start upon install. The second is that the service is unable to start the process. Am I right?

When I’ve installed services through a setup project, I always start the service from the Commit method of the installer class, that way I know that everything got installed correctly. I’m not 100% sure about this, but you may not be able start the service until the installation has been committed. It looks like you have your Custom Actions set up correctly, so there shouldn’t be any issue with the Commit method getting called (you do have Commit included in the Custom Actions, right?) Here is an example of the Commit method from one of my projects:

By showing the message box to the user, if something goes wrong with the service start, at least the user will be notified that the service should be started manually. When debugging the install issue, you can include the exception in the message box for more details into what exactly is going on.

I’m curious — what Account are you using in your ServiceProcessInstaller? Does this user have the rights on the computer to start the process? Does the Process have any specific UAC requirements? I suspect that Access Control is what is keeping your process from starting.

Automatically start a Windows Service on install

I have a Windows Service which I install using the InstallUtil.exe. Even though I have set the Startup Method to Automatic, the service does not start when installed, I have to manually open the services and click start. Is there a way to start it either via the command line, or through the code of the Service?

13 Answers 13

In your Installer class, add a handler for the AfterInstall event. You can then call the ServiceController in the event handler to start the service.

Now when you run InstallUtil on your installer, it will install and then start up the service automatically.

After refactoring a little bit, this is an example of a complete windows service installer with automatic start:

How about following commands?

Programmatic options for controlling services:

• Native code can used, «Starting a Service». Maximum control with minimum dependencies but the most work.
• WMI: Win32_Service has a StartService method. This is good for cases where you need to be able to perform other processing (e.g. to select which service).
• PowerShell: execute Start-Service via RunspaceInvoke or by creating your own Runspace and using its CreatePipeline method to execute. This is good for cases where you need to be able to perform other processing (e.g. to select which service) with a much easier coding model than WMI, but depends on PSH being installed.
• A .NET application can use ServiceController

You can use the following command line to start the service:

Use ServiceController to start your service from code.

Update: And more correct way to start service from the command line is to use «sc» (Service Controller) command instead of «net».

Automatically start a windows service after install

Which of the two of these are preferable (and why) from the service installer, I’ve seen both mentioned on different websites (and here on stackoverflow Automatically start a Windows Service on install and How to automatically start your service after install?).

3 Answers 3

I consider the latter a little more proper (although a quick check of my codebase and I coded essentially the former). The difference I see is the chance of a Rollback happening. In the commit phase you are past the risk of a rollback. But if you start your service in the AfterInstall (which is just part of the overall Install phase (the four phases being Install, Rollback, Commit, Uninstall)) you have the possibility of a Rollback being issued by a subsequent InstallerClass. You would then need to stop your service and uninstall it (which Microsoft’s default service installer classes do for you so it’s not much of an issue.

In summary, there isn’t too much of a difference.

Considering Committed is raised post-installation (that is, only when Install() calls have completed, and hence related events raised (if successful)) then I would say doing it at this point is «safest». in fact, I’m sure it is the last installation related event raised, and by doing so finalises the complete installation.

The Commit method is called only if the Install method of each installer in this instance’s InstallerCollection succeeds.

Since Commit gathers information required for uninstallation, and it is possible to break and therefore for Rollback to be called throughout installation — you could possibly find yourself in a bind if services are already ambitiously running before completed, successful committing.