Failed to install and start Windows services in WiX installer

Question

I am creating an MSI package for installing and starting Windows services using WiX v3.8. The code as follows:

<Component Id="INSTALLAPSSERVICE" Guid="991D5F82-0E77-4FE3-B1D8-4C941B84C7CD" Win64="yes">
   <File Id="ApsService.exe"
         Name="ApsService.exe"
         Source="Resource\ApsService.exe"
         KeyPath="yes"
         Vital="yes"
         DiskId="1"></File>
   <ServiceInstall Id="ApsServiceInstaller"
                   Name="ApsService"
                   DisplayName="ApsService"
                   Type="ownProcess"
                   Start="auto"
                   ErrorControl="normal"
                   Description="A monitor service for windows application."
                   Account="[SERVICEACCOUNT]"
                   Password="[SERVICEPASSWORD]"
                   Vital="yes"
                   Interactive="no"></ServiceInstall>
    <ServiceControl Id="StartService"
                    Start="install"
                    Stop="both"
                    Remove="uninstall"
                    Name="ApsService"
                    Wait="yes"/>
</Component>

But install fails with the following errors in the log:

Executing op: ServiceControl(,Name=ApsService,Action=1,Wait=1,)
StartServices: Service: ApsService
Error 1920. Service 'ApsService' (ApsService) failed to start. Verify that you have      sufficient privileges to start system services.
MSI (s) (F0:D0) [15:57:28:630]: I/O on thread 3676 could not be cancelled. Error: 1168
MSI (s) (F0:D0) [15:57:28:630]: I/O on thread 1888 could not be cancelled. Error: 1168
MSI (s) (F0:D0) [15:57:28:630]: I/O on thread 1764 could not be cancelled. Error: 1168
MSI (s) (F0:D0) [15:57:28:630]: I/O on thread 3504 could not be cancelled. Error: 1168
MSI (s) (F0:D0) [15:57:28:630]: I/O on thread 2100 could not be cancelled. Error: 1168
MSI (s) (F0:D0) [15:57:28:630]: I/O on thread 2752 could not be cancelled. Error: 1168
MSI (s) (F0:D0) [15:57:28:630]: I/O on thread 3672 could not be cancelled. Error: 1168
MSI (s) (F0:D0) [15:57:28:630]: I/O on thread 3876 could not be cancelled. Error: 1168
MSI (s) (F0:D0) [15:57:28:630]: I/O on thread 1400 could not be cancelled. Error: 1168
MSI (s) (F0:C0) [15:57:28:630]: Product: WinApsSetup64 -- Error 1920. Service 'ApsService' (ApsService) failed to start. Verify that you have sufficient privileges to start system services.

How can I fix the errors?

Debatable

did u find the solution? – Feverroot

Answer 1

The error message you are getting is the generic message the Windows Installer sends when it fails to start a service during install. Almost always the issue is that the Service is missing a dependency or otherwise not fully configured when the start occurs. To debug the root issue try:

1. Install the MSI package.
2. When the error dialog comes up indicating there is a failure to start the service *do not dismiss the dialog.
3. Start services.msc or use sc.exe from the command-line to attempt to start your service. The Windows Installer should have configured enough of the service to be able to debug deeper why it failed.
4. If necessary debug into your service executable directly to see why it cannot be started.

If this is a service written in managed code, ensure that it does not depend on files being placed in the GAC. Files are not in the GAC until very, very late during the installation process. If you must use files in the GAC, you will not be able to use the built-in ServiceControl element and will have to write a custom action to run after InstallFinalize. Note that after InstallFinalize a custom action will not be elevated so your service will have to support being started by non-elevated users. Again, I recommend not depending on the GAC.

Good luck debugging your service!

Creosote

Hi Rob, while the question may sound dummy, but how do I know if my executable depends on some file in GAC? – Antibiosis

Answer 2

The ServiceInstall Account is obfuscated in the OP's example, but this error can happen if one forgets to fully qualify the account, as such:

<ServiceInstall ... Account="NT AUTHORITY\LocalService" />

Your installer will fail if you only specify the username (w/o the NT Authority) like this:

<ServiceInstall ... Account="LocalService" />

Kathrinekathryn

Related to this answer: If you use a local account for [SERVICEACCOUNT], make sure you include name of the computer, and not just the account name. E.g. MYSERVER\UserX will work, while just UserX will not work. And, of course, you need to specify domain name is this is a domain account. – Squawk

Answer 3

Remember to add "Log on as a service" rights to the [SERVICEACCOUNT],

To add the "Log on as a service" right to an account on your local computer

1) Open Local Security Policy.

2) In the console tree, double-click Local Policies, and then click User Rights Assignments.

3) In the details pane, double-click Log on as a service.

4) Click Add User or Group, and then add the appropriate account to the list of accounts that possess the Log on as a service right.

From: http://technet.microsoft.com/en-us/library/cc739424%28v=ws.10%29.aspx.

Shanteshantee

Answer 4

When debugging a service startup issue, I always just use a simple if() statement that checks for the existence of a particular file in the installation directory. When the service fails, I open a command prompt (before dismissing the dialog indicating the failure) and use "echo >thatfile" to create the file that I am looking for in the if(). The object of the if() is the Debugger.Launch() invocation.

Now, I can dismiss the dialog and rerun the installer and this time it will start the debugger and I can see what happens. I tend to use static class init as the moment to launch the debugger, but you can try to do it in "OnStart()", but if there are loading/binding issues, you probably won't get to that point before it dies. Whereas doing it during static class init will almost always tell you the things that you need to address as dependencies.

Uncommercial

Answer 5

So I got this error today because my service had dependencies that had to be GACed before starting the service. As it turns out, dependencies are GACed last by the installer, and there's really no good way to get around this without building some kind of bootstraper/multipart installer.

However, I found the following resolution: deploy the assemblies both to the GAC and install them in the same directory as the service. This way, the service will be able to find the DLLs on start in the program files directory, and they will be GACed (which was a requirement for other reasons).

To do this, I had to create two separate component groups, and a "dummy" Directory:

<Directory Id="TARGETDIR" Name="SourceDir">
  <Directory Id="ProgramFilesFolder">
    <Directory Id="INSTALLDIR" Name="NameOfProgram" />
    <Directory Id="GacDlls" Name="libs" />
  </Directory>
</Directory>

I then create two Component Groups: one that has the exe and all libraries, and a second with the same libraries with the Assembly attribute set to ".net":

<ComponentGroup Id="ServiceLibs" Directory="GACDlls">
    <Component Id="log4netGAC"
                   Guid="a23099ac-5880-4b6e-af3f-fa7cef113226">
        <File Id="log4net.dllGAC"
              Name="log4net.dll"
              Source="..\ProjectDir\bin\$(var.Configuration)\log4net.dll"
              KeyPath="yes"
              Vital="yes"
              DiskId="1"
              Assembly=".net"
            />
    </Component>
</ComponentGroup>

<ComponentGroup Id="ProductComponents" Directory="INSTALLDIR">
    <Component Id="log4net"
               Guid="463e05db-e248-44d7-bbde-467358b7310f">
        <!-- normally we'd want to GAC this (Assembly=".net"), but that would prevent us from starting the service up during install so we'll just drop it in the program folder -->
        <File Id="log4net.dll"
              Name="log4net.dll"
              Source="..\ProjectName\bin\$(var.Configuration)\log4net.dll"
              KeyPath="yes"
              Vital="yes"
              DiskId="1"                      
            />              
    </Component>
    ... other components ...
</ComponentGroup>

And now it works!

Sawdust

Answer 6

I was also having this issue, an error kept occurring during installation even though the service registry keys were created and I was able to manually start the service.

So I solved it this way:

Instead of starting the service right at installation with the Service control:

  <ServiceControl Id="StartService"
                  Start="install" 
                  .. />

I just removed Start from the ServiceControl so the installer's success is not dependent on the service being started. You just need to start the service manually after successful installation which can be done easilly with a script.

Tacita

Answer 7

Just wanted to add my solution in case someone runs across this like I did...

I had a .msi file that was installing services and at a certain point, a dialog box would pop up saying, ""Service ... failed to start. Verify that you have sufficient privileges to start system services." Of course I had all the privileges... Once I generated a log for it

msiexec -i package.msi /L*V package.log

had this in the logfile:

Error 1920. Service 'Controller 01' (Controller01) failed to start. Verify that you have sufficient privileges to start system services.
MSI (s) (04:5C) [12:23:11:831]: I/O on thread 2052 could not be cancelled. Error: 1168
MSI (s) (04:5C) [12:23:11:831]: I/O on thread 5396 could not be cancelled. Error: 1168
MSI (s) (04:5C) [12:23:11:831]: I/O on thread 5404 could not be cancelled. Error: 1168
MSI (s) (04:5C) [12:23:11:831]: I/O on thread 1448 could not be cancelled. Error: 1168
MSI (s) (04:5C) [12:23:11:831]: I/O on thread 1904 could not be cancelled. Error: 1168
MSI (s) (04:5C) [12:23:11:831]: I/O on thread 1088 could not be cancelled. Error: 1168
MSI (s) (04:5C) [12:23:11:831]: I/O on thread 6952 could not be cancelled. Error: 1168
MSI (s) (04:5C) [12:23:11:831]: I/O on thread 6956 could not be cancelled. Error: 1168

Looking in the Event Viewer was no help, so before I hit cancel on the installer, I went to the location of the service on the hard drive and tried to run it as an administrator. At which point, I got a clue that led me to ultimately fix this:

MSVCR120.dll was not found

At which point, I went to c:\windows\system32 and looked for the DLL... and it was there. So, I copied it directly into the directory with the .exe and tried to run it again. This time I got a different error message:

The application was unable to start correctly (0xc000007b)

Searching for the meaning of "0xc000007b", I found here what it signifies: "The error 0xc000007b means STATUS_INVALID_IMAGE_FORMAT. This means an application tries to load DLLs with the wrong CPU architecture. So a 32Bit application tries to load 64Bit Dlls or the opposite (64Bit app tries to load 32Bit DLLs)."

So in my case, the publisher of the installer failed to include the x86 Visual C++ Redistributable Package for Visual Studio 2013. After installing that and rebooting, I reran the installer and it worked.

Null