如果遇到意外的自我修复,您可以尝试的第一件事是手动为应用程序可执行文件直接创建桌面快捷方式问题发生时,您正在启动.这会绕过自我修复最常见的触发条件"所宣传的快捷方式".如果这行得通,则您的问题已解决"(或避免了). 这是一个快速的,充实的解释如果问题仍然存在,或者您的问题与 MS Office , MS Outlook加载项或类似加载(您无法启动)有关(通过快捷方式),那么您的系统很可能会遇到COM注册冲突,并且涉及到更多修复程序. 最容易的尝试是在相关应用程序的插件"对话框中禁用所有不需要的插件,并查看问题是否消失如果仍然遇到问题,则通常需要调试真正的COM注册冲突(或冲突的文件/MIME关联或命令动词).这通常涉及(至少)系统上的两个冲突应用程序,它们在另一个应用程序运行后每次启动时都会打掉它"更新注册表(始终启动其中一个应用程序不会触发自我修复-当出现冲突时,冲突会浮出水面).您在应用程序之间切换).权限问题也有可能导致同一应用程序无法更新系统,并且它会通过反复运行自我修复而不断尝试.还有更多的可能性,下面有更多详细信息"实际修复"是与两家应用程序供应商联系,并向他们询问问题的修复方法(因为通常需要修复)两个供应商MSI的修复程序),但根据我的经验,这很少成功.不过请尝试一下-因为这是长期困扰所有人的方法!我亲自提供了一个用于银行部署的修复程序,很高兴能在我的程序包中解决该问题要调试自己,您需要掌握打开系统上缓存的MSI文件的工具,并且需要入侵"数据库-这是一项涉及到需要专家技能的非常艰巨的任务,您将如果问题对于您的桌面环境非常严重,建议您咨询安装专家以寻求帮助.它可以工作,但不要指望奇迹.有关获取工具以查看和修改MSI文件的更多详细信息,请参见下面称为"查找自我修复的触发器或罪魁祸首"的部分文章"的其余部分深入描述了自我修复问题.除了本简短"部分中描述的原因之外,还有许多其他可能导致自我修复的潜在原因.总体问题:开发人员调试和自我修复 Windows Installer 是一项部署技术,其作用是安装指定的文件和注册表设置,并将其保留在指定的安装位置,并确保它们是正确的版本-为此目的,自我修复或弹性是一种机制.它的操作与开发人员发生冲突,需要即时交换文件以进行调试,开发和测试.相应地,许多自我修复(弹性)仅由开发人员尝试调试即时安装的应用程序和热交换文件触发.有关如何处理此问题的信息,请参见下面的"一些典型的自我修复问题情境"中的第2节.在其他情况下,必须纠正MSI中的真正的设计错误,或者系统管理陷阱会导致自我修复-有时错误源可能很难被发现找.我在 关于serverfault.com的答案 .供系统管理员使用的词略有不同,现在阅读比这冗长的解释(面向开发人员)更容易理解.关于stackoverflow,这里还有另一个简短的答案: 如果删除文件,为什么MSI安装程序会重新配置? (这可能是最短且最容易理解的文件).最后,我找到了 Vadim Rapp 关于自我修复的非常不错的文章:"> 如何修复Windows Installer的自我修复功能 .这篇文章非常值得一读.如果Windows Installer确定正确安装了要启动的产品,则不会进行自我修复.当进行自我修复时,需要在系统上进行一些更改以使应用程序正常运行.自我修复的主要原因 详细信息显示在下面的部分"一些典型的自我修复问题方案"中,但作为快速的预备名单-主要原因是: 1.公司的MSI文件打包错误或来自供应商的MSI设计缺陷(MSI软件包本身设计错误,由于各种原因,意外触发了自我修复)过度使用或错误使用每个用户文件或每个用户注册表项的情况通常是在用户配置文件(而不是HKCU)中设置了错误的密钥路径.有关更多详细信息,请参见下面的第5节(以及这种情况的彩色插图)由于错误的COM服务器注册(尤其是 AutoCAD 和类似产品).两个MSI程序包从两个不同的位置注册相同的COM文件(ActiveX/OCX),并在每次启动应用程序时进行自我修复",以保持其版本正确注册.最后一个启动的应用程序会将注册表设置为正确,并且持续到另一个应用程序启动并执行相同操作为止.一旦您在应用程序之间交替,就会出现问题.有关更多的VB/COM自修复详细信息,请参见下面的第7章组件密钥路径设置为Windows安装程序在自我修复时删除的空文件夹(触发无休止的移除和随后的自我修复循环) ACL锁定权限问题(登录的用户无法访问密钥文件,并且Windows Installer反复触发修复).这也可能是由外部进行的ACL更改引起的,但通常是由MSI本身完成的 这是一个serverfault.com正在进行的工作描述常见的MSI设计缺陷 2.文件或注册表项会受到外部原因(从(登录)脚本到标准操作系统功能,病毒,安全软件等)的干扰而被删除.由MSI软件包将 临时文件错误地安装到temp文件夹后,Windows会自动删除 干扰来自错误的登录-并触发了令人满意的清理脚本和清理应用 防病毒应用程序阻止或删除文件或注册表项,以便Windows Installer不再检测或访问它们 计算机病毒更改或删除文件和注册表设置 计算机修补程序过度活跃,并且用户删除了他们不了解的文件和设置 3. Windows设计更改,缺陷或限制导致存在缺陷或问题的 广告宣传的MSI软件包无法安装(由于安装时间太长,因此可能会被取消),并且一直困扰着人们.严格来说,这不是自我修复,而是宣告中止的安装,但结果是一样的:无尽的重新安装 终端服务器并发症.通常在终端服务器上完全禁用自我修复.这通常不会引起自我修复问题,但是应用程序安装时不需要通过可良性使用自我修复来添加所需的每用户文件或注册表项(请参阅下文).然后,用户文件和用户注册表项就丢失了,并导致了问题 UAC 干扰,证书验证失败和其他因 Windows设计更改而导致的问题.对于每种版本的Windows安全功能,都添加了这些功能,通常最终会为可靠部署增加新的障碍即使某些特定的 Windows更新(更新,安全更新,修补程序等),也可能会对MSI软件包的安全实施方式进行重大更改,从而导致行为异常严重尽管这与MSI的创建有关,而不主要与最终用户的使用有关,但 Windows Update KB3004394 更新了Windows检查吊销的根证书的方式,打破了Installshield命令行版本的旧版本(对于经过数字签名的设置).到目前为止,已解决的问题大部分已经解决,但说明了Microsoft如何不断更改MSI核心功能以类似的方式在安装Microsoft更新MS14-037"Internet Explorer版本6、7、8、9、10和11的安全更新"(KB2962872)后,许多用户的Installshield崩溃在安装 kb2918614 (Vista).突然,一个简单的MSI修复操作需要管理员凭据.这完全挫败了MSI的一项核心优势:常规用户具有临时管理员权限的能力来运行批准的安装.安装该修补程序后,还有其他报告的MSI问题.看来是另一个Windows更新程序解决了该问题: kb3008627 (后来由kb3072630代替)关于自我修复 Windows Installer旨在安装应用程序的二进制文件,设置和数据文件并保持其安装状态,并确保它们是正确的版本.为此,自我修复是一种机制.总体概念称为弹性-即,损坏的安装会在启动应用程序之前触发自我修复. 弹性(或自我修复)是Windows Installer的内置主要概念,并且无法关闭以任何安全的方式.人们有时会做最不可思议的事情,例如禁用整个Windows Installer引擎以停止自我修复.显然,绝不能这样做.必须找出修复原因,并解决问题,而不是创建新问题或入侵系统.每次您启动 宣传的快捷方式 > (本质上是指向Windows Installer功能而不是直接指向文件的特殊快捷方式),Windows Installer会通过检查产品的"组件键路径"来验证安装.如果发现差异,则会触发修复以纠正不完整的安装. 组件密钥路径"是为MSI内部组件指定的密钥文件"-每个组件都有一个.自我修复还可以通过实例化COM服务器(或尝试尝试),通过文件扩展名或MIME注册激活文件以及其他一些方式来启动.这是赛门铁克关于自我修复入口点"的主题的综合文章:使用入口点启动自我修复和广告功能.如果文件被删除,移动或简单覆盖(由用户手动或以某种方式自动覆盖),则可能导致自我修复(如果未将文件或注册表设置设置为关键路径,则不会触发自我修复).找到自我修复的起因或元凶 自我修复的触发器通常可以在发生自我修复的系统上的事件查看器中找到.请按照以下步骤打开事件查看器:右键单击我的电脑"点击管理如果出现UAC提示,请单击继续"转到事件查看器"部分,然后检查Windows日志或者,您可以执行以下操作:仅针对事件查看器,开始 => 运行... => eventvwr.exe .如果在开始菜单中没有看到运行,请按 WINKEY + R .查看事件日志的"应用程序部分",您应该从事件源"MsiInstaller"中找到ID为1001和1004的警告在产品代码上方的示例屏幕截图中,红色框内显示了要确定产品代码用于什么产品,您可以按照以下说明的步骤查找产品名称: 如何找到已安装的MSI安装程序的产品GUID?如果您实际上想深入了解MSI文件的实际内容,则必须拥有能够查看MSI文件的工具( ,例如Orca,Installshield,Advanced Installer或类似的 ).然后,您打开"LocalPackage"路径列表中列出的软件包,如在上一个项目符号链接到的答案中找到的屏幕截图所示.对系统缓存的MSI文件和/或注册表进行实际修改以删除广告的入口点(例如(广告的)快捷方式,COM注册,文件关联,MIME关联或命令动词)是专家的工作.它涉及很多,不是很好的做法,但这是我所知道的唯一的最后手段".最后,应用程序可以显式调用Windows Installer本身,以触发共享组件(例如拼写检查器)的自我修复.我相信有几个版本的Microsoft Access可以做到这一点,而且据我所知,这种行为无法更改或解决. MSI专家和 MVP StefanKrüger 有一篇关于相同的自我修复问题的文章.并且他至关重要地讨论了实际事件日志条目及其含义. 请在此处了解实际的调试过程 .一些典型的自我修复问题场景:这是上面概述中已经概述的几种自我修复问题方案的详细解释".将组件键路径 设置为空文件夹,Windows安装程序会在自我修复时将其删除(触发无休止的删除和随后的自我修复循环).通过将文件夹添加到 CreateFolder表 代替(等效的蜡笔).以我的经验,这是发生不必要的自我修复的最常见情况. 非常常见. 许多自我修复问题实际上是由开发人员尝试通过即时替换文件,删除文件或重命名它们来调试其应用程序引起的.或者他们可能使用清理注册表脚本和/或批处理脚本来注销和注册COM文件,COM-Interop,GAC文件,文件关联或其他常见的开发人员调试和开发.任务. 通过广告快捷方式启动应用程序时,此热交换可以触发自我修复. 在应用程序调试过程中为自我修复而苦苦挣扎的开发人员的重要提示是不从公告的快捷方式启动应用程序,但直接从Windows资源管理器或手动创建的快捷方式启动主EXE.这将绕过最常见的" 自我修复入口点 "-宣传的快捷方式.自我修复可能仍然是由于损坏的COM数据,广告的文件关联以及其他一些特殊情况(阅读此Symantec文章了解入口点信息. 其他应用程序或其他MSI软件包可能会干扰注册表数据(通常是COM设置),还会干扰其他注册表设置,从而导致安装中断并导致自我修复设置和文件.这些可能是最难解决的情况,因为应用程序基本上正在与之抗争,而最后一个要运行的应用程序将每次更新注册表.通常,必须重新设计两个MSI文件,才能使应用程序在同一台计算机上运行.或者,按照一天的顺序,可以对整个应用程序进行虚拟化(例如: Microsoft App -V虚拟软件包)并在自己的沙箱中运行,这似乎是当今公司越来越多的事情.经常会在公司环境中使用一组严重重新打包的应用程序来看到这种错误情况.来自不同程序包的COM片段将覆盖另一个程序包中的COM服务器的磁盘路径,并通过公告的快捷方式在每次启动应用程序时进行自我修复.也可以从不同的文件位置注册具有不同文件版本的相同文件名,并共享一些干扰的注册表设置.据我所知,文件系统和注册表中的至少7个变量或设置必须同步才能正确实例化COM服务器.有关 VB6 和 VBA COM应用程序中COM干扰的详细说明,请参见下面的第7章. > 组件密钥路径指向已由应用程序删除的临时文件,或者最终将通过某种清理机制被系统删除的临时文件(也可以是清理工具,例如ccleaner).这对于temp文件夹本身中的文件很常见.通过不安装临时文件或将文件放置在其他位置并使其永久化,可以解决此问题.在企业应用程序重新打包的世界中,我经常看到此错误,在该情况下,错误地清除捕获的图像会导致安装一个根本不应该包含在软件包中的临时文件.通常,它们可能是等待重新启动安装到其预期的受保护位置的临时文件,并且从未执行过重新启动-这是常见的应用程序打包错误.在较小程度上,我看到了来自自动构建系统的自动生成的程序包. 权限问题:如果组件的密钥文件安装在调用应用程序的用户无法访问的位置. Windows Installer可能不会看到"已安装的文件/密钥路径,或者无法将该文件添加到该文件夹中.这些问题可能更难以调试,并且可能不会经常发生.关于此问题,有几种变体:例如,当您将文件安装到%USERPROFILE%路径,然后忘记设置HKCU注册表键路径,而将键路径设置为指向%USERPROFILE%文件夹/时,此示例文件.通常,这会产生无法访问的特定于用户的硬编码密钥路径: C:\ Documents and settings \ user1 \ Desktop .对于其他登录用户将找不到此路径,并且自我修复会循环运行.这是彩色插图.另一个示例是设置为系统帐户不可写的文件夹的关键路径.这可能看起来很奇怪,但可能是由于MSI对系统ACL条目的错误修改,或者奇怪的系统管理员安全设置或任何其他非标准的ACL/安全描述符导致的. 与终端服务器和 Citrix 有关的另一类自我修复问题出现了.整个 Windows安装程序服务都可能被锁定,因此,为添加每个用户数据而调用的任何自我修复都可能会失败,因此自我修复可能会失败,或者更有可能根本无法运行.这是足够的理由,它不像某些MSI文件那样依靠自我修复作为添加用户数据的方式,并且必须用从每台计算机位置复制的用户文件的应用程序部署或效率较低的 ActiveSetup 功能每个用户. VB6应用程序和 VBA应用程序,它们是基于COM的,具有 COM干扰的巨大潜力 >(COM设置相互覆盖并变得不一致),已知会引发一些神秘的自我修复问题,其中大多数问题都没有得到适当的解释.在启动Visual Basic 6(VB6)或Visual Studio(以及许多其他应用程序)时,也可能会发生这种情况.共同点是,当前安装状态中的某些错误触发了自我修复,您可以按照上面"查找"部分中概述的步骤来跟踪罪魁祸首产品和组件自我修复的触发因素或罪魁祸首". 请确保在此处报告您的发现(我不再使用VB6或VBA,您的详细发现可能会对其他人造成长期困扰.)尽管我从未详细调试过此类VB6问题,但这些问题似乎是由安装常用控件, VB6 COM文件,的应用程序导致的与框上的现有文件以及注册表设置和注册冲突的模板和 VBA文件和库,或者每个用户可能需要添加一些每个用户的注册表项或用户配置文件(让自我修复完成一次,看看问题是否消失了).特别是,当我启动 AutoCAD (来自Autodesk), Visual Basic 6启动时,我听说过这些神秘的自我修复问题. 和其他几种产品(该工具中通常带有VBA自动化功能).某些应用程序甚至错误地自行从VB6运行时安装了零碎的片段,从而导致这些设置在卸载这些应用程序时被撕掉".这肯定会导致触发自我修复,以修复现在(部分?)损坏的VB6运行时.此问题有多种变体,全部捕获"解决方案可能是VB6运行时的完全卸载和重新安装. 以下是一个非常常见的特定"问题的描述,涉及几个COM注册表键 .它很好地说明了这种情况下发生的情况.如果在启动 VB6 , AutoCAD , Visual Studio 或其他产品时遇到意外的自我修复,则可以先尝试一种解决方法,以防止这些意外的自我修复首先发生(这不能解决问题,但可能会绕过其症状): 为什么每次我启动Visual Basic 6时Windows Installer都会启动有关最典型的VB6样式自我修复之一,请参阅我对本主题中问题的评论: (ActiveX控件从磁盘上两个不同的位置注册了两次). >我认为对于VB-COM自我修复问题,应该始终有效的"常规修补程序"是让供应商更新其相关项目,以使用最新的官方版本和正确安装并共享ActiveX控件/OCX可用,并且不要依靠自己的版本进行冗余安装并在错误的位置注册. Windows Installer修复或自我修复的一种特殊情况值得一提,完整性是几年前Microsoft Office发生的,其中自我修复会被触发,并且您可能会要求插入Microsoft Office安装介质(在当时是CD-ROM或DVD-今天可能是拇指驱动器).据我所知,这与对Windows Installer内置标准操作" ResolveSource "的错误调用有关,该操作意外(不必要)触发了安装媒体的提示.早些时候,我们非常常见的支持电话,并在此处提及其完整性.请务必注意,只要从任何可移动媒体安装了MS Office,就仍然会出现此问题(而不是使用网络共享的更好选择) >).当MS Office检测到它需要安装最初未安装的产品的其他可选(通常是共享)组件时,就会发生这种情况.例如异常的拼写检查器,各种模板或特定且很少使用的工具.可以将这些组件安装为首次使用时安装"(广告功能是Windows Installer的正确术语). 还有许多其他可能的方案.列举一些: 错误的登录脚本可能会删除系统上的内容并触发自我修复 广告宣传的软件包可能无法安装并继续烦人两个应用程序可能会开始争夺相同的文件关联计算机修补程序和黑客可以手动删除触发自我修复的数据 防病毒软件可以隔离触发修复的文件和注册表设置 病毒可以更改或删除内容并触发自我修复一个cstronger之类的磁盘和注册表清理工具可以删除文件并触发自我修复毫无疑问还有许多其他情况...良性用于自我修复最后,自我修复的良性用途仅发生一次,并不构成错误.这是合法且正确使用自我修复功能,尽管它可能与设计错误一样令人讨厌,并且在用户干预下,它们会一次又一次弹出: 自我修复有时用于向 HKCU 和用户个人资料 添加每个用户的数据. This design mostly works, but gets worse for every version of Windows as new obstacles are put in place for deployment. For one thing self-repair typically does not work at all on terminal servers rendering the setup incomplete. Though it is besides the point for this discussion, it is better to have the application copy files to per-user locations. Another issue is UAC. Other problems show up with each new Windows version and even with some Windows Updates as described above (virtual folder redirects, certificate prompts, previously non-existing target path restrictions etc...).When self-repair is needed to set up user data, it may take so long that the user aborts it and keeps doing so. This causes the self-repair to reappear all the time until it is allowed to finish. A common support call.It is also possible to install a product with "advertised features" that are designed to be installed "on demand" triggered during application use. Few applications use this, but when it is used a lengthy "self-repair style" installer may run - pulling down the required files and settings. If this process is cancelled the installation of the feature is rolled back and it can be triggered again. This install can be slow for several reasons:If the installer used large, compressed CAB files that are first downloaded and then extracted locally on a slow disk where the anti virus starts scanning the whole cab and then each extracted file the operation can take a long time.The operation can also be slow if the network connection is wireless and there are lots of small files to download (high latency), and again the anti virus could slow down things.If installed from removable media, you could get prompts to insert the source media to allow files to be copied. A very common support call if removable media is used in an office environment (it shouldn't be - use an admin install on a network share)Etc...How can I log only the changes causing a MSI file made by Installshield 2008 to reinstall via "self-repair"?What is the reason behind self-repair?How do I disable self-repairing of MSI using Installshield 2008? 解决方案Alternative Answer AvailableUPDATE:There is a shorter, more "solution focused" answer available, perhaps try it first. This answer focuses on "understanding self-repair" rather than explaining the steps to take to eliminate the problem. You might want to read the first section of this answer as well.Unexpected Windows Installer self-repair issues - Quick Fix?This "article" has gotten large and somewhat unreadable. Here is a newly written preamble - the short "workaround version" for fixing unexpected self-repair (often found in VB6, Visual Studio, MS Office, MS Outlook, AutoCAD, etc...)If you experience unexpected self-repair, the first thing you can try is to manually create a desktop shortcut directly to the application executable you are launching when the problem occurs. This bypasses the most common trigger of self-repair, "the advertised shortcut". If this works your problem is "solved" (or avoided). Here is a quick, fleshed-out explanationIf the problem still occurs, or your problem is related to the loading of an MS Office, MS Outlook add-in or similar (that you can't launch via a shortcut), then you most likely have a COM registration conflict on your system, and the fix is much more involved. The easiest to try is to disable any addins you don't need in the addins dialog of the application in question and see if this makes the problem go awayIf you still see problems, then you most often need to debug a genuine COM registration conflict (or conflicting file/MIME associations, or command verbs). This normally involves (at least) two conflicting applications on your system that "fight it out" updating the registry on each launch after the other application has run (always launching one of the apps will not trigger the self-repair - the conflict surfaces when you alternate between applications). It is also possible that permission problems cause the same application to fail to update the system and it keeps trying endlessly by repeatedly running self-repair. And there are further possibilities, more details belowThe "real fix" is to contact both application vendors and ask them for a fix for the problem (since a fix often requires a fix of both vendor MSIs), but in my experience this is rarely successful. Do try it out though - since this is the way to help everyone with a long-standing annoyance! I have personally provided a setup with fixes for a bank deployment and was very happy to have the problem solved in my packageTo debug yourself, you need to get hold of a tool to open cached MSI files on the system and you need to "hack" the database - a very involved task requiring expert skills, you would be advised to seek an installation expert for help if the problem is very serious for your desktop environment. It can work, but don't expect miracles.Please see the section below called "Finding the trigger or culprit for the self-repair" for more details on obtaining a tool to view and modify MSI filesThe rest of the "article" describes self-repair problems in depth. There are many other potential causes of self-repair than what is described in this "short" section.Overall Problem: Developer debugging and self-repairWindows Installer is a deployment technology, its job is to install the specified files and registry settings and keep them in the specified install locations and to ensure they are the right versions - self-repair or resiliency is a mechanism to that end. Its operation conflicts with a developers need to exchange files on the fly for debugging, development and testing.Accordingly, many self-repairs (resiliency) are triggered simply by developers trying to debug their installed application and hot-swapping files on the fly. See section 2 in "Some typical self-repair problem scenarios" below for how to handle this. In other cases there are genuine design errors in the MSI that must be corrected or system administration pitfalls that lead into self-repair - and at times the error source can be hard to find.I have written about the issue of self-repair in an answer on serverfault.com. Slightly different words intended for system administrators, and reading it now it might be a more accessible explanation than this long one (intended for developers). There is also another, shorter answer here on stackoverflow: Why does the MSI installer reconfigure if I delete a file? (this is probably the shortest one and easiest to understand). And finally I found a very nice article on self-repair by Vadim Rapp: How to fix Windows Installer Efforts to Self-Repair. This article is well worth a read.No self-repair will occur if Windows Installer determines that the product being launched is properly installed. When self-repair occurs something needs to be changed on the system for the application to run properly.The Primary Causes of Self-RepairThe details are presented below in the section "Some typical self-repair problem scenarios", but as a quick, foreshadowing list - the primary causes are:1. Badly packaged corporate MSI files or MSI design flaws from the vendor (the MSI package itself is badly designed and triggers self-repair unexpectedly for a variety of reasons)Excessive or erroneous use of per-user files or per-user registry keys often with erroneous key paths set into the user profile (instead of HKCU). See section 5 below for more details (and a color illustration of such a situation)Package interference from erroneous COM server registration (particularly VB6 COM files or VBA files and libraries from products such as AutoCAD from Autodesk, and similar products).Two MSI packages register the same COM file (ActiveX/OCX) from two different locations and "self-repair fight" on each application launch to keep their version correctly registered.The last application to launch puts the registry right for itself, and it lasts until the other application is launched and does the same. Once you alternate between applications the problem occurs. See section 7 below for a lot more VB / COM self-repair detailA component key path is set to an empty folder that Windows installer removes on self-repair (triggering an endless loop of removal and subsequent self-repair)ACL lockdown permission problems (logged on user can not access key file and Windows Installer triggers repair repeatedly). This can also be caused by ACL changes done externally, but is often done by the MSI itselfHere is a serverfault.com work-in-progress describing common MSI design flaws2. Files or registry keys are deleted by interference from external causes ranging from (logon) scripts to standard OS features, viruses, security software, etc...Temporary files are deleted automatically by Windows after being erroneously installed to the temp folder by an MSI packageInterference from bad logon- and trigger happy cleanup scripts and cleanup applicationsAntivirus applications blocking or deleting files or registry keys so that Windows Installer can no longer detect or access themComputer viruses changing or deleting files and registry settingsOveractive computer tinkerers and users delete files and settings they don't understand3. Windows design changes, flaws or restrictions that causes flawed or problematic deploymentAn AD-advertised MSI package fails to install (might be cancelled since it takes too long to install) and keeps bugging people. This is strictly speaking not self-repair but an advertised install that is aborted, but the result is the same: endless reinstallTerminal server complications. Self-repair is generally disabled altogether on terminal servers. This does not normally cause self-repair problems, but application installs without the required per-user files or registry keys that can be added via benign use of self-repair (read below). The user files and user registry keys are then just missing and problems resultUAC interference, certificate validation failure and other problems resulting from Windows design changes. For every version of Windows security features like these are added and normally end up adding new obstacles for reliable deploymentEven certain Windows Updates (updates, security updates, hotfixes, etc...) can make drastic changes to how security is enforced for MSI packages, and hence cause extremely problematic behaviorThough this relates to MSI creation, and not primarily their end-user use, the Windows Update KB3004394 which updates the way Windows checks for revoked root certificates, breaks older version of Installshield's command line build (for setups that were digitally signed). Largely a resolved issue by now, but an illustration of how Microsoft keeps changing core MSI functionalityIn a similar manner Installshield crashed for many users after installing Microsoft update MS14-037 "Security update for Internet Explorer versions 6, 7, 8, 9, 10, and 11" (KB2962872)An extremely problematic change in Windows Installer base functionality occurred after installing kb2918614 (Vista). Suddenly administrator credentials were required for a simple MSI repair operation. This defeated a core benefit of MSI altogether: the ability of regular users to run approved installs with temporary admin rights. There were also other reported MSI problems after installing that fix. It appears another Windows update fixed the issues: kb3008627 (later replaced by kb3072630)About Self-RepairWindows Installer is designed to install your application's binaries, settings- and data files and keep them installed and ensure they are the right versions. Self-repair is a mechanism to that end. The overall concept is called resiliency - i.e. a broken installation triggers a self-repair before the application is launched.Resiliency, or self-repair, is a built-in primary concept of Windows Installer and can not be turned off in any way that is safe. People do the most incredible things sometimes, such as disabling the whole Windows Installer engine to stop their self-repair. This must obviously never be done. The cause of the repair must be identified, and the problem resolved rather than creating new ones, or hacking the system.Every time you launch an advertised shortcut (essentially a special shortcut that points to a Windows Installer feature and not directly to a file), Windows Installer will verify the installation by checking the "component key paths" for your product. If a discrepancy is found, a repair is triggered to correct the incomplete installation. The "component key paths" are the "key files" specified for the components inside your MSI - there is one per component. Self-repair can also be initiated by someone instantiating a COM server (or attempting to), someone activating a file via its file extension or MIME registration, and a few other ways. Here is a comprehensive article from Symantec on the subject of "self-repair entry points": Initiating Self-Repair and Advertising Features with Entry Point.If files are deleted, moved or simply overwritten (manually by a user or somehow automatically), self-repair may result (if the file or registry setting isn't set as a key path self-repair is not triggered).Finding the trigger or culprit for the self-repairThe trigger for the self-repair is generally possible to find in your event viewer on the system where the self-repair took place. Follow these steps to open the event viewer:Right click "My Computer"Click ManageClick continue if you get an UAC promptGo to the Event Viewer section, and check the Windows LogsAlternatively you can do: Start => Run... => eventvwr.exe for just the event viewer. If you don't see run in the start menu, press WINKEY + R.Look in the "Application section" of the event log and you should find warnings from the event source "MsiInstaller" with IDs 1001 and 1004In the sample screen shot above the product code is shown inside the red boxIn order to determine what product the product code is for, you can look up the product name via the procedure explained here: How can I find the product GUID of an installed MSI setup?If you actually want to go in deep and check the actual content of the MSI file, you must get hold of a tool capable of viewing a MSI file (such as Orca, Installshield, Advanced Installer or similar). You then open the package listed in the "LocalPackage" path listing as illustrated in the screen shot found in the answer linked to in the previous bullet point.The actual modification of the system-cached MSI file and/or the registry to remove advertised entry points such as (advertised) shortcuts, COM registration, file associations, MIME associations or command verbs is a specialists job. It is very involved and not good practice, but it is the only "last resort" that I know about.Finally it is possible for an application to explicitly call Windows Installer itself to trigger self-repair for shared components - for example a spell checker. I believe a few versions of Microsoft Access did this, and this behavior can not be changed or worked around as far as I know.MSI-expert and MVP Stefan Krüger has an article about the same self-repair issue. And he crucially discusses the actual event log entries and what they mean. Please read about the actual debugging procedure there.Some typical self-repair problem scenarios:This is the "verbose explanation" of several self-repair problem scenarios already outlined in the overview above.A component key path is set to an empty folder that Windows installer removes on self-repair (triggering an endless loop of removal and subsequent self-repair). This is solved by adding the folder to the CreateFolder table instead (Wix equivalent). In my experience this is the most common scenario for unwanted self-repair. Very common.Many self-repair problems are actually caused by developers trying to debug their applications by replacing files on the fly, deleting files or renaming them. Or they may use cleanup registry scripts and / or batch scripts to unregister and register COM files, COM-Interop, GAC files, file associations, or other common developer debug and development tasks.This hot-swapping can triggering self-repair when the application is launched via an advertised shortcut.A top tip for developers struggling with self-repair during application debugging is to not launch the application from an advertised shortcut, but to launch the main EXE directly from Windows Explorer or from a manually created shortcut. This will bypass the most common "self-repair entry point" - the advertised shortcut. Self-repair may still result from broken COM data, advertised file associations and a few other special cases (read this Symantec article for entry point information).Other applications or rather other MSI packages can break your installation and cause self-repair by interfering with registry data - typically COM settings, but also with other settings and files. These can be some of the hardest cases to solve, since the applications are basically fighting it out and the last one to run will update the registry each time. Typically both MSI files must be redesigned for the applications to operate on the same machine. Or, as is the order of the day, the whole application may be virtualized (for example: Microsoft App-V virtual packages) and run in its own sandbox which seems to be what is done more and more in companies these days. This error scenario is often seen with a suite of badly repackaged applications in a corporate environment. COM fragments from different packages overwrite the COM server's disk path from another package, and self-repair fighting ensues on each application launch via an advertised shortcut. The same file name with different file versions can also be registered from different file locations and share some registry settings that interfere. As far as I recall at least 7 variables or settings in the file system and registry must be in sync for a COM server to be properly instantiable. See section 7 below for a more specialized description of COM interference in the context of VB6 and VBA COM applications.A component key path is pointing to a temporary file that has been deleted by the application or it will be deleted by the system eventually via some sort of cleanup mechanism (can also be a cleanup tool such as ccleaner). This is common for files in the temp folder itself. This is solved by not installing the temp file, or putting the file somewhere else and making it permanent. I have seen this error most often in the world of corporate application repackaging where a faulty cleanup of the captured image leads to the install of a temporary file that should not have been included in the package at all. Often they may be temporary files waiting for a reboot to be installed to their intended, perhaps protected location, and the reboot was never performed - a common application packaging error. To a lesser degree I have seen it in auto-generated packages coming out of automated build systems.Permission problems: if a key file for a component is installed to a location that is not accessible for the user who invokes the application. Windows Installer might not "see" the installed file / key path, or be unable to add the file to the folder. These issues can be more exotic to debug, and may not happen that often. There are several variations on this issue:An example of this is when you install a file to a %USERPROFILE% path and then forget to set a HKCU registry keypath, and instead set the keypath to point to the %USERPROFILE% folder/file. This generally yields an inaccessible hard coded key path that is user-specific: C:\Documents and settings\user1\Desktop. This path will not be found for another user logging on, and self-repair runs in circles. Here is a color illustration.Another example is key paths set to folders that are not writeable for the System account. This may seem exotic but can result from the MSI's faulty modification of system ACL entries, or from a strange system administrator security setup, or any other non-standard ACL / Security Descriptor.Another class of self-repair problems emerges in relation to terminal servers and Citrix. The whole windows installer service could be locked down so any self-repair invoked to add per user data could fail and consequently self-repair may fail or more likely not run at all. This is reason enough to not rely on self-repair as a way to add user data like some MSI files do, and such constructs must be replaced with application deployment of user files copied from per-machine locations or the less effective ActiveSetup feature from Microsoft that runs once per user.VB6 applications and VBA applications, which are heavily COM based with massive potential for COM interference (COM settings overwriting each other and becoming inconsistent), have been known to trigger several mysterious self-repair problems, most of which have not been properly explained. This can also happen on launch of Visual Basic 6 (VB6) or Visual Studio (and many other applications). The common denominator is that some error in the current installation state triggered the self-repair, and you can track down the culprit product and component by following the steps outlined in the section above called "Finding the trigger or culprit for the self-repair". Be sure to report your findings here (I never use VB6 or VBA anymore - your detailed findings could help others with a long-standing annoyance).Though I have never debugged such VB6 issues in great detail, it would seem that the problems result from applications that install common controls, VB6 COM files, templates and VBA files and libraries that conflict with existing files and registry settings and registrations on the box, or some per-user registry key or userprofile file may need to be added once per user (allow the self-repair to complete once and see if the problem goes away). In particular I have heard of these mysterious self-repair problems when launching AutoCAD (from Autodesk), Visual Basic 6, and several other products (often with VBA automation available in the tool).Some applications even erroneously install bits and pieces from the VB6 runtime on their own causing these settings to be "ripped out" on uninstall of those applications. This can certainly cause self-repair to be triggered to fix the now (partially?) broken VB6 runtime. There are several variants of this problem, and the "catch all" solution is probably a complete uninstall and reinstall of the VB6 runtime. Here is a description of a very common "specific" problem involving a few COM registry keys. It nicely illustrates what happens in this scenario.If you experience unexpected self-repair when launching VB6, AutoCAD, Visual Studio or other products, you can first try a workaround to prevent these unexpected self-repairs from happening in the first place (this doesn't solve the problem, but may bypass its symptoms): why does windows installer start up everytime i start up visual basic 6See my comment to the question in this topic for one of the most typical VB6 style self-repairs: Why does my application triggers the Installer of another application? (ActiveX control registered twice from two different locations on disk).In my opinion the "general fix" - that should always work - for VB-COM self-repair issues, is to get the vendor to update their project in question to use the latest official and properly installed and shared ActiveX control / OCX available, and not to rely on their own version installed redundantly and registered in the wrong location.A special case of Windows Installer repair or self-repair that is worth mentioning for completeness, was the issue with Microsoft Office several years ago where a self-repair would be triggered, and you would be asked to insert the Microsoft Office installation media (in those days CD-ROMs or DVDs - today maybe thumb drives). As far as I recall this was related to an erroneous call to the built in Windows Installer standard action "ResolveSource" which unexpectedly (and unnecessarily) triggered the prompt for the installation media. A very common support call back in the day and mentioned here for completeness. It is important to note that this problem can still occur whenever MS Office is installed from any removable media (rather than the better option of a network share). This happens when MS Office detects that it needs to install further, optional (and usually shared) components of the product that were not installed originally. For example unusual spell-checkers, various templates or specific and rarely used tools. It is possible to install these components to "install on first use" (advertised features is the proper Windows Installer term).There are many other possible scenarios. To mention a few:a bad logon script may delete things on the system and trigger self-repairan AD advertised package may fail to install and keep bugging peopletwo applications may start fighting for the same file associationscomputer tinkerers and hackers can manually delete data that trigger self-repairanti-virus can quarantine files and registry settings that trigger repaira virus can change or delete things and trigger self-repaira disk and registry cleanup tool such as ccleaner can delete files and trigger self-repairand no doubt numerous other scenarios...Benign uses for self-repairFinally there are benign uses for self-repair that happen once and do not constitute errors. This is the legal and proper use of self-repair though it may be just as annoying as the design errors, and with user intervention they can pop up again and again:Self-repair is sometimes used to add per-user data to HKCU and the user profile. This design mostly works, but gets worse for every version of Windows as new obstacles are put in place for deployment. For one thing self-repair typically does not work at all on terminal servers rendering the setup incomplete. Though it is besides the point for this discussion, it is better to have the application copy files to per-user locations. Another issue is UAC. Other problems show up with each new Windows version and even with some Windows Updates as described above (virtual folder redirects, certificate prompts, previously non-existing target path restrictions etc...).When self-repair is needed to set up user data, it may take so long that the user aborts it and keeps doing so. This causes the self-repair to reappear all the time until it is allowed to finish. A common support call.It is also possible to install a product with "advertised features" that are designed to be installed "on demand" triggered during application use. Few applications use this, but when it is used a lengthy "self-repair style" installer may run - pulling down the required files and settings. If this process is cancelled the installation of the feature is rolled back and it can be triggered again. This install can be slow for several reasons:If the installer used large, compressed CAB files that are first downloaded and then extracted locally on a slow disk where the anti virus starts scanning the whole cab and then each extracted file the operation can take a long time.The operation can also be slow if the network connection is wireless and there are lots of small files to download (high latency), and again the anti virus could slow down things.If installed from removable media, you could get prompts to insert the source media to allow files to be copied. A very common support call if removable media is used in an office environment (it shouldn't be - use an admin install on a network share)Etc... 这篇关于如何确定导致Windows Installer重复进行自我修复的原因?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持! 上岸,阿里云!