启动应用程序触发重复无休止的Windows Installer自修复时，我该怎么办? [英] What do I do when launching an application triggers repeating, endless Windows Installer self-repair?

问题描述

Windows Installer的自我修复可能对开发人员，系统管理员和最终用户都造成问题.如果您的MSI经验有限，则很难找到解决方案.

Windows Installer self-repair can cause problems for both developers, system administrators and end users. Finding the solution can be difficult if you have limited MSI experience.

这是一种问答式的回答，旨在作为解决自我修复问题的核对清单 .以下是一些常见的问题场景:

This is a Q&A-style answer intended as a check list for solving self-repair problems. Here are a few common problem scenarios:

• 每当您在工作站上启动应用程序时，都可能发生重复的Windows Installer自修复.如何解决此问题，或如何禁用组件以使其不再发生?
• 可能会部署WiX安装程序，并且每次尝试启动该应用程序时，都会看到Windows Installer自我修复的情况.
• 启用或安装MS Office加载项时，在应用程序启动一个或多个MS Office应用程序时，您会不断进行Windows Installer自修复.
• 在VB6或VBA中使用旧式解决方案时，启动主开发人员IDE时会为不相关的产品进行自我修复.
• 在Outlook，Excel或Word或类似应用程序中打开表单时，对于来自其他供应商的不相关产品，将启动自我修复.

关键字:Windows Installer意外启动. MSI意外显示. Windows Installer每次都会出现.打开应用程序启动Windows Installer. Windows Installer自愈.包裹如何自我修复. MSI自我修复最佳实践. Windows Installer修复.自我修复.禁用Windows Installer. Windows Installer反复运行.应用程序快捷方式将启动安装程序. Windows Installer意外出现.

Keywords: Windows Installer launches unexpectedly. MSI displays unexpectedly. Windows Installer appears every time. Opening Application Starts Windows Installer. Windows Installer self healing. How does a package self-heal. MSI self-heal best practice. Windows Installer repair. Self-Repair. Disable Windows Installer. Windows Installer repeatedly runs. Application Shortcut launches installer instead. Windows Installer appears unexpectedly.

推荐答案

自我修复，简单&简短说明 :

---

您的WiX/MSI文件的具体设计建议

我一直在尝试撰写有关为开发人员重复进行MSI自修复的内容，但最终的细节太多了.这是我的最后一次尝试:

---

Concrete Design Advice for your WiX / MSI File

I keep trying to write about repeating MSI self-repair for developers, but end up with too much detail. Here is my last attempt: concrete design advice for what not to do in your WiX / MSI file.

下面的答案提供了一个清单，用于解决任何自我修复的情况-来自任何供应商或来源，而不仅仅是您自己的.查看上面链接的答案，以解决您自己的MSI封装设计问题.

The answer below provides a checklist for solving any self-repair scenarios - from any vendor or source, not just your own. Check the answer linked above for your own MSI package design concerns.

要永久且可靠地修复每个人的自我修复问题，必须参与开发人员和设置开发人员，因为真正的修复必须在供应商级别进行.

To permanently and reliably fix self-repair problems for everyone, developers and setup developers must be involved since the real fix must happen at the vendor level.

如果您处于公司环境中，劣质的应用程序重新打包也可能导致自我修复问题，因此，您应该请应用程序打包程序来确定是否问题是来自供应商还是来自供应商.

If you are in a corporate environment, poor-quality application re-packaging can also cause self-repair problems, and you should involve your application packagers to determine if the problem is from the vendor or not.

系统管理员必须知道他们在看什么，并且在没有可用的修复程序时，请使用各种变通办法来解决该问题.甚至最终用户都可以自己尝试一些简单的解决方法(请参阅第5节).

System administrators must know what they are looking at, and when no fix is available, use various workarounds to deal with the problem in the wild. Even end users can try some easy workarounds themselves (see section 5).

自我修复问题的本质 :

The essence of self-repair problems:

• 大多数自我修复问题与COM相关，并且供应商和开发人员有两个常规修复程序:1)正确使用部署的，通常通过合并模块部署的共享COM库，或2)使用无需注册的COM来屏蔽"您的应用程序免受自我修复和兼容性问题的影响.
  • 您的设置开发人员可以实施合并模块修复，开发人员必须进行测试.合并模块是用于共享文件的标准化共享部署库.
  在我的经验中，
  • 无需注册的COM 仅在开发人员参与的情况下有效.如果开发人员需要使用COM文件的特定版本(无论出于何种原因)，则此选项特别有用.详情请参阅下文的5.4节.
  • Most self-repair issues are COM-related, and there are two general fixes for vendors and developers: 1) use the properly deployed, shared COM libraries generally deployed via merge modules, or 2) use registration-less COM to "shield" your application from self-repair and compatibility issues.
    • Your setup developer can implement the merge module fix, developers must test. Merge modules are standardized, shared deployment libraries for shared files.
    • Registration-less COM only works with developer involvement in my experience. This option is particularly relevant if the developer needs to use a particular version of a COM file (for whatever reason). Details in section 5.4 below.

    如果您确定所看到的自我修复仅由MSI引起(而不是由MSI引起)，也许直接跳转至第5部分以获取建议的修复和解决方法列表.其他外部原因，如以下前几节所述.

    Perhaps jump straight to section 5 for the list of suggested fixes and workarounds if you are sure the self-repair you see is caused by MSI alone (and not by other, external causes as described in the first few sections below).

    第5节中提出的大多数解决方案"实际上大部分是系统管理员技巧，不能解决根本的问题-如上所述，真正的解决方法必须来自供应商.例外是"5.4:无需注册的COM"，它实际上可以帮助开发人员屏蔽"其应用程序免受自我修复问题的影响.

    Most of these proposed "solutions" in section 5 are really mostly system administrator tricks that don't fix the underlying problem - as stated above the real fix has to come from the vendor. The exception is "5.4: registration-less COM", which can actually help developers "shield" their applications from self-repair problems.

    如果您没有管理员权限，建议您尝试解决方案" 5.2 ， 5.3 或 5.1 (5.1通常需要管理员权限才能尝试，但这并不复杂).这些是"快速解决方法"，其他则涉及更多.如果这些解决方法不起作用，请让您的管理员阅读其他建议.

    If you don't have admin rights on your box you are advised to try "solutions" 5.2, 5.3 or 5.1 (5.1 will generally require admin rights to try, but it is non-complicated). These are "quick workarounds", the others are more involved. If these workarounds don't work, please ask your admin to read the other suggestions.

    之前，我已经写了很多篇关于这个问题的文章，但是它过于专注于理解问题，而不是为它实际找到可以接受的解决方案.您可以在此处阅读有关自我修复问题的完整说明:

    I have written at length about this issue before, but it focused too much on understanding the problem rather than actually finding an acceptable fix for it. You can read the full explanation of self-repair problems here: How can I determine what causes repeated Windows Installer self-repair?.

    要真正解决重复不断的自我修复问题，可以尝试以下第5节中的建议-以复杂性和难度递增的顺序.在这样做之前，您应该验证自我修复问题的真正根源是什么.可能不是由MSI文件引起的，而是由其他外部原因引起的(例如脚本或用户删除文件或防病毒阻止文件).

    To actually fix repeated and endless self-repair, you can try the suggestions below in section 5 - in increasing order of complexity and difficulty. Before doing so, you should verify what the real source of the self-repair problem really is. It might not be caused by MSI files, but by other, external causes (such as scripts or users deleting files or anti-virus blocking files).

    如果问题确实与MSI相关，则可以尝试禁用广告的快捷方式和 COM插件，使用无需注册的COM ， 从应用程序供应商那里获取帮助，卸载有问题的应用程序，虚拟化软件包或完全破解缓存的MSI数据库和注册表 >(不推荐，只有在专家帮助下才有可能).这完全取决于您的情况.如果脚本等外部原因有误，则必须消除这种干扰.请在下面查看详细信息-只需遵循清单即可.

    If the problem is indeed MSI-related, you can try to disable advertised shortcuts and COM addins, use registration-less COM, get help from the application vendor, uninstall offending applications, virtualize packages or full on hack the cached MSI database and registry (not recommended, and only really possible with expert help). It all depends on your scenario. If external causes such as scripts are at fault, you must eliminate this interference. See details below - just follow the check-list.

    解决问题的第一步是确定问题确实存在于您的平台上，然后首先确定哪些应用程序触发自我修复:

    The first steps for problem solving are to identify that the problem really exists in the wild on your platform, and then to determine what application(s) trigger the self-repair in the first place:

    • 通常总是可能弄清楚正在发生的事情会导致有问题的自我修复，并且有几种可行的解决方法可以用来解决问题.但是，并非总能找到一个好的永久性修复程序(没有供应商的帮助-如下所述).
      • 因此，如果您是系统管理员，试图找到针对您的自我修复问题的修复程序，则可能要确保在多台计算机上发现了该问题-尤其是在 developer- ，质量检查-，甚至是测试计算机.
      • 如果您仅在一台计算机上看到自我修复问题，则可以选择重建有问题的计算机.有效地消除而不是解决"问题.但是，您可能会相对较高的风险 再次遇到问题.如果您问我，不要重建，那不是解决方案-但我想在现实世界中通常会做些什么.
      • It is generally always possible to figure out what is going on to cause the problematic self-repair, and there are several viable workarounds that can be utilized to deal with the problem. It is, however, not always possible to find a good, permanent fix (without vendor help - as described below).
        • Accordingly, if you are a system administrator trying to find a fix for your self-repair issue, perhaps make sure the problem is seen on more than one computer - especially if the problem is seen on a developer-, QA- or even a test computer.
        • If you only see self-repair problems on one computer, an alternative might be to rebuild the problem computer. Effectively eliminating rather than "solving" the problem. There is a relatively high risk that you might see the problem again though. If you ask me, don't rebuild, it is no solution - but what tends to be done in the real world I guess.
        • 单个应用程序可能会自行导致问题，但通常至少有两个应用程序发生冲突(它们错误地共享了一些资源)
        通常，可以在您的事件查看器中找到进行自我修复的系统上的
        • 自我修复触发.请按照以下步骤打开事件查看器:
          • 右键单击我的电脑"
          • 点击管理
          • 如果出现UAC提示，请单击继续"
          • 转到事件查看器"部分，然后检查Windows日志
          • It is possible for a single application to cause the problem on its own, but typically there are at least two applications that conflict (they share some resource by mistake).
          • 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
            • 您可以在以下更详细的答案中找到有关如何执行此操作的更多详细信息: 找到用于自我修复的触发器或罪魁祸首"部分.
            • 您还可以尝试来自独立部署专家， MSI专家和 MVP StefanKrüger .他有一篇关于同一自我修复问题的文章.并且他至关重要地讨论了实际事件日志条目及其含义. 请在此处了解实际的调试过程 .
            • You can find a lot more details on how to do this in the more elaborate answer here: How can I determine what causes repeated Windows Installer self-repair?. Look in the "Finding the trigger or culprit for the self-repair" section.
            • You can also try the advice from independent deployment specialist, MSI-expert and MVP Stefan Krüger. He 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.
            • 删除文件或注册表设置的任何手动或自动操作都可以触发MSI自修复. 尤其是如果您想删除用户个人资料或注册表的HKCU部分中的内容.
              • 在大多数情况下，此类触发器只会导致运行单次自我修复，并且然后问题得以解决(这是应该进行自我修复的方式，帮助用户).允许自我修复运行一次，然后再次启动应用程序以测试问题是否消失.应该是这样，并且您的应用程序应该从现在开始正确启动.
              • 特殊情况:具有讽刺意味的是，有时您可以通过重命名HKCU应用程序密钥(在注册表的用户部分)来修复损坏的应用程序，以实际强制自我修复程序运行并安装该应用程序的默认数据在用户个人资料中-如果该数据被意外删除(这种类型的修复通常在终端服务器上不起作用).
              • 如果通过自动方式再次删除了相同的文件或注册表项并导致自我修复，则必须消除或更新引起该问题的自动过程，并且问题已解决，您可以停止阅读.如果您自己再次手动删除了文件，则可能会遇到内存不足的问题:-).
              • 摘要清理脚本，登录脚本，清理应用或修补过度活跃的用户都可能导致此情况一种自我修复.
              • Anything that deletes files or registry settings, manually or automatically, can trigger MSI self-repair. Especially if you are messing around deleting stuff in the user profile or in the HKCU section of the registry.
                • In most cases such triggers will only cause a single self-repair to run and then the problem is fixed (this is how self-repair is supposed to work and help users). Allow self-repair to run once and then launch the application again to test if the problem is gone. It should be, and your application should launch correctly from now on.
                • Special case: Ironically you can sometimes fix a broken application by renaming its HKCU application key (in the user section of the registry) to actually force self-repair to run and install the application's default data in the user profile - if that data was accidentally deleted (this type of fix generally does not work on terminal servers).
                • If the same file or registry entry is deleted again by automated means and self-repair results, you must eliminate or update the automatic process that is causing it and your problem is solved and you can stop reading. If you manually deleted the file again yourself, then you may suffer from bad memory :-).
                • In summary cleanup scripts, logon scripts, cleanup applications or tinkering, overactive users can all cause this kind of self-repair.
                • 对于受感染的计算机，只需重建计算机即可.这样可以为您节省总体时间.
                • 对于防病毒/安全软件问题，请请安全专家来解决.在某些情况下，他们可能需要与供应商联系(尤其是对于误报).
                • 无论与病毒或杀毒软件相关，请检查 http://www.virustotal.com 验证它是病毒还是假阳性(这对于自我修复可能是一个更大的问题).
                • 我个人已经看到了一些与防病毒/安全软件有关的自我修复问题，但是到目前为止，还没有真正的与病毒有关的问题.我猜病毒通常会感染核心系统文件而不是应用程序文件，并且核心系统文件不会由MSI文件部署(共享的系统文件可能包含在MSI文件中，而不包含在核心系统文件中).
                • For an infected computer, just rebuild the computer. It will save you time overall.
                • For anti-virus / security software problems, bring out your security guys to solve it. They may need to contact the vendor in some cases (particularly for false positives).
                • Whether virus or anti-virus related, check the offending file on http://www.virustotal.com to verify whether it is actually a virus or just a false positive (which can be an even bigger problem for self-repair).
                • Personally I have seen several anti-virus / security software related self-repair problems, but no real virus-related problems (so far). I guess viruses normally infect core system files rather than application files, and core system files are not to be deployed by MSI files (shared system files might be included in MSI files, but not core system files).
                • 一旦您确认自我修复问题是基于MSI的，而不是您自己的软件，则首先要尝试联系应用程序供应商，看看他们是否拥有更新的安装程序来消除该问题.

                • 尝试使用此选项很重要，因为所有其他选项都是变通办法"，而不是真正的解决方案.只有通过供应商安装程序的更改(可能是应用程序可执行文件本身)，才能永久完全解决问题.

                • Once you have verified that the self-repair problem is MSI-based and it is not your own software, the first thing to try is to contact the application vendor(s) and see if they have an updated installer to eliminate the problem.

                • It is important to try this option since all other options are "workarounds" and not real fixes. The problem can only be completely resolved permanently by changes in the vendor installer and possibly the application executable itself.

                • 修复1 :修复方法很简单，即让供应商使用适当的共享"合并模块"删除私下安装但已全局注册的COM文件，以安装该文件.正确地为每个人运行.这些应将COM文件正确安装到共享位置，在此处可以进行全局注册而没有副作用.准备供所有人使用.
                • 修复2 :如果供应商声称这是不可能的-那么他们应该能够提供正确的无注册COM安装，并将正确隔离的COM文件安装到主应用程序文件夹中.他们还应随时注意部署任何安全更新.
                • Fix 1: The fix can be as simple as having the vendor remove privately installed but globally registered COM files with the appropriate, shared "merge module" to install the run-time correctly for everyone. These should install COM files properly to shared locations where they can be globally registered without side effect. Ready for everyone's use.
                • Fix 2: If the vendor claims this isn't possible - then they should be able to provide a proper registration-less COM installation with properly isolated COM files installed to the main application folder. They should also take care of deploying any security updates whenever they would come along.

                重要！:如果供应商使用正确的共享合并模块来部署文件，或者使用以下命令提供隔离安装无需注册的COM ，然后该问题应该永久地为所有人解决.

                Important!: If the vendor either uses the correct, shared merge module to deploy files or provides an isolated installation using registration-less COM, then the problem should be solved permanently for everyone.

                • 如果供应商不提供固定的安装程序包，则需要找到一种替代方法"来解决这种情况.有多种选择，在尝试过多的复杂性之前，应尝试一些"快速解决方法".以下是一些问题解决建议，以增加难度和复杂度的顺序进行:

                • If the vendor(s) won't provide a fixed installer package, you need to find a "workaround" to deal with the situation. There are several options, and some "quick workarounds" should be tried before you delve into too much complexity. Here are some problem solving suggestions in order of increasing levels of difficulty and complexity:

                • 5.1:只需卸载罪魁祸首.

                  • 最简单的绝对修复方法是找出哪些应用程序触发了自我修复，然后将其卸载(如果您的环境可以接受这种解决方案(很少见)).
                  • 如果有两个(或多个)应用程序发生冲突，并且其中一个应用程序很少使用或为可选"，则可以接受.
                  • 您可以改为在虚拟机上运行问题应用程序(请参阅第5.5节).对于非常行为异常"的应用程序，这将是我的首选解决方案".所有问题都应该消失，而无需任何实际调试(这是昂贵的).
                  • 简单卸载是一个至少值得考虑的选项-某些软件的问题可能不止一种，而应仅被拒绝使用.确保让供应商知道该软件也被拒绝.这可能是使他们认真对待问题的唯一方法.

                  • 5.1: Just uninstall the culprit(s).

                    • The absolute simplest fix is to figure out what application(s) trigger(s) the self-repair and just uninstall it, if that is an acceptable solution for your environment (it rarely is).
                    • This can be acceptable if there are two (or more) applications in conflict and one of them is rarely used or "optional".
                    • You can run the problem application on a virtual machine instead (see section 5.5). This would be my preferred "fix" for a very "misbehaving" application. All problems should disappear without any real debugging (which is costly).
                    • Plain uninstall is an option that is at least worth considering - some software can be very problematic in more ways than one, and should simply be rejected for use. Be sure to let the vendor know that the software was rejected as well. It might be the only way to make them take the problem seriously.
                    • 尝试使用的第一个Windows Installer解决方法是删除" 发布的快捷方式 "(本质上是一种特殊类型的快捷方式，它指向Windows Installer应用程序功能，而不是直接指向可执行文件或文件).阅读Symantec的链接文章，以了解有关宣传的快捷方式的详细信息.
                      • 请注意，可以在任何位置创建快捷方式，包括在特殊文件夹(如启动"文件夹)中.此特定位置意味着可以在系统启动时自行触发自我修复(无需用户交互).
                      • 使用 MSI查看器工具并打开系统缓存的MSI，并检查其快捷方式"表以查找所有快捷方式.为了找到所有缓存软件包的列表，您可以尝试以下答案:
                      • The first Windows Installer workaround to try is to remove "advertised shortcuts" (essentially a special type of shortcut that points to an Windows Installer application feature, and not directly to an executable or file). Read the linked article from Symantec for details on advertised shortcuts.
                        • Note that shortcuts can be created "anywhere" including in special folders such as the "Startup" folder. This particular location means a self-repair can be triggered by itself on system startup (without user interaction).
                        • Use an MSI viewer tool and open the system-cached MSI and inspect its Shortcut table to find all shortcuts. In order to find a list of all cached packages you can try this answer: How can I find the product GUID of an installed MSI setup? (open the package path specified in "LocalPackage").
                        • 1):该软件包可以设计为使用自我修复功能来安装用户配置文件或HKCU设置.在这种情况下，由于永远不会运行自我修复，并且安装实际上是不完整的，因此这些数据将永远不会按预期添加到系统中.
                        • 2)不能保证不会继续进行自我修复-因为它可以由其他公告的入口点(例如COM调用，文件和MIME关联以及命令动词)触发./li>
                        • 1) The package could be designed to use self-repair to install userprofile files or HKCU settings. In this case this data will then never be added to the system as intended since self-repair will never run, and the install is effectively incomplete.
                        • 2) There is no guarantee that self-repair won't still occur - since it can be triggered by other advertised entry points such as COM invocation, file and MIME associations and command verbs.
                        • 如果您的问题与加载项的加载有关(适用于Outlook，Excel，Word或其他类似AutoCAD或类似应用程序的应用程序)，则没有可进行调整的快捷方式-加载项为在其主机应用程序"启动时加载.
                        • 最容易尝试的方法是在有问题的应用程序的插件对话框中禁用所有不需要的插件(通常 Outlook ， Excel 或 Word 或相似)，看看是否可以解决问题.在某些情况下，您只是禁用了用户最初从未使用过的COM插件，因此问题已消除.
                        • 而且很显然，还尝试禁用您实际需要的插件，以便检查问题是否可能与其加载有关.如果外来元凶是罪魁祸首，则应继续从检查清单中移至下一个建议的解决方案(下一个要点).
                        • 我要重申，首选解决方案是供应商提供的修复程序(大多数情况下，它涉及使外接程序正确使用相关的最新的共享ActiveX/OCX控件-其他外接程序)但是，即使它们的设计不当，仍然可能会引发问题.您最终可能会与多个供应商打交道-通常会互相指责.
                        • 为了公平起见，如果您使用的是公司计算机，则公司应用程序重新打包不正确也可能导致此问题.然后，您必须与包装部门联系以寻求修复.
                        • If your problem is related to the loading of an add-in (for Outlook, Excel, Word or other apps like AutoCAD or similar), then there are no shortcuts to tweak - the addin is loaded on launch of its "host application".
                        • The easiest to try is to disable any addins you don't need in the addins dialog of the application in question (often Outlook, Excel or Word or similar) and see if this makes the problem go away. In some cases you are just disabling COM addins that users never used in the first place, and the problem has been eliminated.
                        • And, rather obviously, also try to disable addins that you actually need as well, in order to check if the problem can be related to its loading. If the addin is the culprit, you should continue down the check list to the next proposed solutions (next bullet points).
                        • I should re-iterate that the preferred solution would be a fix from the vendor (most often it would involve making the addin properly use the latest, shared ActiveX/OCX controls in question - other addins could still trigger the problem though, if they are also badly designed. You could end up dealing with multiple vendors - usually blaming each other).
                        • In fairness to the vendors, the problem can also be caused by bad corporate application repackaging - if you are on a corporate machine. Then you must deal with the packaging department for a fix.
                        • 可以说，该解决方案比虚拟化更为复杂(在下一个要点中进行介绍)，但是我将其放在此处，因为它可能是某些人的首选.
                        • 无需注册的COM 是我很少使用的东西，但据说它是一种可行的解决方案:
                        • 您的内部包装部门可能可以使用它来处理困难的供应商包装"以隔离"他们的问题.但是，我不相信无需注册的COM就能在原始解决方案开发人员做出一些其他应用程序调整的情况下正常工作，但是我缺乏经验数据来支持它.如果它是一个内部应用程序，并且有可用的源代码，请对其进行一次测试(并告诉我们).
                        • 我的这种方法的主要问题是，如果您不这样做，它会打开潜在的安全漏洞(COM文件的私人副本，Microsoft永远不会对其进行修补).不能确保隔离的组件可以自己更新.更新可能也会导致很多清单重写工作(但是这些旧的COM文件是否仍会更新吗?)
                        • 请注意，至少从理论上讲，无需注册的COM可以用于所有与COM相关的冲突，无论它们是VB6可执行文件，使用COM的VC ++应用程序，等等. (办公室)COM加载项(dll)和VBA表单.
                        • 这似乎是关于无注册COM的MSDN更好的文章之一):正确的供应商修补程序是要停止部署在系统范围内错误注册的共享COM文件的私有副本，然后启动使用适当的部署合并模块按预期安装它们.
                        • Arguably this solution is more complicated than virtualization (which is described in the next bullet point), but I put it here since it might be a preferred option for some people.
                        • Registration-less COM is something I have rarely used, but it is said to be a viable solution: Generate manifest files for registration-free COM. This essentially bypasses the registry and activates private copies of the COM files controlled by manifest file(s) placed next to the application executable(s) - effectively shielding the application from COM registry interference (in theory). "Everything happens in the same folder".
                        • Your in-house packaging department might be able to use this to deal with "difficult vendor packages" to "isolate" their problems. However, I am not convinced registration-less COM will work properly without a few additional application tweaks contributed by the original solution developer, but I lack the empirical data to back it up. If it is an in-house app with source available, give it a test spin (and let us know).
                        • My main problem with this approach, is that it opens up potential security holes (private copies of COM files that will never be patched by Microsoft), if you don't make sure the isolated components are updated yourself. Updates would likely cause lots of manifest-rewrite work as well (but are these old COM files updated at all anymore anyway?)
                        • Note that registration-less COM, at least in theory, can be used for all COM related conflicts, whether they are VB6 executables, VC++ applications that use COM, etc... I am honestly not sure if it works properly for (office) COM addins (dlls) and VBA forms.
                        • Here is what appears to be one of the better MSDN articles on registration-less COM): https://msdn.microsoft.com/en-us/library/ms973913.aspx (there is even a downloadable MSI with the samples - which ironically seems to trigger an error for me on launch).
                        • Personally I would probably rather try a virtual package using APP-V rather than trying to use registration-less COM (see next bullet point).
                        • It should be re-iterated that rather than "shielding" your own application - the correct vendor fix is to stop deploying private copies of shared COM files that are erroneously registered system-wide, and start installing them as intended using the appropriate merge module for deployment.
                        • 除了卸载或禁用组件外，最简单的解决方法可以说是使用虚拟化来隔离"发生冲突的应用程序.如果仍然需要将应用程序放在主SOE(标准操作环境)上，则可以尝试使用虚拟部署程序包(APP-V).这是一个基本上按需安装(在启动时)并运行沙盒"或与系统中其他应用程序隔离的应用程序.
                        • 您还可以通过 VMWare 或 Microsoft Virtual PC 之类的系统使用虚拟机，以在其自己的操作系统中运行有问题的应用程序.人们在使用虚拟机时通常具有管理员权限，但不在其主SOE系统(主工作站)上.许多开发人员应用程序可以更有效地使用管理员权限，因此在与开发团队及其需求打交道时，此解决方案可能特别有用.
                        • Apart from uninstalling or disabling components, the simplest fix is arguably to use virtualization to "isolate" the applications that conflict. If you still want the applications on your main SOE (Standard Operating Environment), you could try to use a virtual deployment package (APP-V). This is an application that is basically installed on demand (on launch) and runs "sandboxed" or isolated from other applications on the system.
                        • You can also use a virtual machine via systems such as VMWare or Microsoft Virtual PC to run the problematic application(s) in their own operating system. Often people have admin rights when using virtual machines, but don't on their main SOE system (main workstation). Many developer applications are more effective to use with admin rights, so this solution might be particularly useful when dealing with development teams and their requirements.
                        • 如果该问题对于您的桌面环境非常严重，并且以上选项均无效，则可以尝试在Windows Installer级别修复该问题.如果外接程序(或任何其他软件)对于在公司的主要PC环境中可用至关重要，那么这可能是值得的.
                        • 基本上，您需要做的是从系统缓存的MSI和/或注册表中删除有问题的条目(禁用广告的入口点，例如广告的快捷方式，COM注册，文件关联，MIME关联或命令动词等). .
                          • 这是非常复杂的操作，不是很好的做法，并且有一些副作用(如卸载，弹性等)，但这是我所知道的唯一的最后手段".
                          • 在这种情况下，建议您联系部署/Windows Installer专家，并让他们分析是否可以进行修复".它可以工作，但不要指望奇迹.
                          • 如果您坚持要调试自己，则需要掌握一种工具才能在系统上打开缓存的MSI文件(
                          • If the problem is very serious for your desktop environment and none of the options above work, you can try to fix the problem at a Windows Installer level. It might be worth it if the addin (or whatever other software) is crucial to have available on the company's main PC environment.
                          • Essentially what you need to do is remove offending entries from the system cached MSI and/or the registry (disable advertised entry points such as advertised shortcuts, COM registration, file associations, MIME associations or command verbs, etc...).
                            • This is very involved and not good practice to do, and there are some side-effects (for uninstall, resiliency, etc...), but it is the only "last resort" that I know about.
                            • In these cases you would be advised to contact a deployment / Windows Installer expert and have them analyze whether a "fix" is possible. It can work, but don't expect miracles.
                            • If you insist on debugging yourself, you need to get hold of a tool to open cached MSI files on the system (such as Orca, Installshield, Advanced Installer or similar) and you need to "hack" the database - not recommended.
                            • 出于完整性考虑，我会添加此选项"，如果您愿意，还包含"历史目的".从来都不是一个好的选择，现在在新版本的Windows上已经非常不安全.
                            • MsiZap.exe是Microsoft SDK工具，旨在作为开发人员清除失败的MSI安装或卸载的最后手段，它从未打算广泛使用.它允许任何MSI程序包的完全脏注销". MsiZap.exe 现在已被弃用，不受支持和不安全.如果有的话，仅在一次性虚拟机上使用.
                            • 过去，常见的"系统管理员技巧"是使用 MsiZap.exe 整体上" zap "系统中的Windows Installer程序包.除了使您的系统变得无法治愈之外，它还消除了该应用程序的所有自修复问题.
                            • 留下的垃圾在运行MsiZap.exe 之后，基本上包括了所有内容(实际的MSI数据库注册除外).所有文件，所有注册表项(包括COM)，SharedDll ref计数器(在重新安装时确实搞砸了事情)，服务，任何其他内容.您将永远无法正确卸载.在大多数情况下，您将无法安装同一应用程序的升级版本，而不会产生副作用.在尝试在脏状态之上安装之后，实际上很多人之后会看到更多的自我修复问题.
                            • Rob Mensching，WiX，Orca和Windows Installer具有的所有功能的创建者
                            • I am including this "option" for completeness and "historical purposes" if you like. It was never a good option, and is now very unsafe on newer versions of Windows.
                            • MsiZap.exe was a Microsoft SDK tool meant as a last-resort tool for developers to clean out failed MSI installs or uninstalls, it was never intended for widespread use. It allowed the complete "dirty unregistration" of any MSI package. MsiZap.exe is now deprecated, unsupported and unsafe to use. Use only on throwaway virtuals, if at all.
                            • Back in the day a common "system administrator trick" was to use MsiZap.exe to "zap" a whole Windows Installer package from the system. Besides leaving your system incurably dirty, it also removed all self-repair problems for that application.
                            • The junk that is left behind after running MsiZap.exe includes essentially everything (except the actual MSI database registration). All files, all registry entries (including COM), SharedDll ref counters (which really screw up things on reinstall), services, anything really. You will never be able to uninstall properly. In most cases you will fail to install upgraded versions of the same application without side effects. Many people actually see more self-repair problems afterwards when trying to install on top of the dirty state.
                            • Rob Mensching, creator of WiX, Orca and all things Windows Installer has a blog post on the perils of MsiZap. MSDN describes another bad side effect: All program update information is removed when you use the Msizap.exe tool to uninstall a program from a Windows-based computer
                            • 步骤4 -与供应商联系以寻求修复-我认为是唯一的"实际修复".
                              • 所有其他建议都试图解决由供应商错误引起的问题，而不是提供持久的解决方案.
                              • 现实世界中的问题是，许多供应商往往会互相指责，因此您可能会不走运.一些做得对的供应商确实遭受了其他设计错误的困扰.
                              • Step 4 - contacting the vendor for a fix - is the only "real fix" in my opinion.
                                • All other proposals try to deal with the problems that result from vendor errors, rather than provide a lasting solution.
                                • The real-world problem is that many vendors tend to blame each other, so you might be out of luck. And some vendors who do it right, do suffer from the design errors of others.
                                • 应该可以安全地为每个人尝试.
                                • Proposals 5.2 and 5.3 should be possible to try even without admin rights.
                                • Should be safe to try for everyone.
                                • Proposals 5.2 and 5.3 should be possible to try even without admin rights.
                                • Developer involvement might be required to find all dependent files to "isolate".
                                • In my experience this is the kind of project that ends up taking days to try out (even with expert help) - without a real guarantee that it will eventually work.
                                • I hear conflicting things from experts, some have succeeded, some say it fails. The people with access to the solution source seem to succeed.
                                • Personally i don't like it for the potential security holes it opens up, and any new file versions to deploy could mean a new round of manifest re-authoring (I believe).
                                • However the COM files in question are so old now that it is rather unlikely that they will see any security updates made to them anyway. I suppose these COM objects are mostly used for .NET interop nowadays.
                                • I honestly don't know (lack experience) if virtualization is viable for (office) addins. Please update if you can confirm.
                                • Executables can definitely be virtualized.
                                • There are some "side effects", particularly for uninstall - and also for "resiliency", but these should be manageable if done right.
                                • It is the "real world" - nothing is "clean".
                                • There are some "side effects", particularly for uninstall - and also for "resiliency", but these should be manageable if done right.
                                • It is the "real world" - nothing is "clean".
                                • There are several side effects due to the system's "dirty state".
                                • Total corruption of the MSI database has been reported after running MsiZap.exe.
                                • There are several side effects due to the system's "dirty state".
                                • Total corruption of the MSI database has been reported after running MsiZap.exe.

                                这篇关于启动应用程序触发重复无休止的Windows Installer自修复时，我该怎么办?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！