This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Auto repair occuring without missing files
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 24, 2009
03:15 PM
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.
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.
(5) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 24, 2009
04:19 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 25, 2009
12:47 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 25, 2009
12:52 PM
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).
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).
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 26, 2009
07:52 AM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 30, 2009
09:14 PM
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):
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?
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?