Self-Repair: Exactly WHEN does it occur?

[Lon Wergin]

I know that the self-repair feature ("resiliency") of
Windows Installer can be triggered in the following
scenarios:

1.) When a COM client attempts to CoCreateInstance on a
COM object whose CLSID is registered by a COM Windows
Installer Component. Apparently, CoCreateInstance first
looks for the additional registry value that Windows
Installer adds to the Class registration. If it exists,
Windows Installer will validate that the COM object is
registered properly and references the expected COM server
file. If it fails this validation, then the self-repair
occurs. After that operation, the CoCreateInstance
function goes back to the business of CoCreating.

2.) A COM server Windows Installer component is installed
because 1 or more Features are being installed but the
Feature listed in the "Feature_" column of the Class and
TypeLib tables is not installed. (I believe that the
component ends up registering as "advertised"--or
something like that--rather than "run-locally".)

3.) An advertised shortcut that references a not-yet-
installed file is activated.

4.) Explicit calls to Windows Installer API functions to
ensure that a component (and/or a feature or product?) is
properly installed.

QUESTION 1: We have a Windows Installer component that
registers a COM server .DLL (using the Class, ProgID, and
TypeLib tables) installs and registers just fine. A
client application can make the same set of requests of
that COM server over and over again without problem, and
then suddenly the self-repair kicks in because of that
component because Windows Installer believes the component
to be "broken". Given that we are not deleting, renaming,
modifying the file nor its COM registration, how could
this happen?

QUESTION 2: If we install a plain-jane non-COM
resource .DLL, should self-repair ever occur on that file
if we manually delete it and it is not a target of an
advertised shortcut and we never make explicit Windows
Installer API calls to validate it?

Any insights would be appreciated.

Lon

[Phil Wilson]

1) Repair happens when Windows uses MSI descriptors to get to something, so 3)
is not really just advertising, it's whenever an advertised shortcut is used
(whether it causes installation of the advertised feature or not).

I think MSI descriptors are in advertised shortcuts, COM registration entries,
file extension linkages.

Is it possible that the COM server is being used by multiple accounts? Keep in
mind that repair/cacheing is related to user accounts, and the COM server may be
in use by something with a user account and something else with a local system
account (a Service), or another user account. Note that looking at the registry
stuff to see what's really there needs to be done carefully because when you run
regedit, your view of HKCR is not the same as some other user (especially the
local system account).You did install per-system?

2) Probably not, wish I could more explicit. The MS folks might jump in.

--
Phil Wilson [MVP Windows Installer]
----
"Lon Wergin" <qwe...@spammenot.com> wrote in message
news:05ba01c39fc1$e56f0a70$a001...@phx.gbl...

[Lon Wergin]

Thanks Phil,

FYI: The install in question is always installed per-
machine.

Lon Wergin

>.
>

[Anil Abraham]

Whenever a feature which is installed by the MSI which
actually contains components which in turn has a key path
is found to have some problem the MSI repairs.
This is checked whevenver you invoke the feature through
an advertised component.Be it a shortcut or a file
extension.
If you go to eventviewer it would tell you exactly which
component causes the problem.
If this is caused due to an advertised com component
either remove the advertising for the component or see
what is wrong with the component which causes the repair
to happen which can be identified from the event viewer.

>.
>