使用 WiX 进行重大升级后无法启动 Windows 服务
Failing to start Windows service after a MajorUpgrade with WiX
我有一个非常简单的 WiX 项目。没有什么花哨。当尝试对现有安装执行 MajorUpgrade 时,它无法启动服务并且不可避免地回滚到以前的版本并正常启动服务。我已经删除了 Start="install"
并成功手动启动了应用程序,所以我知道这不是依赖性问题。
我进行了无休止的搜索,但没有找到解决我问题的方法。
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." Schedule="afterInstallFinalize" />
我的服务安装:
<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" />
我将 MSI 日志转储到文件中并收到此错误,但它非常模糊。
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
安装过程中有一些注册表修改。安装程序尝试从注册表中读取并继承已经存在的值。
<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>
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:
通用检查表:如果上面的 none 做了任何事情,也许试试这些 "torpedoes full spread" check-lists
(只是开始调试的想法):
- Desktop applicaton not opening after installation in client system
- Windows Application Startup Error Exception code: 0xe0434352
通用调试:引入一些通用调试方法。
- 自定义操作调试:
- 依赖扫描: Which winform project files should be packed up into the installer
一些进一步的链接:
- C# Debug folder when copied to another location does not run the exe
这当然可能是一个依赖性问题。例如,GAC / WinSXS 文件直到 StartServices 之后的提交阶段才会安装到 GAC 中。
我会保留 Start="Install",当它处于无法启动提示时检查机器状态并手动调试服务启动。我敢打赌你会发现缺少的东西。
我有一个非常简单的 WiX 项目。没有什么花哨。当尝试对现有安装执行 MajorUpgrade 时,它无法启动服务并且不可避免地回滚到以前的版本并正常启动服务。我已经删除了 Start="install"
并成功手动启动了应用程序,所以我知道这不是依赖性问题。
我进行了无休止的搜索,但没有找到解决我问题的方法。
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." Schedule="afterInstallFinalize" />
我的服务安装:
<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" />
我将 MSI 日志转储到文件中并收到此错误,但它非常模糊。
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
安装过程中有一些注册表修改。安装程序尝试从注册表中读取并继承已经存在的值。
<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>
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" aDWORD
value found via aRegistrySearch
operation to a formatted string -REG_SZ
- during upgrade installations (could be more involved too). This causes services that expect aDWORD
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
andREG_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 onlyREG_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:
通用检查表:如果上面的 none 做了任何事情,也许试试这些 "torpedoes full spread" check-lists
(只是开始调试的想法):
- Desktop applicaton not opening after installation in client system
- Windows Application Startup Error Exception code: 0xe0434352
通用调试:引入一些通用调试方法。
- 自定义操作调试:
- 依赖扫描: Which winform project files should be packed up into the installer
一些进一步的链接:
- C# Debug folder when copied to another location does not run the exe
这当然可能是一个依赖性问题。例如,GAC / WinSXS 文件直到 StartServices 之后的提交阶段才会安装到 GAC 中。
我会保留 Start="Install",当它处于无法启动提示时检查机器状态并手动调试服务启动。我敢打赌你会发现缺少的东西。