我有一台全新的机器，大约两个月前我们刚刚安装了Windows Server 2008 Enterprise。 在事件日志中，我看到成千上万的EventID 1035logging。 这是MsiInstaller一遍又一遍地重新configuration十几个产品，每半小时循环一次。
有没有人看过这个？ 作为开始，我做了一般的networkingsearch，大部分解决scheme围绕戴尔系统中心或谷歌工具栏被安装为罪魁祸首。
我们没有安装这些产品。
谢谢你的帮助，
戴尔
更新 ：
Windows Installer为安装的应用程序提供“ 自我修复 ”function。 实际上，这意味着它将继续检查磁盘上的文件和registry中的设置是否与相应的软件包最初安装的内容相匹配。 这些检查通常不是针对软件包安装的所有内容执行的，而是针对所谓的“ 关键path ”执行的。
在自行修理周期运行的情况下，通常意味着系统或其他MSI上的某个进程已经更改了系统上的设置，随后自行修复的程序包也发生了更改。 就像这个家伙说的那样，就像一个加湿器和一个除湿机在同一个房间里一样 – 或者是一条追着自己尾巴的狗。 直到find并消除冲突为止，你无法find任何地方。 MSI文件将继续“这是我的资源，我改变了”一遍又一遍。
所需要的是确定MSI文件或系统进程争吵的冲突： http : //www.installsite.org/pages/en/msifaq/a/1037.htm 。
MSI文件中还存在其他devise错误，可能会触发相同的问题，如关键path设置为硬编码的用户特定path： C：\ Documents and Settings \ user1 \ Desktop 。 这个path不会被其他用户login，并自我修复结果。 另一个示例是将密钥path设置为不可写入系统帐户的文件夹。 又一个例子是设置为临时文件的关键path（系统将最终删除）。
正如你所看到的，有很多情况下，但总是相同的问题：一个MSI文件正在检查当前安装是否正确，并发现它然后尝试修复的差异。
经过艰苦的研究，我发现这篇Microsoft知识库文章指出这些消息可以通过组策略筛选器或应用程序查询Win32_Product WMI类来生成。 不幸的是缩小哪个应用程序导致问题是困难的。
我可以确认这个问题是由Win32_Product类的WMI查询触发的。 但是如下面的其他问题中所述，如果您没有安装SCCM / SMS，则无法使用Win32reg_AddRemovePrograms，即使您必须使用Win32reg_AddRemovePrograms64来获取64位程序的列表
这些都没有被logging为坏事，实际上是作为正确的方式来做到这一点。 我认为微软select在做出响应查询的同时进行修复检查是一个糟糕的devise。 查询不应该导致对系统的更改，这应该是一个不同的“函数”（WMI方法）。 一个明智的devise可能包括对新操作系统的“系统维护”特性进行定期检查，因为这也是可configuration的，对用户/pipe理员是有意义的。
无论如何，这是一个旧的服务器，实际上即将退役（Windows 2003 64位）。 但是，它确实发生在我们所有的服务器上多年（这是对性能的重大打击，现在已经确认）。 所以我将不得不再次检查较新的2008 R2服务器，看看这是否是一个持续的生产问题。
但是我真正想知道的是，我可以向包装工程师和支持工程师团队解释他们不能使用WMI查询/ API。 我们有很多不同的人编写了数百个脚本和工具来处理1000个软件包。 这是不可能发生的。 因此，如果在2008 R2和其他支持的操作系统版本中仍然出现此问题，则应将此行为作为MS的关键devise错误进行修复。 如果仍然如此，我们肯定会升级它！