Puzzling Repair Behavior...
Posted 16 February 2012 - 21:50
We had a user at a pilot site attempt to utilize our installation, but the had redirected their My Documents to a UNC path and received a 1324 error. I believe I posted here about that a week or so ago. We worked around that by removing the involved component and we now let the application handle involved setting in this area at startup.
I believe I'm dealing with dirty machines now, but let me tell you what seems to be happening now.
When a non installing user, User2, logs in, they still receive the 1324 error during the repair install to place other user specific settings. My first thought was that the cached installation was bad. We re-cached the installation with REINSTALLMODE=vomus REINSTALL=ALL. That didn't make any difference so we initiated our application with another user, User3, and it seems to have gotten past that problem. So one question is what is going on with User2?
For User3, now a repair is repeatedly initiated when he/she logs in and the component that is 'broken' contains our Main executable. I'm not sure why this is occurring either. This potential customer is concerned about security so I don't know if they have any policies in place that would cause this behavior, but like I said, the machines are dirty as well.
I have not gotten a chance to look at logs of the repairs (hopefully they have logging enabled) as Support has been the first line of defense to this point, but plan to do so ASAP. I was just wondering it security restraints could possibly cause repairs for some reason.
I would also like to get a clean machine in place a the users site to test our lates install on a fresh slate.
I know this probably doesn't give anybody anything substantial to go on. Sorry and I hope to provide details soon.
Posted 17 February 2012 - 18:09
Posted 19 February 2012 - 04:26
Posted 20 February 2012 - 14:51
The puzzling thing about his is that we haven't been experiencing problems with this custom action anywhere else when non-installing users launch our product and initiate a repair install (when other user specific date is written).
I know I could condition with $ComponentName=3, but I believe the widgets that run detect and set up registry information needed for or by third party products we team with.
I hope to find out more today in working directly on a clean customer machine, but I'm stumped at the moment.
Posted 20 February 2012 - 18:13
Posted 22 February 2012 - 20:41
We are still erperiencing the 1324 error as something in the users environment appears to be interferring with Windows Installer. I've attached a log that I was able to grab from the users system today.
Any help, thoghts, etc appreciated!!
Thanks in advance!!!
Posted 22 February 2012 - 21:21
When the user launches our shortcut, they get the 1324 then a fatal error and the process stops.
I’ve attached two other logs (along with the original) from manually built, direct shortcuts, one set as Run As Administrator. Both basically received a quick repair, haulted by the 1324 error, but after clicking OK on the error, it appears the repair finished as the app launches and all seems functional.
I don’t know if this will shed any further light on this situation or not, but I thought I should send them along just in case. I’m just wondering why my Advertised shortcut launched repair simply dies.
Thanks again for any efforts.
Posted 23 February 2012 - 10:45
I don't know why you see different results from the diferent shortcuts, since all three logs exit with error 1324 during CostFinalize, so no changes to the target system should be made at that point.
Posted 24 February 2012 - 15:57
The problem seems to have been resolved with our latest software installation. The customer was piloting with a previous version. When they needed a fix for the initial 1324 error, I had modified the .msi through InstallShield to remove the problematic component. I did not do a full rebuild.
This is about the only thing I can think of to explain the problem. I tried to shortcut the process of building in a time crunch which turned out to be a no-no.
To work through what appeared to be a problem, some suggested that I should create a separate Feature to contain all of my user specific information with a sub feature to contain an advertised entry point.
Currently our install has one Component with a mix of Machine and User items. There is an advertised shortcut to our main .exe. We had to go this route because the app would launch and a repair would be initiated, but the app had already searched for and failed to find information that would be written during the repair. By using the Advertised shortcut, the repair writes the information then the app launches - and we're all good.
I'm just wondering at this point if it would work to add and extra User data Feature with no advertised entry point (because I don't know what that would be). Would is still function the same or better to keep the advertised entry point the main .exe in the current, Core feature?
With the separate user info/component(s) Feature, I'm also thinking that this will still go against what I've read most... Machine and User items should be kept from the same installation processes.
Our users would like to see us move away from Repairs and the only way I know of to do that is to make it a per machine install with no user data. The application would/should handle all user items at runtime. This would fall in line with most recommendations I've read with regard to mixing machine/user information.
Thoughts, pitfalls, recommendations????
As Always, THANKS!!!!
Edited by Superfreak3, 24 February 2012 - 16:03.
Posted 29 February 2012 - 18:01