自我修复,简单而简短的说明:如果我删除文件,为什么 MSI 安装程序会重新配置?
WiX / MSI 文件的具体设计建议
我一直在尝试写关于为开发人员重复 MSI 自我修复的文章,但最终写得太详细了。这是我的最后一次尝试:关于在 WiX/MSI 文件中不应该做什么的具体设计建议。
下面的答案提供了一个用于解决任何自我修复方案的清单- 来自任何供应商或来源,而不仅仅是您自己的。检查上面链接的答案,了解您自己的 MSI 封装设计问题。
“短版” - 自我修复清单
为了永久且可靠地为每个人修复自我修复问题,开发人员和设置开发人员必须参与其中,因为真正的修复必须在供应商级别进行。
如果您在企业环境中,质量差的应用程序重新打包也会导致自我修复问题,您应该让您的应用程序打包人员确定问题是否来自供应商。
系统管理员必须知道他们在看什么,并且当没有可用的修复程序时,使用各种变通方法来处理野外的问题。甚至最终用户也可以自己尝试一些简单的解决方法(参见第 5 节)。
自修复问题的本质:
- 大多数自我修复问题与 COM 相关,供应商和开发人员有两个通用修复:1 ) 使用通常通过合并模块部署的正确部署的共享 COM 库,或 2) 使用无注册 COM 来“屏蔽”您的应用程序自修复和兼容性问题。
- 您的设置开发人员可以实施合并模块修复,开发人员必须进行测试。合并模块是用于共享文件的标准化共享部署库。
- 根据我的经验,无注册 COM仅适用于开发人员参与。如果开发人员需要使用特定版本的 COM 文件(无论出于何种原因),此选项尤其重要。详情见下文第 5.4 节。
- 除了 COM,您还可以通过让安装程序开发人员在您的MSI 安装程序中注册文件和MIME 关联以及命令动词来导致自我修复问题。谨慎使用,并确保您的文件/MIME 关联是唯一的。
- 最后,您可以通过两个已安装的 MSI 文件之间的任何文件或注册表冲突导致自我修复。他们“错误地共享资源”并将其视为自己的资源 - 与之抗争直到冲突解决。
- 一些自我修复问题根本不是由供应商应用程序或设置中的错误引起的,而是由相关计算机环境中的外部因素引起的,例如修补用户、脚本、病毒、防病毒或安全软件的干扰。有关详细信息,请参阅第 3 节。
处理问题应用程序的快速选项
如果您确定您看到的自我修复仅由 MSI 引起(而不是由下面前几节中描述的其他外部原因引起),也许可以直接跳到第 5 节以获取建议的修复和解决方法的列表。
第 5 节中提出的大多数“解决方案”实际上主要是系统管理员的技巧,它们不能解决根本问题——如上所述,真正的解决方案必须来自供应商。例外是“5.4:无注册COM”,它实际上可以帮助开发人员“保护”他们的应用程序免受自修复问题。
如果您的盒子没有管理员权限,建议您尝试“解决方案” 5.2、5.3或5.1 (5.1通常需要管理员权限才能尝试,但并不复杂)。这些是“快速解决方法”,其他涉及更多。如果这些解决方法不起作用,请让您的管理员阅读其他建议。
了解 Windows Installer 自我修复
我之前已经详细写过这个问题,但它过于关注理解问题,而不是真正找到可接受的解决方案。您可以在此处阅读自修复问题的完整说明:如何确定导致 Windows Installer 重复自修复的原因?.
修复 Windows Installer 自我修复问题
要真正修复重复和无休止的自我修复,您可以尝试以下第 5 节中的建议 - 按复杂性和难度递增的顺序排列。在这样做之前,您应该验证自我修复问题的真正根源是什么。它可能不是由 MSI 文件引起的,而是由其他外部原因引起的(例如脚本或用户删除文件或防病毒阻止文件)。
如果问题确实与 MSI 相关,您可以尝试禁用广告的快捷方式和COM 插件,使用无注册 COM,从应用程序供应商处获得帮助,卸载有问题的应用程序,虚拟化包或完全破解缓存的 MSI 数据库和注册表(不推荐,只有在专家帮助下才有可能)。这完全取决于您的情况。如果脚本等外部原因出现故障,则必须消除这种干扰。请参阅下面的详细信息 - 只需按照清单进行操作。
解决问题的第一步是确定问题确实存在于您的平台上,然后首先确定哪些应用程序触发了自我修复:
1.验证您的环境中确实存在问题。
- 通常总是可以找出导致有问题的自我修复的原因,并且有几种可行的解决方法可用于处理该问题。然而,并不总是能够找到一个好的、永久的修复(没有供应商的帮助 - 如下所述)。
- 因此,如果您是一名系统管理员,试图为您的自我修复问题找到解决方案,也许要确保在不止一台计算机上发现问题 - 特别是如果在开发人员、QA甚至测试中发现问题时电脑。
- 如果您只在一台计算机上看到自我修复问题,另一种方法可能是重建有问题的计算机。有效地消除而不是“解决”问题。但是,您可能会再次看到该问题的风险相对较高。如果你问我,不要重建,这不是解决方案 - 但我猜在现实世界中往往会做些什么。
- 请注意,安装速度缓慢且不断被用户中止的AD 宣传的 MSI 安装可能“看起来像”桌面支持的自我修复问题,但这是预期的 MSI 行为。允许安装完成一次(可以更改安装程序进度条以禁用取消按钮 - 类似于只有进度条,没有取消按钮,最后没有模式对话框)。
msiexec.exe /I "MyApp.msi" /QB-!
2.找出自我修复的罪魁祸首。
- 单个应用程序可能会自行导致问题,但通常至少有两个应用程序发生冲突(它们错误地共享某些资源)。
- 自修复的触发器通常可以在发生自修复的系统上的事件查看器中找到。按照以下步骤打开事件查看器:
- 右键单击“我的电脑”
- 点击管理
- 如果收到 UAC 提示,请单击继续
- 转到事件查看器部分,然后检查 Windows 日志
- 通过查看事件日志的“应用程序部分”,在Windows 事件日志中识别有问题的应用程序,您应该会发现来自ID 为 1001和1004的事件源“ MsiInstaller ”的警告。
3.验证外部非 MSI 原因不是导致问题的原因
- 手动或自动删除文件或注册表设置的任何操作都可以触发 MSI 自我修复。尤其是当您在用户配置文件或注册表的 HKCU 部分中删除内容时弄乱了。
- 在大多数情况下,此类触发器只会导致一次自我修复运行,然后问题就解决了(这就是自我修复应该如何工作并帮助用户)。允许自我修复运行一次,然后再次启动应用程序以测试问题是否消失。它应该是,并且您的应用程序应该从现在开始正确启动。
- 特殊情况:具有讽刺意味的是,您有时可以通过重命名其 HKCU 应用程序密钥(在注册表的用户部分中)来修复损坏的应用程序,以实际强制自我修复运行并在用户配置文件中安装应用程序的默认数据 - 如果该数据是意外的已删除(这种类型的修复程序通常不适用于终端服务器)。
- 如果通过自动方式再次删除相同的文件或注册表项并自行修复结果,您必须消除或更新导致它的自动过程并且您的问题得到解决并且您可以停止阅读。如果您自己再次手动删除了该文件,那么您可能会遭受记忆不佳的困扰:-)。
- 总之,清理脚本、登录脚本、清理应用程序或修补,过度活跃的用户都可能导致这种自我修复。
- 最后,病毒和防病毒软件(和其他安全软件)可以阻止对文件的访问并触发永远不会成功的自我修复。
- 对于受感染的计算机,只需重建计算机。这将节省您的整体时间。
- 对于防病毒/安全软件问题,请带您的安全人员来解决它。在某些情况下(尤其是误报),他们可能需要联系供应商。
- 无论是病毒还是反病毒相关,请检查http://www.virustotal.com上的违规文件,以验证它是否真的是病毒或只是误报(这可能是自我修复的更大问题)。
- 我个人见过几个防病毒/安全软件相关的自我修复问题,但没有真正的病毒相关问题(到目前为止)。我猜病毒通常感染核心系统文件而不是应用程序文件,并且核心系统文件不是由MSI文件部署的(共享系统文件可能包含在MSI文件中,但不包含核心系统文件)。
4.联系供应商(或您自己的包装部门)。
5.选择“解决方法”或修复来处理冲突情况。
6.总结与结论
- 第 4 步-联系供应商进行修复-在我看来
是唯一的“真正的修复”。
- 所有其他提案都试图处理由供应商错误导致的问题,而不是提供持久的解决方案。
- 现实世界的问题是许多供应商倾向于互相指责,所以你可能不走运。一些做得对的供应商确实会遭受其他人的设计错误。
- 提案5.1、5.2、5.3是不复杂的“解决方法”。
- 应该安全地为每个人尝试。
- 即使没有管理员权限,建议5.2和5.3也应该可以尝试。
- 提案5.4 -无注册 COM - 是一个相当复杂的潜在“修复”。
- 可能需要开发人员参与才能找到要“隔离”的所有相关文件。
- 以我的经验,这种项目最终需要几天的时间才能尝试(即使有专家的帮助)——没有真正保证它最终会奏效。
- 我从专家那里听到了相互矛盾的事情,有些人成功了,有些人说它失败了。有权访问解决方案源的人似乎成功了。
- 就我个人而言,我不喜欢它打开的潜在安全漏洞,并且要部署的任何新文件版本都可能意味着新一轮的清单重新创作(我相信)。
- 然而,有问题的 COM 文件现在太旧了,无论如何他们都不太可能看到对它们进行的任何安全更新。我想这些 COM 对象现在主要用于 .NET 互操作。
- 提案5.5 -虚拟化- 目前是一个常见的选项,如果在环境中可用,可能应该在 5.4 之前尝试。俗话说,“虚拟化,认真”。
- 老实说,我不知道(缺乏经验)虚拟化是否适用于(办公室)插件。如果可以确认请更新。
- 可执行文件绝对可以虚拟化。
- 提案5.6 - “缓存 MSI 调整” - 是一种“黑客”,如果部署专家正确完成,它可以“足够好”地工作。
- 有一些“副作用”,特别是对于卸载- 以及“弹性”,但如果操作正确,这些应该是可以管理的。
- 这是“真实世界”——没有什么是“干净的”。
提案5.7 - “ zapping MSI ” - 是一个不安全的、已弃用的“遗留黑客”。
由于系统的“脏状态”,有几个副作用。
运行 MsiZap.exe 后报告了 MSI 数据库完全损坏。