1

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>
user0000001
  • 2,092
  • 2
  • 20
  • 48

2 Answers2

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:

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:

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • Found my exact problem. https://wix-users.narkive.com/EMfQPDrM/a-bug-get-reg-sz-when-using-type-integer – user0000001 Mar 10 '19 at 22:30
  • So if I understand correctly it retrieves the old port value from the registry and then writes is as an encoded string that then finally converts to a **`DWORD`** at the completion of the install? Now that IS weird indeed :-). I suppose you could make your service deal with this by handing this unexpected encoding? In other words your code can handle reading both a **`DWORD`** and a **`REG_SZ`**. It is almost always better to put this in real code than in a setup custom action, and the reason is future maintenance - the fix must remain in there. Easier to debug in your service code as well. – Stein Åsmul Mar 11 '19 at 03:19
  • Maybe change the encoding to a **`REG_SZ`** as well - for the future? Not necessary, but just "thinking out loud". Not that critical to use a **`DWORD`**? – Stein Åsmul Mar 11 '19 at 03:23
  • Good suggestion. Looks like it's the only maintainable route. Strange that MSI does not support this type of lookup. I found some solutions but seemed like anti-pattern resolutions. For now, I will take your suggestion and do a lookup on the registry type before I do a query, and handle the necessary conversions. Cheers! – user0000001 Mar 11 '19 at 15:26
  • Sounds good. Do let us know if it works and I will update my answer so others can avoid wasting time on this issue. Sorry about that! [MSI has many quirks](https://stackoverflow.com/q/45840086/129130) (not great, best effort, pragmatic list) and also [some borderline and full on anti-patterns](https://stackoverflow.com/a/1055861/129130) (towards bottom, ad-hoc list), but it has delivered [a number of crucial corporate benefits](https://stackoverflow.com/a/49632260/129130). – Stein Åsmul Mar 11 '19 at 17:04
  • Great writeup's. Yes, my issue is fixed. Opening `services.msc` while leaving the MSI error up and starting the service manually lead me to a resolution. The MSI error was incredibly misleading. Thank you again for taking the time to troubleshoot this with me. I would give you more upvotes if I could! Cheers. – user0000001 Mar 11 '19 at 23:40
  • Great! "Torpedoes full spread" worked :-). Helped at least. Good search effort on your part mate. I have never heard of this issue, and I thought I'd seen most quirks. [I only remember one similar issue, and that related to MultiString](https://stackoverflow.com/q/49892805/129130) (and we never really solved it). I have tried to summarize your findings at the top of my previous answer. – Stein Åsmul Mar 12 '19 at 00:02
1

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.

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • Ah, great. I updated one of the check lists. I had forgotten all about that problem. What a horrible anti-pattern that GAC commit issue really is :-(. I'll just add that I would make sure to test on a clean virtual. Obvious, but just want to mention it. [Dependencies](https://stackoverflow.com/a/51940598/129130). – Stein Åsmul Mar 10 '19 at 15:19
  • Assuming the service is written in .NET, one trick is to run the EXE from the command line and see if you get any file not found exceptions listing what assembly it was trying to run. If you can get past that the a little logging from inside the service should be more then enough to troubleshoot the problem. – Christopher Painter Mar 10 '19 at 16:25
  • It is a C++ application and to remove any questions about dependencies, I statically linked the runtime for this scenario - not to be deployed in production. Still ran into the same issues. Though, I am naive when it comes to Windows services and am unsure of GAC. I will need to do some more research to better understand what this is. This issue doesn't occur on a fresh installation with the same installer, only during my upgrade. I am going to compare the log of a fresh install with an upgrade and see what I am missing. Thank you for your suggestions. – user0000001 Mar 10 '19 at 16:38
  • Does your installer have any custom actions? – Christopher Painter Mar 10 '19 at 16:44
  • No custom actions. – user0000001 Mar 10 '19 at 16:50
  • Do you have registry settings for the service? – Stein Åsmul Mar 10 '19 at 17:14
  • @SteinÅsmul I do have registry settings. I can update OP if necessary. – user0000001 Mar 10 '19 at 22:07
  • Please do update your question. And maybe [have a quick skim of the "debugging ideas list"](https://stackoverflow.com/a/53530377/129130). I'll be away for a little while. – Stein Åsmul Mar 10 '19 at 22:11
  • @SteinÅsmul You may have just pointed me to my problem. I am updating OP to show you the issue. Cheers to you. For whatever reason, the update is writing a `REG_SZ` causing the service to fail on start. It is strange because once it installs completely, the registry key is updated to a `DWORD`. Odd behavior. If you update your answer in regards to verifying the service even starts during the installation, I will accept the answer. – user0000001 Mar 10 '19 at 22:15
  • That sounds strange indeed. Can we see the WiX source? (snippet for that key)? – Stein Åsmul Mar 10 '19 at 22:18
  • What's writing to the registry? WiX or the service? Is it writing the value of a property? – Christopher Painter Mar 11 '19 at 02:07