【问题标题】:WiX 3.0 throws error 217, while being executed by continuous integrationWiX 3.0 在通过持续集成执行时​​抛出错误 217
【发布时间】:2026-02-19 14:25:01
【问题描述】:

这是我们的自动构建套件在 Windows 2008 上运行 ICEs(从 WiX 2.0 迁移到 WiX 3.0 之后)时引发的错误:

LGHT0217:执行 ICE 操作“ICE01”时出错。这种 ICE 故障的最常见原因是错误注册的脚本引擎。有关详细信息以及如何解决此问题,请参阅http://wix.sourceforge.net/faq.html#Error217。外部 UI 消息记录器不希望出现以下字符串格式:“无法访问 Windows Installer 服务。如果未正确安装 Windows Installer,可能会发生这种情况。请联系您的支持人员寻求帮助。”。在 light.exe(0, 0) 中

此外,这些是显示在事件日志中的错误:

MSIInstaller:无法连接到服务器。错误:0x80070005 产品:[ProductName] -- 错误 1719。无法访问 Windows Installer 服务。如果未正确安装 Windows Installer,则可能会发生这种情况。请联系您的支持人员寻求帮助。

直观地说:

  • VBScriptJScript 在 admin 下注册。
  • 集成服务拥有桌面交互和所有文件的权限
  • 当其他用户或什至以集成帐户登录的用户(通过RDP)在同一台机器上手动执行时,构建成功

到目前为止,我没有任何想法。

如何在保持 ICE 验证的同时解决此问题?

【问题讨论】:

  • 错误消息中的常见问题解答网址已损坏...

标签: continuous-integration wix build-automation wix3


【解决方案1】:

故事结束

在摆弄了集成账户的权限、DCOM、服务激活等都没有任何运气之后,我终于在持续集成构建中简单地禁用了 ICE 验证,同时仍然保留在本地构建中。

要禁用 ICE 验证,您可以在 .wixproj 文件中将 SuppressValidation 设置为 true:

    <PropertyGroup>
        <SuppressValidation>true</SuppressValidation>
    </PropertyGroup>

或者将-sval 命令行选项传递给light.exe

【讨论】:

  • 您是如何禁用 ICE 验证的?
  • 这不是一个真正的答案,而是一个不太好的解决方法。
  • 也许这不是一个好的解决方法,但这是我发现生成 MSI 的唯一方法。所以谢谢 Rinat!
  • 对于将此答案视为可行解决方案的其他人,您应该了解,违反 ICE 可能会给您在尝试遵守 f.ex msdn.microsoft.com/en-us/library/windows/desktop/… 以及生产现场正式检查时带来麻烦。简而言之。不要通过禁用 ICE 检查来解决您的问题。
  • 无论是搞乱环境还是给我的构建代理用户管理员权限对我来说都不起作用。 WiX Toolset issue 3968a post by Rob Mensching on WiX-Users 都表示唯一可靠的解决方法是禁用 ICE。像WiX's ICE Breakers project 这样的东西总有一天会解决问题。
【解决方案2】:

将 TFS 构建控制器帐户添加到本地管理员组并重新启动 Windows 服务为我完成了这项工作。

【讨论】:

  • 但这违反了 Team Build 最佳实践,请参阅:msdn.microsoft.com/en-us/library/dd578625
  • 我同意这是一种不好的做法,并不是我个人喜欢做的事情,但它是两害相权取其轻。为您的 MSI 完全禁用 ICE 验证,而不是让构建帐户成为管理员。
  • 为了进一步反思@Jeff 的评论,这确实是一个明显的选择:花时间在内部网上正确保护构建机器,或者禁用可能破坏诸如“为 Windows 服务器设计”之类的检查" 标志验证。
  • 最好了解需要哪些确切权限而不是授予完整的管理员角色...
  • 我公司不允许这样做。正如 Ivan 上面评论的那样,有人知道需要哪些确切的权限吗? (顺便说一句,我们暂时尝试了这个建议的解决方案,它奏效了)
【解决方案3】:

我找到了根本原因。我尝试了所有找到的方法,包括类似于 Re: [WiX-users] light.exe failed randomly when running ICEs. 中发布的自定义验证器扩展。

这不是各种线程中建议的并发问题。这是由过大的进程环境块 (PEB) 引起的。

事实证明,Windows Installer 无法处理大于 32 kB 的进程环境块。在我的环境中,由于构建系统设置的变量数量及其大小(例如,PATH variable 包含多个重复值),PEB 约为 34 kB。

有趣的是,根据 Environment Variables,Windows XP 和 2003 将 PEB 的硬限制设置为 32 KB。这可能会在构建的早期阶段导致易于捕获的构建中断。较新的 Windows 没有这样的限制,但我猜 Windows Installer 开发人员将其内部环境缓冲区限制为 32 kB,并在超过该值时优雅地失败。

问题很容易重现:

  • 创建一个 .bat 文件,用于设置大小超过 32 kB 的环境变量。比如可以是32行set Variable&lt;number&gt;=&lt;text longer than 1024 characters&gt;
  • 启动 cmd.exe
  • 执行您创建的批处理文件
  • 从同一个 cmd.exe 窗口:
    • 尝试使用 WiX 构建 MSI 包,并在 OR 上进行 ICE 验证
    • 运行 smoke.exe 以验证您的包或
    • 只需运行msiexec /i Package.msi
  • 以上所有命令最终都会报告Error 1719 - Windows Installer could not be accessed

因此,解决方案是 - 检查您的构建脚本并减少环境变量的数量和大小,使它们都适合 32 kB。您可以通过运行轻松验证结果:

set > environment.txt

目标是使文件 environment.txt 小于 ~30 kB。

【讨论】:

  • 这似乎也是我遇到的问题。我怀疑并发,但没有足够的 MSI 并行构建。非常感谢分享这个解决方案。很想知道你最终是如何调试它的。
  • 我认为您的意思是这是问题的原因之一,因为我的环境变量小于 2K。
  • 也为我工作,谢谢。但我的门槛更低。 6KB(-> 5900 个字符)有效。 10 KB(-> 9300 个字符)显示错误。在 electron-builder 20.39.0 中在 Windows Server 2016 上运行
  • 我的 environment.txt 约为 7 KB。所以这可能不是问题所在。 ?
  • 也为我工作:我使用 CSC_LINK variable with base64-encoded certificate 使用电子生成器,导致环境太大。为了解决这个问题,我将证书存储在一个文件中,并将 CSC_LINK 设置为证书文件名。
【解决方案4】:

问题的正确描述(没有解决方案,除非将CruiseControl帐户添加到本地管理员组可以作为解决方案传递):

引用自Wix 3.5 & Cruise Control gives errorLGHT0217

ICE 验证需要一个交互式帐户或管理员权限 快乐的。参见例如 WiX Projects vs. TFS 2010 Team Build (2009-11-14) 或 Re: [WiX-users] Help with building patch (2009-11-20)。

【讨论】:

    【解决方案5】:

    imagi 完全正确!我不敢相信这是真正的答案。禁止验证并使 TFS 用户成为管理员不是好的解决方案。另外,我找不到 NT\Authority 将其添加到管理员组,并且完全陷入了困境。

    我在 Windows Server 2012 Datacenter 上遇到与 Build Agent 相同的错误。 解决问题:

    1. 列表项
    2. 转到构建代理计算机上的环境变量
    3. 创建两个系统变量
    4. "PF86" 等于 "C:\Program Files (x86)"
    5. "PF" 等于 "C:\Program Files"
    6. 它们很短,因为我想保存字符。我制作它们时没有最后的反斜杠,因为 TEMP、TMP 和其他都是这样制作的,我决定对这些变量坚持 MS 标准。
    7. 编辑 PATH 变量,将每个 "C:\Program Files (x86)" 替换为 %PF86%,将每个 "C:\Program Files" 替换为 %PF%
    8. 关闭并构建并享受!
    9. 它对我有用。 :)

    更新 我找到了一个更好的解决方案:Rapid Environment Editor 将为您完成所有这些工作,甚至更多。自动。

    【讨论】:

      【解决方案6】:

      来自http://wix.sourceforge.net/faq.html#Error217

      在 WiX v3 中,Light 自动运行验证—— Windows Installer Internal Consistency Evaluators (ICEs) --在每次成功构建之后。验证是一个 捕获可能导致服务问题的常见创作错误的好方法, 这就是为什么它现在默认运行的原因。不幸的是,有一个常见的问题 在 Windows Vista 和 Windows Server 2008 上发生的可能导致 ICE 失败。有关原因和解决方法的详细信息,请参阅 Heath Stewart's BlogAaron Stebner's WebLog.

      【讨论】:

      • 该链接中的任何内容是否真的可以帮助您解决此问题?
      • 这对我不起作用。我有一个 2008 R2 x64 的全新服务器,并且 dll 在 HKLM 而不是 HKCU 下注册。
      • 这两个链接都失效了。请在答案中包含实际假设的解决方案。
      • 这里有一个链接。 devblogs.microsoft.com/setup/…
      【解决方案7】:

      我遇到了同样的 ICE 错误,但问题变成了 Windows Installer 服务损坏。 这个解决方案对我有用: http://support.microsoft.com/kb/315353

      1. 以管理员身份登录您的计算机。
      2. 点击开始,然后点击运行。
      3. 在“打开”框中,键入 cmd,然后单击“确定”。
      4. 在命令提示符下,键入 msiexec.exe /unregister,然后按 Enter。
      5. 键入 msiexec /regserver,然后按 Enter。
      6. 重启 Windows

      另外,请验证 SYSTEM 帐户对 Windows 注册表中的 HKEY_CLASSES_ROOT 配置单元。在某些情况下,您可能还需要添加管理员帐户。

      【讨论】:

        【解决方案8】:

        我遇到了同样的问题,不喜欢取消 ICE 验证。我的设置:我使用自己的计算机作为 Visual Studio Online (VSO) 上的构建代理。我的解决方案是更改用于在我的机器上运行服务的帐户。我没有使用网络服务或本地服务,而是使用我自己拥有所有必要权限的帐户登录服务。

        【讨论】:

        • 这正是发生在我身上的事情。运行构建服务的帐户存在权限问题。我更改了用户,现在构建通过了
        【解决方案9】:

        我有一些建议。

        • 尝试更新构建服务器上的 Microsoft Installer 版本
        • 确保您使用的是最新版本的 WiX 3.0,因为它现在是稳定的 3.0 版本。
        • 如果所有其他方法都失败了,请尝试在特定的构建用户下运行构建服务,您可以为该用户设置权限...

        【讨论】:

        • 1.是的; 2. 最新; 3. 我可以更改集成帐户的权限。
        • 尝试将构建用户添加到 DCOM 本地用户组。
        • 当时没用。我最终在集成构建中禁用了 ICE 验证。
        【解决方案10】:

        转到您的构建机器并重新启动 Windows Installer 服务

        【讨论】:

          【解决方案11】:

          以上建议均不适合我,对我来说,防病毒 (mcafee) 出现在图片中,看起来它将 vbscript.dll 注册表项更新到了错误的 DLL 位置。这些是要记住的事情:

          1. 部分 WiX ICE 验证是使用 VBSCRIPT 实现的。
          2. 因此在编译 MSI 时,构建服务器需要访问 c:\windows\system32\vbscript.dll。
          3. 运行您的构建的用户可能会以某种方式失去对该 DLL 的访问权限。
          4. 如上述答案中所述,请务必查找管理员访问权限/注册表访问权限,并确保您的用户拥有该权限。

          以下是我为解决此问题而采取的步骤:

          1. 在构建代理机器上打开 cmd(以管理员身份运行)。
          2. 运行 RegEdit
          3. 选择根目录,然后单击 ctrl + f 并搜索以下注册表项:{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
          4. 查找 InprocServer32\Default 键

          1. 在我的构建代理上,路径被替换为 mcafee DLL 位置。我将路径更新回 c:\windows\system32\vbscript.dll
          2. 编辑注册表项并不容易,因为它是一个受保护的注册表项。在编辑属性之前,我使用以下链接更改了访问权限:Edit protected registry entry

          一旦我更新了路径,一切就开始照常工作了。

          【讨论】:

            【解决方案12】:

            我的解决方案类似于 Vladimir 的解决方案。我的 CI 用户是计算机的管理员。

            但是为了让我的詹金斯构建成功,以下步骤是强制性的:

            • 使用 rdp 以 CI 用户身份登录
            • 打开一个dos命令提示符
            • 执行:%windir%\system32\msiexec.exe /unregister
            • 执行:%windir%\system32\msiexec.exe /regserver

            然后我得到了一份成功的工作

            【讨论】:

              【解决方案13】:

              我从本地运行的 Azure 构建代理收到此错误。 我的解决方案是将其用户帐户从“网络服务”升级为“本地系统帐户”。

              【讨论】: