12 replies to this topic

[reflex]

A client of ours has installed our software and they are experiencing some odd Windows Installer behaviour.

The software installs fine and they can then use it without a problem.
They then shut the computer down and log in as the same user. When they start our software up the windows installer kicks in again and runs through the configuration process.

Now I would understand if they had logged in as a different user or if they had deleted user settings or something but in this case its the same user with no modifications.

Anyone got any suggestions?

Regards
Reflex.

[Stefan Krueger]

Take a look at Windows' event log to see what triggers this auto-repair.

[reflex]

This was the first piece of info that I asked for and there is no trigger for the self-repair (normally it would report which component it was looking for).

All that is there is "<Product> configuration completed successfully".

[Stefan Krueger]

In this case I suggest you enable installer logging using the registry emthod. This should generate a log of the repair in the temp folder.

[reflex]

Thanks Stefan,

please excuse the ignorance, but how would I set the installer to log using the registry?

[reflex]

Please ignore the last post,

I do know how to enable normal logging, I normally use te group policy editor rather than edit raw registry values.

Kind Regards

Reflex.

[reflex]

I got the log file from the client and I cant see anything untowards in it (nothing that says what is kicking off the reinstall).

Can I attach the log file here?

Kind Regards

Reflex

[Glytzhkof]

reflex, this is not something I have experienced myself, but I believe I read somewhere in passing that COM/COM+ components can trigger very mysterious self repairs.

Other things I have seen: components pointing to empty folders, a component pointing somewhere in the temp folder, a keypath set to a location in the registry where the user does not have write access, roaming profiles (no idea why, but I have had mysterious self repairs kick in when using roaming profiles with no clear cause), faulty merge modules: http://forum.install...?showtopic=8723, etc... The log file would be useful.

[reflex]

The first avenue I went down was that a component was misconfigured or something like that but there was no entry in the Application Event Log saying anything of the sort.

Below are the opening lines of the Windows Installer log, maybe someone can spot something that I am missing.

Thanks for all your help so far,

Reflex.

-----Windows Installer Log-----

MSI © (34:94): Resetting cached policy values
MSI © (34:94): Machine policy value 'Debug' is 0
MSI © (34:94): ******* RunEngine:
******* Product: c:\Temp\_Sfx922\Product.msi
******* Action:
******* CommandLine: **********
MSI © (34:94): Machine policy value 'DisableUserInstalls' is 0
MSI © (34:94): SOFTWARE RESTRICTION POLICY: Verifying package --> 'c:\Temp\_Sfx922\Product.msi' against software restriction policy
MSI © (34:94): Note: 1: 2262 2: DigitalSignature 3: -2147287038
MSI © (34:94): SOFTWARE RESTRICTION POLICY: c:\Temp\_Sfx922\Product.msi is not digitally signed
MSI © (34:94): SOFTWARE RESTRICTION POLICY: c:\Temp\_Sfx922\Product.msi is permitted to run at the 'unrestricted' authorization level.
MSI © (34:94): Cloaking enabled.
MSI © (34:94): End dialog not enabled
MSI © (34:94): Original package ==> c:\Temp\_Sfx922\Product.msi
MSI © (34:94): Package we're running from ==> c:\Temp\166a5.msi
MSI © (34:94): APPCOMPAT: looking for appcompat database entry with ProductCode '{BC29B6AE-248C-40F7-BD5C-C2BE167DBC33}'.
MSI © (34:94): APPCOMPAT: no matching ProductCode found in database.
MSI © (34:94): APPCOMPAT: looking for appcompat database entry with ProductCode '{BC29B6AE-248C-40F7-BD5C-C2BE167DBC33}'.
MSI © (34:94): APPCOMPAT: no matching ProductCode found in database.
MSI © (34:94): Transforms are not secure.
MSI © (34:94): Command Line: REINSTALL=ALL REINSTALLMODE=vomus CURRENTDIRECTORY=C:\WINDOWS\System32 CLIENTUILEVEL=0 CLIENTPROCESSID=308
MSI © (34:94): Product Code passed to Engine.Initialize: '{BC29B6AE-248C-40F7-BD5C-C2BE167DBC33}'
MSI © (34:94): Product Code from property table before transforms: '{BC29B6AE-248C-40F7-BD5C-C2BE167DBC33}'
MSI © (34:94): Product Code from property table after transforms: '{BC29B6AE-248C-40F7-BD5C-C2BE167DBC33}'
MSI © (34:94): Product registered: entering maintenance mode
MSI © (34:94): Entering CMsiConfigurationManager::SetLastUsedSource.
MSI © (34:94): Specifed source is not already in a list.
MSI © (34:94): User policy value 'SearchOrder' is 'nmu'
MSI © (34:94): Machine policy value 'DisableBrowse' is 0
MSI © (34:94): Machine policy value 'AllowLockdownBrowse' is 1
MSI © (34:94): Adding new sources is allowed.
MSI © (34:94): Package name retrieved from configuration data: 'Product.msi'
MSI © (34:94): Determined that existing product (either this product or the product being upgraded with a patch) is installed per-machine.
MSI © (34:94): Note: 1: 2262 2: AdminProperties 3: -2147287038
MSI © (34:94): Machine policy value 'DisableMsi' is 0
MSI © (34:94): Machine policy value 'AlwaysInstallElevated' is 1
MSI © (34:94): User policy value 'AlwaysInstallElevated' is 1
MSI © (34:94): Product {BC29B6AE-248C-40F7-BD5C-C2BE167DBC33} is admin assigned: LocalSystem owns the publish key.
MSI © (34:94): Product {BC29B6AE-248C-40F7-BD5C-C2BE167DBC33} is managed.
MSI © (34:94): Running product '{BC29B6AE-248C-40F7-BD5C-C2BE167DBC33}' with elevated privileges: Product is assigned.

[Scotsmanscott]

I notice that the "AlwaysInstallElevated" is set for the user and the machine, which means that the policy is in force... Can I conclude that the users of the software are not members of the local Administrators group?

If so, try logging on as a local administrator... does the MSI still self-repair repeatedly?

If this works, I'll explain what I think is happening later.

[Scotsmanscott]

Also, does the MSI self-repair repeatedly during the same session (launching the application several times without logging off)?

[reflex]

Could you explain what is going on in any case?

Due to the time differences the client is getting rather antsy and we would rather have some kind of explanation the next time we talk to them.

At least I will have the course of the day to have a look at other possible scenarios.

The support guys I am working with havent made any indication that it carries on doing the self-repair.

[Scotsmanscott]

Since you haven't answered my questions, I can't tell you whether this is your problem or not. But, here's what may be happening...

The installer uses different security contexts depending on the actions it's performing, the privileges of the user, policies in force, etc.

When an MSI advertisement is invoked by the shell (when you use an advertised shortcut for example), the installer will check the keypaths for all components within the feature that is to be used. For "per machine" managed applications (installed by an administrator), the installer normally does this under the "system" security context.

When an MSI has been installed "per machine" by a non-admin user under the "AlwaysInstallElevated" policy, the runtime component checking appears to occur under the user's security context. Because of this, resources that are actually installed may not be seen because the user doesn't even have "read" NTFS permissions t that resource (eg: a file in another user's profile - hence the requirement to always use registry keypath's for user components). Because the resource is deemed "missing", the component is deemed broken, and the feature is repaired.

You should however find "application" event log entries (EVENT ID 1004) stating that the resource is missing.

A local administrator will not normally experience the problem because he most likely has at least "Read" NTFS permissions to the resource acting as keypath for the component.

Personally, I think this is a bug.