What trigger self-repair a COM object

  • Thread starter Thread starter Erwin
  • Start date Start date
E

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.
 
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
 
Back
Top