启动应用程序触发重复无休止的Windows Installer自修复时，我该怎么办？

自修复，简单简短解释：如果删除文件，为什么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事件日志，通过查看“ 应用程序部分的事件日志”，你应该找到从事件源“警告MsiInstaller ”与编号1001和1004。您可以在以下更详尽的答案中找到有关如何执行此操作的更多详细信息：如何确定导致Windows Installer重复自我修复的原因？。在“ 查找自我修复的触发因素或罪魁祸首 ”部分中查找。您也可以尝试从咨询独立部署专家，MSI-专家和MVP斯特凡·克鲁格。他有一篇关于同一自我修复问题的文章。他至关重要地讨论了实际的事件日志条目及其含义。请在此处阅读有关实际调试过程的信息。3. 验证外部非MSI原因不是引起问题的原因任何手动或自动删除文件或注册表设置的操作都可以触发MSI自修复。尤其是在您要删除用户个人资料或注册表的HKCU部分中的内容时。在大多数情况下，此类触发器只会导致运行一次自我修复，然后问题得以解决（这是应该进行自我修复并为用户提供帮助的方式）。允许自我修复运行一次，然后再次启动应用程序以测试问题是否消失。应该是这样，并且您的应用程序应该从现在开始正确启动。特殊情况：具有讽刺意味的是，有时您可以通过重命名HKCU应用程序密钥（在注册表的用户部分中）来修复损坏的应用程序，以实际上强制自我修复在用户配置文件中运行并安装该应用程序的默认数据-如果该数据是偶然的已删除（此修复程序通常在终端服务器上不起作用）。如果同一文件或注册表项再次通过自动方式删除并导致自我修复，则必须消除或更新引起该问题的自动过程，并且问题已解决，您可以停止阅读。如果您自己再次手动删除了文件，则可能会遇到内存不足的问题:-)。总之，清理脚本，登录脚本，清理应用程序或修补程序，活动过度的用户都可能导致这种自我修复。最终，病毒以及防病毒软件（和其他安全软件）会阻止对文件的访问并触发永远无法成功进行的自我修复。对于受感染的计算机，只需重建计算机即可。它将为您节省总体时间。对于防病毒/安全软件问题，请请安全人员来解决。在某些情况下（特别是误报），他们可能需要与供应商联系。无论是与病毒还是与反病毒有关，请检查http://www.virustotal.com上的有问题的文件，以确认它实际上是病毒还是假阳性（这可能是自我修复的更大问题）。我个人已经看到了一些与防病毒/安全软件有关的自我修复问题，但到目前为止还没有真正的与病毒有关的问题。我猜病毒通常会感染核心系统文件而不是应用程序文件，并且核心系统文件不会由MSI文件部署（共享的系统文件可能包含在MSI文件中，而不包含在核心系统文件中）。4. 与供应商（或您自己的包装部门）联系。一旦确认自我修复问题是基于MSI的，而不是您自己的软件，首先要尝试的是与应用程序供应商联系，并查看他们是否具有更新的安装程序来消除该问题。尝试此选项非常重要，因为所有其他选项都是“变通办法”，而不是真正的解决方案。只有通过更改供应商安装程序以及可能的应用程序可执行文件才能永久完全解决该问题。修补程序1：修补程序很简单，只需让供应商使用适当的共享“ 合并模块 ” 删除私下安装但已全局注册的COM文件，即可为所有人正确安装运行时。这些应将COM文件正确安装到共享位置，在此处可以进行全局注册而不会产生副作用。准备好供大家使用。修复2：如果供应商声称这是不可能的-那么他们应该能够提供正确的无注册COM安装，并在主应用程序文件夹中安装正确隔离的COM文件。他们还应随时注意部署任何安全更新。重要！：如果供应商使用正确的共享合并模块来部署文件，或者使用无需注册的COM提供隔离安装，则该问题应为每个人永久解决。该问题也可能是由其他问题引起的，但COM通常是罪魁祸首。有时清理他们的MSI安装程序可以解决其他更晦涩的冲突。如果您知道一个好的应用程序包装商，则他/她应该能够快速识别冲突（并为供应商提供反馈）。请注意，自我修复也可能是由供应商软件的错误（内部）重新包装引起的。在这种情况下，您可以通过自己的打包/部署部门提供的更新来修复自己的软件包（在大多数情况下，他们肯定应该能够实现此目的）。这实际上是一个非常普遍的问题。5. 选择一种“解决方法”或解决此冲突情况。如果供应商不提供固定的安装程序包，则需要找到“替代方法”来解决这种情况。有多种选择，在探究过多的复杂性之前，应尝试一些“ 快速解决方法 ”。以下是一些解决问题的建议，以提高难度和复杂度的顺序：如果问题对于您的桌面环境非常严重，并且以上选项均无效，则可以尝试在Windows Installer级别解决此问题。如果外接程序（或任何其他软件）对于在公司的主PC环境中可用至关重要，则可能是值得的。本质上，您需要做的是从系统缓存的MSI和/或注册表中删除有问题的条目（禁用广告的入口点，例如广告的快捷方式，COM注册，文件关联，MIME关联或命令动词等）。这涉及很多，不是很好的做法，并且有一些副作用（如卸载，弹性等），但这是我所知道的唯一的“最后手段”。在这些情况下，建议您与部署/ Windows Installer专家联系，并让他们分析是否可以进行“修复”。它可以工作，但不要指望奇迹。如果您坚持自己进行调试，则需要掌握一种工具来打开系统上的缓存MSI文件（例如Orca，Installshield，Advanced Installer或类似文件），并且需要“破解”数据库-不推荐。除了卸载或禁用组件外，最简单的解决方法可以说是使用虚拟化来“隔离”发生冲突的应用程序。如果仍然需要将应用程序放在主SOE（标准操作环境）上，则可以尝试使用虚拟部署程序包（APP-V）。这是一个基本上按需安装（在启动时）并运行“沙盒”或与系统中其他应用程序隔离的应用程序。您还可以通过VMWare或Microsoft Virtual PC等系统使用虚拟机，以在其自己的操作系统中运行有问题的应用程序。人们在使用虚拟机时通常具有管理员权限，但不在其主SOE系统（主工作站）上。许多开发人员应用程序更有效地使用管理员权限，因此在与开发团队及其需求打交道时，此解决方案可能特别有用。可以说，该解决方案比虚拟化（在下一个要点中进行介绍）要复杂得多，但是我将其放在此处，因为它可能是某些人的首选。免注册COM是我很少使用的东西，但是据说它是一种可行的解决方案：为免注册COM生成清单文件。这实际上绕过了注册表，并激活了由放置在应用程序可执行文件旁边的清单文件控制的COM文件的私有副本-有效地保护了应用程序免受COM注册表干扰（理论上）。“所有事情都发生在同一文件夹中”。您的内部包装部门也许可以使用它来处理“困难的供应商包装”，以“隔离”他们的问题。但是，我不相信无需注册的COM就能在原始解决方案开发人员做出一些其他应用程序调整的情况下正常工作，但是我缺乏经验数据来支持它。如果它是具有可用源的内部应用程序，请对其进行测试（并告诉我们）。我的主要问题这种方法，就在于它打开了潜在的安全漏洞（也永远不会被微软补丁的COM文件传抄），如果不确保隔离组件自己更新。更新也可能会导致很多清单重写工作（但是这些旧的COM文件是否仍会更新吗？）请注意，至少从理论上讲，无注册COM可以用于所有与COM相关的冲突，无论它们是VB6可执行文件，使用COM的VC ++应用程序，等等。 COM插件（dll）和VBA表单。这似乎是关于无注册COM的MSDN更好的文章之一：https : //msdn.microsoft.com/en-us/library/ms973913.aspx（甚至还有带有示例的可下载MSI-其中具有讽刺意味的是，启动时似乎触发了我一个错误。就我个人而言，我可能宁愿尝试使用APP-V来尝试虚拟软件包，而不是尝试使用无需注册的COM（请参阅下一个要点）。需要重申的是，与其“屏蔽”自己的应用程序，不如说正确的供应商修补程序是停止部署在系统范围内错误注册的共享COM文件的私有副本，并使用适当的合并模块按计划开始安装它们。部署。如果您的问题涉及到的加载插件（用于Outlook，Excel和Word或其他应用程序，如AutoCAD或类似的），那么有没有捷径可调整-该插件加载上推出了其“宿主应用程序”的。最简单的尝试是在有问题的应用程序（通常是Outlook，Excel或Word或类似的应用程序）的“插件”对话框中禁用不需要的任何插件，然后查看是否可以解决问题。在某些情况下，您只是禁用了用户最初从未使用过的COM加载项，因此问题已消除。而且，很显然，还尝试禁用您实际需要的插件，以便检查问题是否可能与其加载有关。如果外来元凶是罪魁祸首，则应继续检查清单中的下一个提议的解决方案（下一个要点）。我应该重申，首选解决方案是供应商提供的修复程序（大多数情况下，它将涉及使外接程序正确使用所涉及的最新的共享ActiveX / OCX控件-但是，其他外接程序仍可能触发问题。您可能最终会与多个供应商打交道-通常会互相指责）。为了公平起见，如果您使用的是公司计算机，则问题也可能是由于公司应用程序重新包装不正确而引起的。然后，您必须与包装部门联系以寻求修复。尝试使用的Windows Installer的第一种解决方法是删除“ 广告的快捷方式 ”（本质上是一种特殊类型的快捷方式，它指向Windows Installer应用程序功能，而不直接指向可执行文件或文件）。阅读Symantec的链接文章，以了解有关宣传的快捷方式的详细信息。然后，您重新创建一个常规快捷方式，该快捷方式直接指向相关的可执行文件。这将“绕过”最常见的自我修复触发器（所宣传的快捷方式）。在某些情况下，这避免了整个自我修复问题。值得一试。请注意，即使这似乎可以立即解决，但在您在应用程序内部进行操作时（例如，当您打开特定表单时）自我修复可能仍会重新出现。您需要与实际积极使用该应用程序的某些用户“试用”此修补程序，以确保它对您的环境而言是足够好的解决方法。您还只是消除了问题的征兆，即引起它的注册表或文件冲突仅被“绕过”或“沉默了”-仍然存在，但是如果应用程序在运行期间没有出现问题，这可能就足够了。实际上，有一种方法可以在安装任何MSI软件包时禁用所有公告的快捷方式。设置属性DISABLEADVTSHORTCUTS（以链接中描述的一种方式），然后所有快捷方式都将创建为常规快捷方式，并且不会触发自我修复。至少有两个问题：请注意，可以在任何位置创建快捷方式，包括在特殊文件夹（如“启动”文件夹）中。此特定位置意味着可以在系统启动时自行触发自我修复（无需用户交互）。使用MSI查看器工具并打开系统缓存的MSI，并检查其“快捷方式”表以查找所有快捷方式。为了找到所有缓存包的列表，您可以尝试以下答案：如何找到已安装的MSI安装程序的产品GUID？（打开“ LocalPackage”中指定的程序包路径）。1）该软件包可以设计为使用自我修复来安装用户配置文件或HKCU设置。在这种情况下，由于永远不会运行自我修复，并且安装实际上是不完整的，因此该数据将永远不会按预期添加到系统中。2）不能保证自修复不会继续发生-因为它可以由其他公告的入口点触发，例如COM调用，文件和MIME关联以及命令动词。绝对最简单的解决方法是找出哪些应用程序触发了自我修复，然后将其卸载（如果这是您的环境可接受的解决方案）（很少是）。如果有两个（或多个）应用程序发生冲突，而其中一个很少使用或“可选”，则这是可以接受的。您可以在虚拟机上运行问题应用程序（请参阅第5.5节）。对于非常“行为异常”的应用程序，这将是我的首选“解决方案”。所有问题都应消失，而无需任何实际调试（这是昂贵的）。普通卸载是至少值得考虑的一个选项-某些软件的问题可能不止一种，而应仅被拒绝使用。确保让供应商知道该软件也被拒绝。这可能是使他们认真对待问题的唯一方法。5.1：只需卸载罪魁祸首。5.2：删除广告快捷方式。5.3：禁用COM插件（如果可能）。5.4：尝试免注册COM5.5：虚拟化（APP-V，虚拟机等）。5.6：Windows Installer调整 -（仅适用于专家！）。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调整 ”-是一种“ hack ”，如果由部署专家正确完成，则可以“足够好”地工作。有一些“ 副作用 ”，特别是对于卸载 -以及“弹性”，但是如果操作正确，则应该可以控制。这是“现实世界”-没有什么是“干净的”。

启动应用程序触发重复无休止的Windows Installer自修复时，我该怎么办？

3回答