What could be causing MsiInstaller to continuously reconfigure applications(EventID 1035)?

I can confirm the problem is triggered by WMI queries to the Win32_Product class. But as documented in this other question below, you cannot use the Win32reg_AddRemovePrograms if you don't have SCCM/SMS installed and even if you do would have to use Win32reg_AddRemovePrograms64 to get a list of 64bit programs

https://stackoverflow.com/questions/2416278/64bit-equivalent-class-for-a-wmi-class-win32reg-addremoveprograms

None of this was documented before as a bad thing, actually as the proper way to do it. I think the choice by Microsoft to do a repair check at the same time as responding to the query is just bad design. A query should never cause changes to a system, that should be a different "function" (WMI method). A sensible design could have included a periodic check into their "system maintenance" featrure of the newer operating systems, because that's also configurable and makes sense to users/administrators.

Anyway this was an old server, actually about to be decommissioned (Windows 2003 64bit). But it did happen on all of our servers for many years (that was a major hit to performance now it's confirmed). So I'll have to check again on the newer 2008 R2 servers to see if this will be an ongoing production issue or not.

But what I really wonder is how the heck I can explain to teams of packagers and support engineers that they must not use that WMI query/API. We've got hundred of scripts and tools written by lots of different people for 1000s of packages. There's no way it'll ever happen. So this behaviour should be fixed as a critical design fault by MS if it's still occurring in 2008 R2 and other supported OS versions. We'll certainly escalate it if it's still the case!

UPDATE:

• Comprehensive explanation of self-repair

Windows Installer features "self repair" for installed applications. In essence this means that it will keep checking whether the files on disk and settings in the registry match what the respective package originally installed. These checks are generally not performed for everything that the package installed, but for what is referred to as "key paths".

In situations where you see self repair running in cycles, it generally means that some process on the system or another MSI has changed settings on the system that the package that subsequently self-repairs also changed. Like the guy said, it's like a humidifier and a dehumidifier fighting it out in the same room - or a dog chasing its own tail. You don't get anywhere till the conflict is found and eliminated. The MSI file will keep going "this is my resource, I am changing it back" over and over.

What is needed is to identify the conflict that the MSI files or system processes are quarreling about: http://www.installsite.org/pages/en/msifaq/a/1037.htm .

There are also other design errors in MSI files that can trigger the same problem such as key paths set to hard coded, user-specific paths: C:\Documents and settings\user1\Desktop. This path will not be found for another user logging on, and self repair results. Another example is key paths set to folders that are not writeable for the System account. Still another example is a key path set to a temporary file (which the system will delete eventually).

As you see, there are many scenarios but always the same problem: an MSI file is checking that the current installation is correct, and finds a discrepancy that it then tries to fix.

After a hard research I found this Microsoft KB article indicating that those messages could be generated by group policy filter OR application querying Win32_Product WMI class. Unfortunately narrowing down which application is causing the problem is difficult.