如何确定导致重复Windows Installer自修复的原因?

问题描述 投票:9回答:1
  • 如何仅记录由Installshield 2008生成的MSI文件的更改,以通过“自我修复”重新安装?
  • 自修的原因是什么?
  • 如何使用Installshield 2008禁用MSI的自我修复?
wix installer windows-installer installshield resiliency
1个回答
16
投票

自我修复,简单和简短说明:Why does the MSI installer reconfigure if I delete a file?


Alternative Answer Available

更新:There is a shorter, more "solution focused" answer available,也许先试试吧。这个答案侧重于“理解自我修复”,而不是解释消除问题的步骤。您可能还想阅读本答案的第一部分。


Unexpected Windows Installer self-repair issues - Quick Fix?

这篇“文章”变得越来越大,有些难以理解。这是一个新编写的序言 - 用于修复意外自修复的简短“解决方法版本”(常见于VB6,Visual Studio,MS Office,MS Outlook,AutoCAD等...)

  • 如果您遇到意外的自我修复,您可以尝试的第一件事是直接手动创建桌面快捷方式,以便在出现问题时启动应用程序可执行文件。这绕过了最常见的自我修复触发器,即“广告的捷径”。如果这有效,您的问题就会“解决”(或避免)。 Here is a quick, fleshed-out explanation
  • 如果问题仍然存在,或者您的问题与加载MS Office,MS Outlook加载项或类似(无法通过快捷方式启动)相关,那么您很可能在系统上发生COM注册冲突,修复更多涉及。最容易尝试的是在相关应用程序的addins对话框中禁用您不需要的任何插件,看看是否会导致问题消失
  • 如果您仍然看到问题,那么您最常需要调试正版COM注册冲突(或冲突的文件/ MIME关联或命令动词)。这通常涉及(至少)系统上的两个冲突的应用程序,在其他应用程序运行后,每次启动都会“解决”更新注册表(总是启动其中一个应用程序不会触发自我修复 - 冲突时会出现冲突你在应用程序之间交替)。权限问题也可能导致同一应用程序无法更新系统,并且通过反复运行自修复而不断尝试。还有其他可能性,下面有更多细节 “真正的解决方案”是联系两个应用程序供应商并要求他们解决问题(因为修复通常需要修复两个供应商的MSI),但根据我的经验,这很少成功。尝试一下 - 因为这是帮助每个人长期烦恼的方法!我个人提供了一个针对银行部署的修复程序的设置,并且很高兴在我的程序包中解决了问题 要调试自己,你需要掌握一个工具来打开系统上的缓存MSI文件,你需要“破解”数据库 - 一个需要专业技能的非常复杂的任务,你会被建议寻求安装专家的帮助,如果对于您的桌面环境,问题非常严重。它可以工作,但不要指望奇迹。 有关获取查看和修改MSI文件的工具的更多详细信息,请参阅下面的“查找自修复的触发器或罪魁祸首”部分。

“文章”的其余部分深入描述了自我修复问题。与“短”部分中描述的相比,还有许多其他潜在的自我修复原因。


Overall Problem: Developer debugging and self-repair

Windows Installer是一种部署技术,其工作是安装指定的文件和注册表设置,并将它们保存在指定的安装位置,并确保它们是正确的版本 - 自我修复或弹性是一种机制。它的操作与开发人员需要动态交换文件进行调试,开发和测试。

因此,许多自我修复(弹性)仅由开发人员尝试调试其已安装的应用程序和动态交换文件而触发。有关如何处理此问题,请参阅下面的“一些典型的自修复问题场景”中的第2节。在其他情况下,MSI中存在必须更正的真正设计错误或导致自我修复的系统管理陷阱 - 有时可能很难找到错误源。

我写过关于an answer on serverfault.com自我修复的问题。用于系统管理员的略有不同的单词,现在阅读它可能是一个比这个长的(用于开发人员)更容易理解的解释。 stackoverflow还有另一个较短的答案:Why does the MSI installer reconfigure if I delete a file?(这可能是最短的,也是最容易理解的)。最后我发现了一篇关于Vadim Rapp自我修复的非常好的文章:How to fix Windows Installer Efforts to Self-Repair。这篇文章非常值得一读。

如果Windows Installer确定正在安装的产品已正确安装,则不会进行自我修复。发生自我修复时,需要在系统上更改某些内容才能使应用程序正常运行。


自我修复的主要原因

详细信息将在下面的“一些典型的自我修复问题场景”一节中介绍,但作为一个快速的预示清单 - 主要原因是:

1.来自供应商的包装不良的企业MSI文件或MSI设计缺陷(MSI包本身设计糟糕,并出于各种原因意外触发自我修复)

  • 过度或错误地使用每用户文件或每用户注册表项通常会在用户配置文件(而不是HKCU)中设置错误的密钥路径。有关详细信息,请参阅下面的第5部分(以及此类情况的彩色插图)
  • 来自错误的COM服务器注册的打包干扰(特别是VB6 COM文件或来自Autodesk的AutoCAD等产品的VBA文件和库,以及类似产品)。 两个MSI包从两个不同的位置注册相同的COM文件(ActiveX / OCX),并在每次应用程序启动时“自我修复”,以保持其版本正确注册。 最后一个要启动的应用程序使注册表适合自己,并且它会持续到其他应用程序启动并执行相同操作。在应用程序之间交替出现问题。有关VB / COM自修复细节的更多信息,请参见下面的第7节
  • 组件密钥路径设置为Windows安装程序在自我修复时删除的空文件夹(触发无限循环的删除和随后的自我修复)
  • ACL锁定权限问题(登录用户无法访问密钥文件,Windows Installer会重复触发修复)。这也可以由外部完成的ACL更改引起,但通常由MSI本身完成
  • Here is a serverfault.com work-in-progress describing common MSI design flaws

2.文件或注册表项被外部原因干扰删除,从(登录)脚本到标准操作系统功能,病毒,安全软件等......

  • 在MSI软件包错误地将临时文件安装到临时文件夹后,Windows会自动删除临时文件
  • 来自错误登录的干扰 - 并触发快乐清理脚本和清理应用程序
  • 阻止或删除文件或注册表项的防病毒应用程序,以便Windows Installer无法再检测或访问它们
  • 计算机病毒更改或删除文件和注册表设置
  • 过度活跃的计算机修补工具和用户删除他们不理解的文件和设置

3. Windows设计更改,缺陷或限制导致部署有缺陷或有问题

  • AD广告的MSI程序包无法安装(可能会因为安装时间太长而被取消)并且不断窃听人员。严格来说,这不是自我修复,而是一个被中止的广告安装,但结果是一样的:无休止的重新安装
  • 终端服务器并发症在终端服务器上通常完全禁用自我修复。这通常不会导致自我修复问题,但应用程序安装没有所需的每用户文件或注册表项,可以通过良好的自我修复添加(如下所示)。然后,用户文件和用户注册表项丢失,并导致问题
  • UAC干扰,证书验证失败以及Windows设计更改导致的其他问题。对于每个版本的Windows,都会添加这些安全功能,并且通常最终会为可靠部署添加新的障碍
  • 甚至某些Windows更新(更新,安全更新,修补程序等)也可以对MSI包的安全性执行方式进行重大更改,从而导致极其有问题的行为 虽然这与MSI创建有关,而不是主要是他们的最终用户使用,但更新Windows检查撤销根证书的方式的Windows Update KB3004394打破了旧版本的Installshield命令行构建(对于经过数字签名的设置)。现在很大程度上是一个已解决的问题,但是说明了Microsoft如何不断改变核心MSI功能 以类似的方式安装Microsoft更新MS14-037“Internet Explorer版本6,7,8,9,10和11的安全更新”后,许多用户使用Installshield crashed(KB2962872) 安装kb2918614(Vista)后,Windows Installer基本功能发生了极其棘手的变化。突然,管理员凭据是简单的MSI修复操作所必需的。这完全打败了MSI的核心优势:普通用户能够运行具有临时管理权限的已批准安装。安装该修复程序后还有其他报告的MSI问题。它似乎另一个Windows更新修复了问题:kb3008627(后来被kb3072630取代)

About Self-Repair

Windows Installer旨在安装应用程序的二进制文件,设置和数据文件,并保持它们的安装并确保它们是正确的版本。自我修复是实现这一目标的机制。整体概念称为弹性 - 即,在应用程序启动之前,损坏的安装会触发自我修复。

弹性或自我修复是Windows Installer的内置主要概念,不能以任何安全的方式关闭。人们有时会做最令人难以置信的事情,比如禁用整个Windows Installer引擎来停止自我修复。显然,这绝不可能。必须确定修复的原因,并解决问题,而不是创建新问题或破解系统。

每次启动advertised shortcut(本质上是指向Windows Installer功能而不是直接指向文件的特殊快捷方式)时,Windows Installer都会通过检查产品的“组件密钥路径”来验证安装。如果发现差异,则会触发修复以纠正不完整的安装。 “组件密钥路径”是为MSI内部组件指定的“密钥文件” - 每个组件有一个。自我修复也可以由实例化COM服务器(或尝试),某人通过其文件扩展名或MIME注册激活文件的人以及其他一些方式启动。以下是赛门铁克关于“自修复切入点”主题的综合文章:Initiating Self-Repair and Advertising Features with Entry Point

如果文件被删除,移动或仅被覆盖(由用户手动或以某种方式自动),则可能导致自我修复(如果文件或注册表设置未设置为关键路径,则不会触发自修复)。


Finding the trigger or culprit for the self-repair

通常可以在发生自我修复的系统上的事件查看器中找到自我修复的触发器。请按照以下步骤打开事件查看器:

  • 右键单击“我的电脑”
  • 单击管理
  • 如果出现UAC提示,请单击“继续”
  • 转到“事件查看器”部分,然后检查Windows日志

或者你可以这样做:Start => Run ... => eventvwr.exe只用于事件查看器。如果在开始菜单中没有看到运行,请按WINKEY + R.

  • 查看事件日志的“应用程序部分”,您应该从事件源“MsiInstaller”中找到ID为1001和1004的警告
  • 在上面的示例屏幕截图中,产品代码显示在红色框内
  • 为了确定产品代码的产品,您可以通过此处说明的程序查找产品名称:How can I find the product GUID of an installed MSI setup?
  • 如果您确实想要深入查看MSI文件的实际内容,则必须获得能够查看MSI文件的工具(such as Orca, Installshield, Advanced Installer or similar)。然后打开“LocalPackage”路径列表中列出的包,如上一个项目符号链接中链接的答案中的屏幕截图所示。
  • 实际修改系统缓存的MSI文件和/或注册表以删除广告的入口点,例如(公布的)快捷方式,COM注册,文件关联,MIME关联或命令动词,这是一项专家工作。它是非常复杂的而不是良好的实践,但它是我所知道的唯一“最后的手段”。
  • 最后,应用程序可以显式调用Windows Installer本身来触发共享组件的自修复 - 例如拼写检查程序。我相信Microsoft Access的几个版本做到了这一点,据我所知,这种行为无法改变或解决。

微星专家和MVP Stefan Krüger有一篇关于同一自修复问题的文章。他重要地讨论了实际的事件日志条目及其含义。 Please read about the actual debugging procedure there


Some typical self-repair problem scenarios:

这是上面概述中已经概述的几个自修复问题场景的“详细解释”。

  1. 组件密钥路径设置为Windows安装程序在自我修复时删除的空文件夹(触发无限循环的删除和后续自我修复)。这可以通过将文件夹添加到CreateFolder tableWix equivalent)来解决。根据我的经验,这是不必要的自我修复的最常见情况。很普通的。
  2. 许多自我修复问题实际上是由开发人员试图通过动态替换文件,删除文件或重命名来调试应用程序引起的。或者,他们可以使用清理注册表脚本和/或批处理脚本来注销和注册COM文件,COM-Interop,GAC文件,文件关联或其他常见的开发人员调试和开发任务。 当通过广告的快捷方式启动应用程序时,此热交换可以触发自我修复。 在应用程序调试期间努力进行自我修复的开发人员的一个重要提示是不从广告的快捷方式启动应用程序,而是直接从Windows资源管理器或手动创建的快捷方式启动主EXE。这将绕过最常见的“self-repair entry point” - 广告的捷径。自修复可能仍然是由于COM数据损坏,广告文件关联和一些其他特殊情况(read this Symantec article用于入口点信息)。
  3. 其他应用程序或其他MSI程序包可能会破坏您的安装并通过干扰注册表数据(通常是COM设置)以及其他设置和文件来导致自我修复。这些可能是最难解决的一些案例,因为应用程序基本上是在解决它,而最后一个要运行的应用程序每次都会更新注册表。通常,必须重新设计两个MSI文件,以便应用程序在同一台计算机上运行。或者,按照当天的顺序,整个应用程序可以虚拟化(例如:Microsoft App-V virtual packages)并在其自己的沙箱中运行,这似乎是公司近来所做的越来越多。在企业环境中,通常会出现一组错误重新打包的应用程序,从而出现此错误情况。来自不同包的COM片段覆盖来自另一个包的COM服务器的磁盘路径,并且通过广告的快捷方式在每次应用程序启动时进行自我修复。也可以从不同的文件位置注册具有不同文件版本的相同文件名,并共享一些干扰的注册表设置。据我所知,文件系统和注册表中至少有7个变量或设置必须同步才能使COM服务器可以正确实例化。有关VB6和VBA COM应用程序环境中COM干扰的更具体描述,请参见下面的第7节。
  4. 组件键路径指向已被应用程序删除的临时文件,或者系统最终将通过某种清理机制(也可以是清理工具,如ccleaner)删除它。这对于临时文件夹本身中的文件很常见。这可以通过不安装临时文件,或将文件放在其他地方并使其永久化来解决。我在企业应用程序重新打包的世界中经常看到这个错误,其中捕获的映像的错误清理导致安装临时文件,该文件根本不应该包含在包中。通常它们可能是临时文件,等待重新启动安装到其预期的,可能受保护的位置,并且从未执行重新启动 - 常见的应用程序打包错误。在较小程度上,我在自动生成的软件包中看到它来自自动构建系统。
  5. 权限问题:如果组件的密钥文件安装到调用应用程序的用户无法访问的位置。 Windows Installer可能无法“看到”已安装的文件/密钥路径,或者无法将文件添加到该文件夹​​。调试这些问题可能更具异国情调,并且可能不会经常发生。这个问题有几个变种: 例如,当您将文件安装到%USERPROFILE%路径,然后忘记设置HKCU注册表键路径,而是将键路径设置为指向%USERPROFILE%文件夹/文件。这通常会产生一个用户特定的无法访问的硬编码密钥路径:C:\ Documents and settings \ user1 \ Desktop。其他用户登录时找不到此路径,并且自我修复以圆圈形式运行。这是一个color illustration。 另一个示例是设置为不可写入系统帐户的文件夹的密钥路径。这可能看起来很奇特,但可能是由于MSI对系统ACL条目的错误修改,或者来自奇怪的系统管理员安全设置或任何其他非标准ACL /安全描述符。
  6. 与终端服务器和Citrix相关的另一类自修复问题出现了。可以锁定整个Windows安装程序服务,因此调用每个用户数据添加的任何自我修复都可能失败,因此自我修复可能会失败或更可能根本无法运行。这是不足以依赖自我修复作为添加用户数据的方式的原因,就像某些MSI文件那样,并且必须用从每个机器位置复制的用户文件的应用程序部署或Microsoft的低效ActiveSetup功能替换此类构造。每个用户运行一次。
  7. VB6应用程序和VBA应用程序是基于COM的,具有巨大的COM干扰潜力(COM设置相互覆盖并变得不一致),已经引发了几个神秘的自修复问题,其中大部分都没有得到适当的解释。这也可以在Visual Basic 6(VB6)或Visual Studio(以及许多其他应用程序)的启动时发生。共同点是当前安装状态中的某些错误触发了自我修复,您可以按照上面“查找触发器或自我修复的罪魁祸首”一节中列出的步骤追踪罪魁祸首产品和组件。 。一定要在这里报告你的发现(我再也不会使用VB6或VBA了 - 你的详细发现可以帮助其他人长期烦恼)。 虽然我从来没有详细调试过这样的VB6问题,但似乎问题是由安装公共控件,VB6 COM文件,模板和VBA文件以及与现有文件和注册表设置冲突的应用程序以及框中注册的应用程序造成的,或者每个用户可能需要添加一些每用户注册表项或userprofile文件(允许自我修复完成一次并查看问题是否消失)。特别是在启动AutoCAD(来自Autodesk),Visual Basic 6和其他几种产品时(通常在工具中提供VBA自动化),我听说过这些神秘的自修复问题。 有些应用程序甚至错误地从VB6运行时自行安装了一些碎片,导致这些设置在卸载这些应用程序时被“撕掉”。这肯定会导致自我修复被触发以修复现在(部分?)损坏的VB6运行时。这个问题有几种变体,“全部捕获”解决方案可能是完全卸载并重新安装VB6运行时。 Here is a description of a very common "specific" problem involving a few COM registry keys。它很好地说明了这种情况下会发生什么。 如果在启动VB6,AutoCAD,Visual Studio或其他产品时遇到意外的自我修复,您可以先尝试一种解决方法,以防止这些意外的自我修复发生(这不能解决问题,但可能会绕过它的症状):why does windows installer start up everytime i start up visual basic 6 请参阅本主题中针对最典型的VB6样式自修复之一的问题的评论:Why does my application triggers the Installer of another application?(ActiveX控件从磁盘上的两个不同位置注册两次)。 在我看来,对于VB-COM自修复问题,应该始终有效的“一般修复”是让供应商更新他们的项目,使用最新的官方和正确安装和共享的ActiveX控件/ OCX,并且不要依赖自己的冗余安装版本并在错误的位置注册。
  8. Windows Installer修复或自我修复的一个特例是值得一提的完整性,是几年前Microsoft Office的问题,其中会触发自我修复,并且会要求您插入Microsoft Office安装介质(在那些日子的CD-ROM或DVD - 今天可能是拇指驱动器。据我所知,这与内置的Windows Installer标准操作“ResolveSource”的错误调用有关,该操作意外地(并且不必要地)触发了安装介质的提示。一个非常普遍的支持在当天回电并在此提及完整性。请务必注意,每当从任何可移动媒体安装MS Office(而不是网络共享的更好选项)时,仍会出现此问题。当MS Office检测到需要安装最初未安装的产品的其他可选(通常是共享)组件时,会发生这种情况。例如,不常见的拼写检查程序,各种模板或特定的和很少使用的工具。可以将这些组件安装为“首次使用时安装”(广告功能是正确的Windows Installer术语)。
  9. 还有许多其他可能的情况。提一下: 错误的登录脚本可能会删除系统上的内容并触发自我修复 AD宣传的软件包可能无法安装并不断窃听人员 两个应用程序可能会开始争夺相同的文件关联 计算机修补匠和黑客可以手动删除触发自我修复的数据 防病毒可以隔离触发修复的文件和注册表设置 病毒可以更改或删除内容并触发自我修复 磁盘和注册表清理工具(如ccleaner)可以删除文件并触发自我修复 毫无疑问,还有很多其他场景......

Benign uses for self-repair

最后,有一次良性用于自我修复,一次发生并且不构成错误。这是合法和正确使用自我修复虽然它可能与设计错误一样烦人,并且通过用户干预,它们可以一次又一次地弹出:

  • 自修复有时用于向HKCU和用户配置文件添加每用户数据。这种设计大多有效,但每个版本的Windows都会变得更糟,因为部署了新的障碍。首先,自修复通常在终端服务器上根本不起作用,导致设置不完整。虽然除了讨论的重点之外,最好将应用程序复制文件放到每个用户的位置。另一个问题是UAC。其他问题出现在每个新的Windows版本中,甚至还有一些如上所述的Windows更新(虚拟文件夹重定向,证书提示,以前不存在的目标路径限制等等)。
  • 当需要自我修复来设置用户数据时,用户可能需要很长时间才能中止并继续进行。这导致自我修复一直重新出现,直到它被允许完成。一个共同的支持电话。
  • 也可以安装带有“advertised features”的产品,这些产品设计为在应用程序使用期间“按需”安装。很少有应用程序使用它,但是当使用它时,可能会运行冗长的“自修复样式”安装程序 - 拉下所需的文件和设置。如果取消此过程,则会回滚该功能的安装,并且可以再次触发该功能。由于以下几个原因,此安装可能会很慢: 如果安装程序使用首先下载的大型压缩CAB文件,然后在慢速磁盘上本地提取,其中防病毒开始扫描整个驾驶室,然后每个提取的文件操作可能需要很长时间。 如果网络连接是无线的并且有许多小文件需要下载(高延迟),那么操作也可能很慢,反病毒可能会减慢速度。 如果从可移动媒体安装,您可能会收到插入源媒体的提示,以允许复制文件。如果在办公室环境中使用可移动媒体,则非常常见的支持呼叫(不应该 - 使用admin install on a network share) 等等...
© www.soinside.com 2019 - 2024. All rights reserved.