CODEWITHSUNDEEP
c++wixwindows-services
user0000001
user0000001

Reputation: 2233

Failing to start Windows service after a MajorUpgrade with WiX

I have a pretty straight forward WiX project. Nothing fancy. When trying to perform a MajorUpgrade over an existing installation, it is unable to start the service and inevitably rolls back to the previous version and starts the service just fine. I have removed the Start="install" and manually started the application successfully, so I know it's not a dependency issue.

I have searched endlessly and found no answers to my problem. 

<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." Schedule="afterInstallFinalize" />

My service install:

<ServiceInstall
        Id="ServiceInstaller"
        Type="ownProcess"
        Name="LsdnService"
        DisplayName="Lsdn Service"
        Description="Placeholder for now."
        Start="auto"
        Account="[SERVICEACCOUNT]"
        Password="[SERVICEPASSWORD]"
        ErrorControl="normal"/>
<ServiceControl Id="StartService" Start="install" Stop="both" Remove="uninstall" Name="LsdnService" Wait="yes" />

I dumped the MSI log to a file and got this error but it is quite vague.

MSI (s) (18:48) [22:41:27:349]: Note: 1: 2205 2:  3: Error 
MSI (s) (18:48) [22:41:27:349]: Note: 1: 2228 2:  3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1920

There are some registry modifications during an installation. The installer attempts to read from the registry and inherit the already existing values.

<Property Id="LSDNADDRESS" Value="127.0.0.1">
  <RegistrySearch Id="LsdnAddressProperty" Root="HKLM" Key="$(var.RegistryKey)" Name="LsdnAddress" Type="raw" />
</Property>
<Property Id="LSDNPORT" Value="9920">
  <RegistrySearch Id="LsdnPortProperty" Root="HKLM" Key="$(var.RegistryKey)" Name="LsdnPort" Type="raw" />
</Property>
<Property Id="LSDNKEY" Value="6f380b07-0b54-4904-8303-95d1ec45d453">
  <RegistrySearch Id="LsdnKeyProperty" Root="HKLM" Key="$(var.RegistryKey)" Name="LsdnKey" Type="raw" />
</Property>

Upvotes: 1

Views: 851

Answers (2)

Stein &#197;smul
Stein &#197;smul

Reputation: 42136

Debugging Results: Following a lot of debugging (by original poster - OP) this turned out to be a known MSI issue described here: https://wix-users.narkive.com/EMfQPDrM/a-bug-get-reg-sz-when-using-type-integer. Nice search work.

What is in a DWORD? (a REG_SZ apparently): Essentially MSI "converts" a DWORD value found via a RegistrySearch operation to a formatted string - REG_SZ - during upgrade installations (could be more involved too). This causes services that expect a DWORD value to fall over on startup during major upgrades. A very exotic error.

Workaround: One can try to "solve" this problem by making the service code capable of reading both DWORD and REG_SZ. This yields a more robust solution than solving the problem in a custom action since it is a "permanent" fix as long as the code is in there (and the presence of the code alerts other developers about the problem). Or maybe use only REG_SZ?

Quick Checks: Check the service password and login - obviously. Anything in the Event Viewer? Windows Key + Tap R + eventvwr.msc + Enter. How to use the Event Viewer to troubleshoot problems with a Windows Service. Perhaps you can try to do a folder diff on the before and after folders and see if you see something unexpected in the config files? Naturally there will be lots of binary differences, but check the text files (also encoding). Check the MSI log file again and search for "value 3" as described here: Tips For Checking MSI Log Files. Manually copy the new files in place and attempt to start the service via the services.msc applet.

Service Experts: Windows Services Frequently Asked Questions (FAQ). Content seems to be up to date - at face value at least. These guys claim to be experts on services. I have no idea who they are.

Look in the "Errors" section in the link above. Here are some extracts:

Generic Check Lists: If none of the above does anything, maybe try these "torpedoes full spread" check-lists (just ideas to start debugging):

General Purpose Debugging: Throwing in some general-purpose debugging approaches.

Some Further Links:

Upvotes: 1

Christopher Painter
Christopher Painter

Reputation: 55581

It certainly could be a dependency issue. For example, GAC / WinSXS files don't get installed into the GAC until the commit phase which is after StartServices.

I would leave the Start="Install" in and while it's sitting at the failed to start prompt inspect the state of the machine and debug the service start manually. I bet you'll find something missing.

Upvotes: 1

Related Questions