What trigger self-repair a COM object

[Erwin]

Hi,

I have a very weird problem. I have an install with that registers
some COM objects. These COM objects are advertised, I knew it as I
found InProcServer32 for that DLL's CLSID.

If I logged in as different user (a restricted user), the DLL is still
accessible, the DLL does exist, but every time I run the application,
it tries to self-repair.

The Event Viewer has these two logs:
Detection of product 'GUID_1', feature 'Common' failed during request
for component 'GUID_2'

Detection of product 'GUID_1', feature 'Common', component 'GUID_33'
failed. The resource 'C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\' does not
exist.

I create a simple application that calls MsiGetComponentPath, both
returns the correct location of the file, both for the admin user and
the restricted user.

When I run MsiProvideComponent, for the admin user it runs just fine,
but when the restricted user tries to run it, it tries to reinstall.

Last, I assigned the restricted user a read only access to
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\, the call to MsiProvideComponent
does not trigger the self-repair dialog. The application also runs.

What's going on here? Can someone help me, or point me to the right
direction?

Thank you!
Erwin.

 

[rweerasi]

Hi Erwin,


What you are seeing here is a quirk of Windows Installer.

Basically, the checks for the component are done within user context
In this case, the component is in a different users profile that th
standard user cannot see.

However the repair uses elevated privileges (via system context) t
access the file


-
rweeras