Software Deployment

What does the Windows Installer-logfile say?
You can also check the EventViewer for extra details.

I looked at one computer with this issue and it seems like an ordinary self repair. It can´t find a HKCU key that I have never seen before from a program I know nothing about. The program that triggers this is a completely different program with no keys under that path.

You can diagnose self-repairs by deep diving into the logs.

Have you checked it already?

Where can I find these logs?

David,

if the conflicting file in question (let's say it's a DLL) happens to also provide an advertised entry point for the packages (i.e if it was registered by the MSI and there's a Darwin Descriptor with the registry entries), then any action that "calls on" this file will actually initiate a self-heal cycle. At that point if a new application has actually changed the component's registration data for that file, for example by installing the same file with a component that has a different GUID, a repair WILL be triggered.

There are more types of triggers for a self-heal than missing HKCU keys. There are a number of tables in an MSI besides the Shortcuts table that can create an entry point, off the top of my head, the Class, ProgID and MIME table are amongst these, but that list might not be complete. Then what triggers the install just depends on what the key paths for the components are.

As you probably know, this is actually the crux of the Conflict Management principles when building MSIs, making sure that if 2 or more packages install the same resources on a machine, they do it with components that are, to the highest extent possible, identical amongst packages (same contents and GUIDs). Same with why using Merge Modules can avoid these kinds of problems.

Rgds,

PJ

First set registrykey below to enable Windows Installer Logging in general:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
Reg_SZ: Logging
Waarde: voicewarmupx

After this is done, reproduce the error and locate the logfile in %temp%. Logfile is in format MSIxxxxx.LOG. The x's are random generated.

You can also check the EventViewer for MSI Installer logs. If a repair is triggered, 2 entries are logged. In the logs you can find the exact component in the msi of the conflicting application that is producing the error.

Ok thanks all I´ll check these things out! Then it´s "just" a matter of figuring out how to avoid these things.

a matter of figuring out how to avoid these thingsAs Pieter mentioned, this is what Conflict Management is about.

the application event log should show the offending component name / product code in the event log.

The component code is of more use to you as the keypaths associated to the component act as the trigger for the self repair. You can find the component code list in here

HKEY_CLASSES_ROOT\Installer\Components
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components

If the component has two products listed it is probably your issue. You may also wants to check the value of each product has the same keypath value. If it doesn't this is likely to be your issue.

You will also need to reverse order of the guid this is well documented all over the place, i blogged about it somewhere once.

Yes I saw the component GUIDS, thanks I´ll check it out and hopefully find a way to avoid these things in the future somehow!