如何确定导致 Windows Installer 重复自我修复的原因？
- 如何仅记录导致 Installshield 2008 所做的 MSI 文件通过“自我修复”重新安装的更改？
- 自修复的原因是什么？
- 如何使用 Installshield 2008 禁用 MSI 自我修复？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
可用的替代答案
更新：
有一个更短、更“以解决方案为中心”的答案，也许可以先尝试一下。这个答案的重点是“理解自我修复”，而不是解释消除问题所采取的步骤。您可能还想阅读此答案的第一部分。
意外的 Windows Installer 自我修复问题 - 快速修复？
这篇“文章”已经变得很大并且有些难以阅读。这是一个新写的序言 - 简短的“解决方法版本”，用于修复意外的自我修复（通常在 VB6、Visual Studio、MS Office、MS Outlook、AutoCAD 等中找到）
“文章”的其余部分描述了自我修复问题深入。除了这个“简短”部分中描述的原因之外，还有许多其他潜在的自我修复原因。
总体问题：开发者调试和自我修复
Windows Installer是一种部署技术，它的工作是安装指定的文件和注册表设置并将它们保存在指定的安装位置，并确保它们是正确的版本 - 自我修复或弹性是达到此目的的一种机制。它的操作与开发人员需要动态交换文件以进行调试、开发和测试相冲突。
因此，许多自我修复（弹性）只是由开发人员试图动态调试已安装的应用程序和热交换文件。有关如何处理此问题，请参阅下面的“一些典型的自我修复问题场景”中的第 2 节。在其他情况下，MSI 中存在必须纠正的真正的设计错误，或者存在导致自我修复的系统管理陷阱 - 有时错误源可能很难确定寻找。
我在serverfault.com 上的答案中写了有关自我修复的问题。对于系统管理员来说，用词略有不同，现在阅读它可能比这个冗长的解释（针对开发人员）更容易理解。 stackoverflow 上还有另一个更短的答案：为什么如果我删除文件，MSI 安装程序会重新配置？（这可能是最短且最容易理解的）。最后我发现了 Vadim Rapp 写的一篇关于自我修复的非常好的文章：如何修复 Windows Installer 自我修复。这篇文章非常值得一读。
如果 Windows Installer 确定正在启动的产品已正确安装，则不会进行自我修复。当发生自我修复时，需要对系统进行某些更改才能使应用程序正常运行。
自我修复的主要原因
详细信息如下“一些典型的自我修复问题场景”部分，但作为一个快速的预示列表< /strong> - 主要原因是：
1。企业 MSI 文件打包不当或供应商的 MSI 设计缺陷（MSI 包本身设计不当，会因各种原因意外触发自我修复）
2.文件或注册表项会因外部原因的干扰而被删除，这些外部原因包括（登录）脚本、标准操作系统功能、病毒、安全软件等...
3. Windows 设计更改、缺陷或限制导致部署有缺陷或有问题
关于自我修复
Windows安装程序旨在安装应用程序的二进制文件、设置和数据文件，并保持它们的安装状态并确保它们是正确的版本。自我修复是达到此目的的一种机制。总体概念称为弹性 - 即损坏的安装会在应用程序启动之前触发自我修复。
弹性或自我修复，是Windows Installer 的内置主要概念并且无法关闭 以任何安全的方式。人们有时会做出最不可思议的事情，例如禁用整个 Windows Installer 引擎来停止自我修复。显然绝对不能这样做。必须确定修复原因并解决问题，而不是制造新问题或破解系统。
每次启动广告快捷方式（本质上是指向 Windows Installer 功能而不是直接指向文件的特殊快捷方式），Windows安装程序将通过检查产品的“组件密钥路径”来验证安装。如果发现差异，则会触发修复以纠正不完整的安装。 “组件密钥路径”是为 MSI 内的组件指定的“密钥文件” - 每个组件都有一个。自我修复也可以通过实例化 COM 服务器（或尝试）、通过文件扩展名或 MIME 注册激活文件以及其他一些方式来启动。以下是赛门铁克关于“自我修复入口点”主题的综合文章：使用入口点启动自我修复和广告功能。
如果文件被删除、移动或简单地覆盖（由用户手动或以某种方式自动），则可能会导致自我修复（如果文件或注册表设置未设置为关键路径，则不会触发自我修复）。
查找自我修复的触发器或罪魁祸首
自我修复的触发器通常可以在发生自我修复的系统上的事件查看器中找到。按照以下步骤打开事件查看器：
或者，您也可以执行以下操作：<强>开始 => 运行... => eventvwr.exe 仅用于事件查看器。如果在开始菜单中没有看到“运行”，请按 WINKEY + R。
MSI 专家和MVP Stefan Krüger 有一篇文章关于同样的自我修复问题。他关键性地讨论了实际的事件日志条目及其含义。 请阅读那里的实际调试过程。
一些典型的自修复问题场景：
这是对上面概述中已经概述的几种自修复问题场景的“详细解释”。
许多自我修复问题实际上是由开发人员试图通过动态替换文件、删除文件或重命名来调试应用程序引起的。或者他们可以使用清理注册表脚本和/或批处理脚本来注销和注册 COM 文件、COM-Interop、GAC 文件、文件关联或其他常见的开发人员调试和开发任务。
当通过广告快捷方式启动应用程序时，此热插拔可以触发自我修复。
开发人员在应用程序调试期间遇到自我修复困难的重要提示是不要从公布的快捷方式启动应用程序，而是直接从 Windows 资源管理器或手动创建的快捷方式启动主 EXE。这将绕过最常见的“自我修复入口点” - 广告快捷方式。自我修复仍可能由损坏的 COM 数据、广告文件关联和其他一些特殊情况导致 (阅读这篇赛门铁克文章以获取入口点信息）。
其他应用程序或更确切地说其他 MSI 软件包可能会破坏您的安装并通过干扰注册表数据（通常是 COM 设置，但也可能与其他设置和文件）进行自我修复。这些可能是最难解决的情况，因为应用程序基本上都在战斗，最后运行的每次都会更新注册表。通常，必须重新设计两个 MSI 文件才能使应用程序在同一台计算机上运行。或者，按照惯例，整个应用程序可以被虚拟化（例如：Microsoft App- V 虚拟包）并在自己的沙箱中运行，这似乎是当今公司越来越多的做法。这种错误情况经常出现在企业环境中重新打包不当的应用程序套件中。来自不同包的 COM 片段会覆盖来自另一个包的 COM 服务器的磁盘路径，并且在通过广告快捷方式启动每个应用程序时会发生自我修复战斗。具有不同文件版本的相同文件名也可以从不同的文件位置注册并共享一些干扰的注册表设置。据我所知，文件系统和注册表中至少有 7 个变量或设置必须同步，COM 服务器才能正确实例化。有关 VB6 和 VBA COM 应用程序上下文中 COM 干扰的更专业描述，请参阅下面的第 7 节。
组件键路径指向一个临时文件，该文件已被应用程序删除，或者最终将被系统通过某种清理机制（也可以是清理工具，例如作为清洁剂）。这对于临时文件夹本身中的文件来说很常见。通过不安装临时文件或将该文件放在其他位置并使其永久化可以解决此问题。我在企业应用程序重新打包领域最常看到此错误，其中捕获的图像的错误清理导致安装根本不应该包含在包中的临时文件。通常，它们可能是临时文件，等待重新启动以将其安装到预期的（可能是受保护的位置），并且从未执行重新启动 - 这是常见的应用程序打包错误。在较小程度上，我在自动构建系统的自动生成的包中看到了它。
权限问题：如果组件的密钥文件安装到调用应用程序的用户无法访问的位置。 Windows Installer 可能无法“看到”已安装的文件/密钥路径，或者无法将文件添加到文件夹。这些问题可能难以调试，并且可能不会经常发生。此问题有多种变体：
与终端服务器有关的另一类自我修复问题和 citrix 。整个 Windows Installer Service 都可以锁定，以便为每个用户数据添加的任何自我修复都可能失败，因此自我修复可能会失败或更可能无法运行。这是足够的原因，不依赖自我修复作为添加像某些MSI文件一样添加用户数据的一种方式，并且必须将此类构造替换为从每电机位置复制的用户文件的应用程序部署或较小有效的 < < a href =“ https://stackoverflow.com/questions/1423687/1423687/updating-every-profiles-registriles-registry-registry-on-windows-server-2003/1424819”> activeVeveEtup 每个用户。
vb6应用和 vba应用程序，基于com的 具有 com Interference 的巨大潜力（com）众所周知，设置相互覆盖并变得不一致），引发了一些神秘的自我修复问题，其中大多数尚未得到正确的解释。这也可能发生在Visual Basic 6（VB6）或Visual Studio（以及许多其他应用程序）的启动中。共同点是，当前安装状态中的某些错误触发了自我修复，您可以通过按照上面概述的步骤来追踪罪魁祸首和组件，称为“ 查找”自我修复的触发器或罪魁祸首”。 一定要在此处报告您的发现（我再也不会使用VB6或VBA-您的详细发现可以帮助他人长期以来的烦恼）。
Windows安装程序维修或自我修复的一种特殊情况值得一提，是Microsoft Office几年前的自我修复将被触发的问题，您将是要求插入Microsoft Office安装媒体（当时CD -ROM或DVD-今天也许是Thumb Drives）。据我所记得的，这与对内置Windows安装程序标准操作“ esolvesourvesource ”的错误调用有关，该呼叫意外（并且不必要）触发了安装媒体的提示。 非常常见的支持呼叫回到当天，此处提到了完整性。重要的是要注意，每当从任何可移动媒体中安装MS Office 时，此问题仍然可以发生（而不是网络共享的更好选择）。当MS Office检测到需要进一步安装的产品最初未安装的产品组件（通常共享）组件时，就会发生这种情况。例如，不寻常的拼写检查器，各种模板或特定且较少使用的工具。可以安装这些组件以“首次使用”（广告功能是适当的Windows Installer术语）。
还有许多其他可能的情况。提到一些：
自我修复的良性用途
最终有一次良性用途发生一次，并且不构成错误。这是法律和适当使用自我修复，尽管它可能与设计错误一样令人讨厌，并且通过用户干预，他们可以一次又一次地弹出：
Alternative Answer Available
UPDATE:
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...)
The 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-repair
Windows 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-Repair
The 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)
2. Files or registry keys are deleted by interference from external causes ranging from (logon) scripts to standard OS features, viruses, security software, etc...
3. Windows design changes, flaws or restrictions that causes flawed or problematic deployment
About Self-Repair
Windows 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-repair
The 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:
Alternatively 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.
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.
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:
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).
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:
Benign uses for self-repair
Finally 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: