使用WiX進行MajorUpgrade后無法啟動Windows服務

Question

我有一個非常簡單的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>

Answer 1

調試結果 ：經過大量調試（由原始海報-OP進行），結果證明是此處描述的已知MSI問題： https : //wix-users.narkive.com/EMfQPDrM/a-bug-get-reg-sz -使用類型整數時 。 不錯的搜索工作。

DWORD中有什么？ （顯然是REG_SZ ）：本質上，MSI在升級安裝過程中將通過RegistrySearch操作找到的DWORD值“轉換”為格式化的字符串REG_SZ （可能涉及更多）。 這會導致期望DWORD值的服務在重大升級期間在啟動時掉落。 一個非常奇怪的錯誤 。

解決方法 ：通過使服務代碼能夠讀取DWORD和REG_SZ可以嘗試“解決”此問題。 與在自定義操作中解決問題相比，這提供了一種更健壯的解決方案，因為只要其中有代碼（這是存在的代碼，就會向其他開發人員發出有關該問題的警報），它便是“永久性”修復程序。 或者也許只使用REG_SZ ？

---

快速檢查 ：很明顯，請檢查服務密碼並登錄 。 事件查看器中有任何內容嗎？ Windows鍵 +點擊R + eventvwr.msc + Enter 。 如何使用事件查看器對Windows Service問題進行故障排除 。 也許您可以嘗試對之前和之后的文件夾進行文件夾比較 ，看看是否在配置文件中看到了意外情況？ 自然會有很多二進制差異，但是請檢查文本文件（也可以編碼）。 再次檢查MSI日志文件 ，然后按照此處所述搜索"value 3" ： 檢查MSI日志文件的提示 。 Manually copy the new files in place and attempt to start the service via the services.msc applet 。

---

服務專家 ： Windows服務常見問題解答（FAQ） 。 內容似乎是最新的-至少以面值計。 這些家伙自稱是服務專家。 我不知道他們是誰。

查看上方鏈接中的“錯誤”部分 。 以下是一些摘錄：

• 1053：服務未及時響應啟動或控制請求
• 重新啟動后，為什么Windows服務沒有自動啟動？
• 1069：由於登錄失敗，服務未啟動

---

通用檢查清單 ：如果以上都不做任何事情，請嘗試以下"torpedoes full spread" check-lists （只是開始調試的想法）：

• 在客戶端系統中安裝后，桌面應用程序無法打開
• Windows應用程序啟動錯誤異常代碼：0xe0434352

---

通用調試 ：拋出一些通用調試方法。

• 自定義操作調試 ： WIxsharp在控制台中調試自定義操作
• 依賴項掃描 ： 應該將哪些winform項目文件打包到安裝程序中

---

其他鏈接 ：

• C＃調試文件夾復制到另一個位置時無法運行exe
• wix服務安裝權限不足
• WiX“服務安裝”在內部如何工作？
• WiX Toolset PermissionEx問題-安裝后應用無法運行

Answer 2

當然，這可能是一個依賴性問題。 例如，GAC / WinSXS文件直到StartServices之后的提交階段才安裝到GAC中。

我將把Start =“ Install”留在其中，當它坐在無法啟動的提示下，檢查計算機的狀態並手動調試服務啟動。 我敢打賭，您會發現缺少的東西。