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

Question

• 如何仅记录由Installshield 2008生成的MSI文件的更改,以通过" 自我修复 " 重新安装？
• 自修的原因是什么？
• 如何使用Installshield 2008禁用MSI的自我修复？

Answer 1

自我修复,简单和简短说明:如果删除文件,为什么MSI安装程序会重新配置？

备选答案可用

更新: 有一个更短,更"解决方案"的答案,或许首先尝试.这个答案侧重于"理解自我修复",而不是解释消除问题的步骤.您可能还想阅读本答案的第一部分.

意外的Windows Installer自修复问题 - 快速修复？

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

• 如果您遇到意外的自我修复,您可以尝试的第一件事是直接手动创建桌面快捷方式,以便在出现问题时启动应用程序可执行文件.这绕过了最常见的自我修复触发器,即" 广告的捷径 ".如果这有效,您的问题就会"解决"(或避免).这是一个快速,充实的解释
• 如果问题仍然存在,或者您的问题与加载MS Office,MS Outlook加载项或类似(无法通过快捷方式启动)相关,那么您很可能在系统上发生COM注册冲突,修复更多涉及.在最简单的尝试是禁用的加载项的任何你不相关应用程序的加载项对话框需要,看看这使问题消失
• If 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 below
  • " 真正的解决方案 "是联系两个应用程序供应商并要求他们解决问题(因为修复通常需要修复两个供应商的MSI),但根据我的经验,这很少成功.尝试一下 - 因为这是帮助每个人长期烦恼的方法!我个人提供了一个针对银行部署的修复程序的设置,并且很高兴在我的程序包中解决了问题
  • To 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 files

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.

我在serverfault.com的答案中写过关于自我修复的问题.用于系统管理员的略有不同的单词,现在阅读它可能是一个比这个长的(用于开发人员)更容易理解的解释.stackoverflow还有另一个较短的答案:为什么MSI安装程序会重新配置,如果我删除文件？(这可能是最短的,也是最容易理解的).最后,我发现了一篇关于Vadim Rapp自我修复的非常好的文章:如何修复Windows Installer自我修复的努力.这篇文章非常值得一读.

如果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本身完成
• 这是一个描述常见MSI设计缺陷的serverfault.com正在进行的工作

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

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

3. Windows design changes, flaws or restrictions that causes flawed or problematic deployment

• An 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 reinstall
• Terminal 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 result
• UAC 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 deployment
• Even 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 behavior
  • Though 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 functionality
  • In 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-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:

• Right click "My Computer"
• Click Manage
• Click continue if you get an UAC prompt
• Go to the Event Viewer section, and check the Windows Logs

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.

• Look in the "Application section" of the event log and you should find warnings from the event source "MsiInstaller" with IDs 1001 and 1004
• In the sample screen shot above the product code is shown inside the red box
• In 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.

1. 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.

2. 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).

3. 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.

4. 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.

5. 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