user7862 Asked: 2009-07-21 09:07:27 +0800 CST2009-07-21 09:07:27 +0800 CST 2009-07-21 09:07:27 +0800 CST 什么可能导致 MsiInstaller 不断重新配置应用程序（EventID 1035）？ 772 我有一台全新的机器，大约两个月前我们刚刚安装了 Windows Server 2008 Enterprise。在事件日志中，我看到记录了数千个 EventID 1035。这是 MsiInstaller 一遍又一遍地重新配置十几个产品，大约每半小时循环一次。 有人见过这个吗？一开始，我进行了一般的网络搜索，大多数解决方案都围绕着作为罪魁祸首安装的戴尔系统中心或谷歌工具栏。 我们没有安装这些产品。 谢谢你的帮助， 戴尔 windows installation windows-installer msi 4 个回答 Voted Stein Åsmul 2009-09-21T11:43:48+08:002009-09-21T11:43:48+08:00 更新： 自修复综合讲解 Windows Installer 为已安装的应用程序提供“自我修复”功能。从本质上讲，这意味着它将继续检查磁盘上的文件和注册表中的设置是否与最初安装的相应软件包相匹配。这些检查通常不会针对软件包安装的所有内容执行，而是针对所谓的“关键路径”执行。 在您看到自我修复循环运行的情况下，这通常意味着系统上的某些进程或另一个 MSI 更改了系统上的设置，随后自我修复的软件包也发生了更改。就像那家伙说的，这就像一个加湿器和一个除湿器在同一个房间里打架——或者是一条追逐自己尾巴的狗。在发现并消除冲突之前，您将一事无成。MSI 文件将一遍又一遍地继续“这是我的资源，我将其改回”。 需要的是识别 MSI 文件或系统进程争吵的冲突：http: //www.installsite.org/pages/en/msifaq/a/1037.htm。 MSI 文件中还有其他可能触发相同问题的设计错误，例如设置为硬编码的用户特定路径的关键路径：C:\Documents and settings\user1\Desktop。其他用户登录时将找不到此路径，并自行修复结果。另一个示例是设置为系统帐户不可写的文件夹的关键路径。又一个例子是设置到临时文件（系统最终将删除）的关键路径。 如您所见，有许多情况，但问题总是相同的：MSI 文件正在检查当前安装是否正确，并找到差异然后尝试修复。 Tony Wall 2013-10-25T11:42:41+08:002013-10-25T11:42:41+08:00 我可以确认问题是由对 Win32_Product 类的 WMI 查询触发的。但正如下面其他问题中所述，如果您没有安装 SCCM/SMS，则不能使用 Win32reg_AddRemovePrograms，即使您必须使用 Win32reg_AddRemovePrograms64 来获取 64 位程序列表 https://stackoverflow.com/questions/2416278/64bit-equivalent-class-for-a-wmi-class-win32reg-addremoveprograms 这些都没有被记录为一件坏事，实际上是正确的做法。我认为微软选择在响应查询的同时进行修复检查只是糟糕的设计。查询永远不应导致系统更改，这应该是不同的“功能”（WMI 方法）。一个明智的设计可以包括定期检查新操作系统的“系统维护”功能，因为这也是可配置的，并且对用户/管理员有意义。 无论如何，这是一台旧服务器，实际上即将退役（Windows 2003 64bit）。但它确实在我们所有的服务器上发生了很多年（现在已经确认这是对性能的重大打击）。所以我必须再次检查较新的 2008 R2 服务器，看看这是否是一个持续的生产问题。 但我真正想知道的是，我怎么能向打包人员和支持工程师团队解释他们不能使用那个 WMI 查询/API。我们有数百个脚本和工具，由许多不同的人为数千个包编写。它永远不会发生。因此，如果在 2008 R2 和其他受支持的操作系统版本中仍然存在这种行为，则 MS 应将其作为关键设计错误进行修复。如果情况仍然如此，我们肯定会升级它！ tomab 2012-03-16T23:57:46+08:002012-03-16T23:57:46+08:00 经过艰苦的研究，我发现这篇 Microsoft 知识库文章表明这些消息可以由组策略过滤器或应用程序查询 Win32_Product WMI 类生成。不幸的是，缩小导致问题的应用程序是困难的。 Glen 2022-07-21T15:55:41+08:002022-07-21T15:55:41+08:00 我知道的旧帖子，但可能对那些在谷歌上搜索错误的人有益。我们发现 Qualy 代理导致我们的设备出现问题。我们已升级到供应商。
更新：
Windows Installer 为已安装的应用程序提供“自我修复”功能。从本质上讲，这意味着它将继续检查磁盘上的文件和注册表中的设置是否与最初安装的相应软件包相匹配。这些检查通常不会针对软件包安装的所有内容执行，而是针对所谓的“关键路径”执行。
在您看到自我修复循环运行的情况下，这通常意味着系统上的某些进程或另一个 MSI 更改了系统上的设置，随后自我修复的软件包也发生了更改。就像那家伙说的，这就像一个加湿器和一个除湿器在同一个房间里打架——或者是一条追逐自己尾巴的狗。在发现并消除冲突之前，您将一事无成。MSI 文件将一遍又一遍地继续“这是我的资源，我将其改回”。
需要的是识别 MSI 文件或系统进程争吵的冲突：http: //www.installsite.org/pages/en/msifaq/a/1037.htm。
MSI 文件中还有其他可能触发相同问题的设计错误，例如设置为硬编码的用户特定路径的关键路径：C:\Documents and settings\user1\Desktop。其他用户登录时将找不到此路径，并自行修复结果。另一个示例是设置为系统帐户不可写的文件夹的关键路径。又一个例子是设置到临时文件（系统最终将删除）的关键路径。
如您所见，有许多情况，但问题总是相同的：MSI 文件正在检查当前安装是否正确，并找到差异然后尝试修复。
我可以确认问题是由对 Win32_Product 类的 WMI 查询触发的。但正如下面其他问题中所述，如果您没有安装 SCCM/SMS，则不能使用 Win32reg_AddRemovePrograms，即使您必须使用 Win32reg_AddRemovePrograms64 来获取 64 位程序列表
https://stackoverflow.com/questions/2416278/64bit-equivalent-class-for-a-wmi-class-win32reg-addremoveprograms
这些都没有被记录为一件坏事，实际上是正确的做法。我认为微软选择在响应查询的同时进行修复检查只是糟糕的设计。查询永远不应导致系统更改，这应该是不同的“功能”（WMI 方法）。一个明智的设计可以包括定期检查新操作系统的“系统维护”功能，因为这也是可配置的，并且对用户/管理员有意义。
无论如何，这是一台旧服务器，实际上即将退役（Windows 2003 64bit）。但它确实在我们所有的服务器上发生了很多年（现在已经确认这是对性能的重大打击）。所以我必须再次检查较新的 2008 R2 服务器，看看这是否是一个持续的生产问题。
但我真正想知道的是，我怎么能向打包人员和支持工程师团队解释他们不能使用那个 WMI 查询/API。我们有数百个脚本和工具，由许多不同的人为数千个包编写。它永远不会发生。因此，如果在 2008 R2 和其他受支持的操作系统版本中仍然存在这种行为，则 MS 应将其作为关键设计错误进行修复。如果情况仍然如此，我们肯定会升级它！
经过艰苦的研究，我发现这篇 Microsoft 知识库文章表明这些消息可以由组策略过滤器或应用程序查询 Win32_Product WMI 类生成。不幸的是，缩小导致问题的应用程序是困难的。
我知道的旧帖子，但可能对那些在谷歌上搜索错误的人有益。我们发现 Qualy 代理导致我们的设备出现问题。我们已升级到供应商。