使用WiX进行MajorUpgrade后无法启动Windows服务

Question

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>

Answer 1

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:

• 1053: The service did not respond to the start or control request in a timely fashion
• Why doesn't my Windows Service start automatically after a reboot?
• 1069: The service did not start due to a logon failure

---

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

• Desktop applicaton not opening after installation in client system
• Windows Application Startup Error Exception code: 0xe0434352

---

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

• Custom Action Debugging : WIxsharp debug custom action in console
• Dependency Scanning : Which winform project files should be packed up into the installer

---

Some Further Links :

• C# Debug folder when copied to another location does not run the exe
• wix service install not enough permission
• How exactly does the WiX 'Service Install' work internally?
• WiX Toolset PermissionEx Problem - App Does Not Run After Installation

Answer 2

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.