cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
RayKode
Level 6

Auto repair occuring without missing files

IS 2009 Professional.
Basic MSI.
I'm confused.
REALLY confused.

I have auto repairs occurring after my product has been installed but no files are missing. (THAT would be way to easy to solve.)

I have enabled logging on my test pc.
And it seems that sometime during the running of the application, an auto repair will be triggered.
When I examine the Application log there are two messages.
Event ID: 1001.
Which says "Detection of product {.....}, feature "Name of feature" failed during request for component {....}.

The second message is Event ID: 11728.
Product: .... - Configuration completed successfully.

The installer log doesn’t show that any files were re-installed.
Only that the RegisterClassInfo is being executed as well as RegisterProgIdInfo for all of the objects that are part of the feature referenced in Event ID: 1001 (above.)

This never occurs when the product is first started.
So, I'm thinking that indeed no key paths are missing.
(We don't use registry entries as key paths.)

I have been able to copy the application folder structure so that I could indeed validate that the file itself was there (and not changed).

Additionally, it appears as of the Darwin descriptors have not changed either.

I say this because I exported the HKCR\CLSIR key before the auto repair took place and compared it what the same key looked like after the repair was completed.

I'm so very confused.

I'm wondering if this is an error of some sort, in the way I am authoring my installation.
Any ideas or suggestions would be greatly appreciated.
Labels (1)
0 Kudos
(5) Replies
joshstechnij
Level 10 Flexeran
Level 10 Flexeran

If this auto repair event log entry does not have a corresponding entry indicating which resource is missing, then this is actually an "install on demand" event and not an auto repair event. The difference is install on demand occurs when an advertised entry point on a machine is triggered and the feature containing the entry point has a state of advertised (and not local). Windows Installer then installs the whole feature because it believes that it was not already on the machine.

Before the install on demand runs, you could use the MsiSleuth utility that ships with IS 2009 to view the feature states of your package.
0 Kudos
RayKode
Level 6

Hey Josh,
Thanks for the reply.

I truly appreciate your thoughts on my problem.


Ya know .....


I have a Windows Installer log from when the (I'll call it) auto repair takes place.

If I look at the lines following the Action start 14:07:15: InstallValidate task, I see all of my Features listed, followed by all of my components.

They all say the same thing.

Installed: Local Request: Null Action: Null

Doesn’t that kinda sorta means that Windows Installer thinks that everything (all my Features and Components) are already installed and "Action: Null" means that Windows Installer thinks that it dosen;t need to do anything ?

I'm not sure.

AND, just to add a little more confusion, I don't advertise anything.
(Much to the chagrin of our users.)

Thanks again Josh.

Your continued responses will be much appreciated.
0 Kudos
joshstechnij
Level 10 Flexeran
Level 10 Flexeran

Can you attach the full log?

Also, regarding advertisement, it is possible for a feature to be advertised without installing it as such. The most common cause is installing a minor upgrade which breaks feature/component rules, which causes MSI to advertise the feature. One other cause I ran across in the past was using MSI component APIs to programmatically enable/disable components during installation (this again caused MSI to advertise the containing feature because the components that were disabled were not registered properly).
0 Kudos
RayKode
Level 6

Hello again Josh,

I can't thank you enough for your time with this.

I have attached the full verbose log that was created while the (auto repair) was taking place.

That's an interesting comment about the minor upgrade and advertising.
I never would have thought that.

The things you know.

Thanks again.
0 Kudos
joshstechnij
Level 10 Flexeran
Level 10 Flexeran

This does seem to be an install on demand operation as the ADDDEFAULT property is being passed to MSI (this isn't typically listed for auto repair if I remember correctly):
MSI (s) (CC:94) [14:07:10:421]: Command Line: ADDDEFAULT=Common CURRENTDIRECTORY=C:\Program Files\Thomson Financial\Thomson ONE CLIENTUILEVEL=2 CLIENTPROCESSID=2300


The install state of Common from InstallValidate does seem to be local, so I'm not sure why this occurring. Were you able to check the state of the features in this package with MsiSleuth before the install operation is triggered?
0 Kudos