1

Snippet from my wxs file:

<ServiceInstall Id="ServiceInstall" Type="ownProcess" Vital="yes"
    Name="service name"
    DisplayName="service display name"
    Description="service description"
    Start="auto" Account="[SERVICEUSERNAME]" Password="[SERVICEPASSWORD]"
    ErrorControl="normal" Interactive="no" />

<ServiceControl Id="StartService"
    Start="install" Stop="uninstall" Remove="uninstall"
    Name="service name" Wait="yes">
    <ServiceArgument>arguments for first run</ServiceArgument>
</ServiceControl>

If the service fails to start, the installer waits for several minutes before failing, whereas it ought to be able to detect that it is in the stopped state, and from that point could never reach the started state without manual intervention. Yet, it keeps waiting. Is there any way to fix this?

Mark Raymond
  • 906
  • 8
  • 22

1 Answers1

0

Service control is a message-based scheme. Windows Installer and the service control mechanism wait for the service to respond from the start message. It's not clear what you mean by "detect it's in the stopped state" because the code might be doing legitimate work, may have crashed but has recovery code, or may be configured to restart after a failure (see ChangeServiceConfig2 Win32 API).

In your case, you have wait=yes which explicitly causes the installer to wait until the service is completely initialized. As the MSDN docs say:

"Leaving this field null or entering a value of 1 causes the installer to wait a maximum of 30 seconds for the service to complete before proceeding. The wait can be used to allow additional time for a critical event to return a failure error. A value of 0 in this field means to wait only until the service control manager (SCM) reports that this service is in a pending state before continuing with the installation."

So changing your Wait value could help. In any event, the normal case when a well-coded service starts normally doesn't cause any of these issues. The fact that the service is broken is not only a rare case (or should be) but when things are broken they are in fact broken and often unpredictable for that reason.

PhilDW
  • 20,260
  • 1
  • 18
  • 28
  • As I understand it, a service can be in one of 7 states: from https://msdn.microsoft.com/en-us/library/system.serviceprocess.servicecontrollerstatus(v=vs.110).aspx, ContinuePending, Paused, PausePending, Running, StartPending, Stopped, StopPending. If the service reaches StartPending, and then moves to Stopped, the service failed to start, and I would expect the install to fail at that point, rather than continuing to wait. The service is not configured to restart after a failure (though perhaps it should be...) – Mark Raymond Nov 17 '16 at 11:18
  • Also - WiX doesn't allow a value of 1, it give the error "error CNDL0015 : The ServiceControl/@Wait attribute's value, '1', is not a legal yes/no value. The only legal values are 'no' and 'yes'." I assume that 'yes' translates to 1 and 'no' to 0 in the ServiceControl installer table. – Mark Raymond Nov 17 '16 at 11:28
  • As I said, I'm referring to the source MSDN documentation, not the WiX syntax for specifying the wait value. The service states that you describe are not detected automatically, they are reported by APIs such as QueryServiceStatus, therefore the service must be coded to return those values, and obviously be alive to return them. Otherwise the timeout rules apply. – PhilDW Nov 17 '16 at 17:01