Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Puzzling Repair Behavior...


9 replies to this topic

Superfreak3

Superfreak3
  • Full Members
  • 437 posts

Posted 16 February 2012 - 21:50

This is an involved story, but here goes...

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.




Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 17 February 2012 - 18:09

I'm note sure, but Windows checks to see if all installed files are there. If some security policy prvents Windows from accessing the file it might interpret this as missing or broken file.

Superfreak3

Superfreak3
  • Full Members
  • 437 posts

Posted 19 February 2012 - 04:26

I'm thinking its security related. I hope to gain some insight on Monday when I hopefully can look at some logs.

Superfreak3

Superfreak3
  • Full Members
  • 437 posts

Posted 20 February 2012 - 14:51

I should also note, that when the repair is initiated, I then get a 2753 Error on an .exe installed with the product Custom Action. It is run Asynchronous, Deferred in User context and has conditions of NOT PATCH AND NOT REMOVE="ALL".

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.

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 20 February 2012 - 18:13

Error 3753 means that the file isn't being installed and therefore can't be run as custom action. CVheck the log to see why the file isn't selected - maybe it's in a feature that doesn't need to be "repaired".

Superfreak3

Superfreak3
  • Full Members
  • 437 posts

Posted 22 February 2012 - 20:41

The 2753 error appears to have gone away after supplying the customer with a newer installer. I don't know if that was the answer so much as it was the customer was testing on a clean image.

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!!!

Attached Files



Superfreak3

Superfreak3
  • Full Members
  • 437 posts

Posted 22 February 2012 - 21:21

There’s a little more to the story. The log I sent you was a repair initiated from our installed shortcut which is advertised. It was changed to advertised a while back because the app needed to be repaired first before actually launching because some user specific login date written during the repair was unavailable otherwise, but I digress.

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.

Attached Files



Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 23 February 2012 - 10:45

Does \\MOQZ14.NA.CustomerCompany.CNB\HOME\MIJDT\Personal Data\ exist and does the user have write access?

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.

Superfreak3

Superfreak3
  • Full Members
  • 437 posts

Posted 24 February 2012 - 15:57

Yes, the user had access to the directory specified.

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.


Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 29 February 2012 - 18:01

I would recommend the same thing: let the application take care of the user data. You could still put some template user data in HKLM that the application would copy over to HKCU if they are missing.