Shorcuts are self repaired even if a shortcut is launched. The application has four shortcuts. Upon launching the 1st shortcut, it repairs. After doing so, when the 2nd shortcut was launched, it also repairs. Is there anyone of you has an idea on how to solve the issue? Thanks in advance.

FYI: vendor MSI

Regards,
Wilson
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
Each triggered repair will be logged in the Event Viewer so open EV, check which component is being repaired (the EV will show the component GUID) and take it from there.
Answered 01/08/2009 by: VBScab
Red Belt

Please log in to comment
0
I already have the component GUID taken from event viewer. What will be the next move?
Answered 01/08/2009 by: wilson
Senior Yellow Belt

Please log in to comment
0
Check whether the component has the keypath set correctly. If not set it.
Answered 01/08/2009 by: SHRIRAMVEN
Senior Yellow Belt

Please log in to comment
0
Sir SHRIRAMVEN, keypath was already set correctly to the component.
Answered 01/08/2009 by: wilson
Senior Yellow Belt

Please log in to comment
0
The obvious thing to do is check WHY it self repairs in the first place, use logging to find out and eventvwr will tell you the component causing the selfrepair.

P
Answered 01/08/2009 by: Inabus
Second Degree Green Belt

Please log in to comment
0
What will be the next move?You need to trace the GUID back to the component itself and then determine why it's being repaired. Did you validate the MSI? Might there by chance be user-level objects (files in the user profile or HKEY_CURRENT_USER registry entries) mixed with machine-level ones?

Are all the shortcuts allocated to one feature?
Answered 01/08/2009 by: VBScab
Red Belt

Please log in to comment
0
ORIGINAL: VBScab

What will be the next move?You need to trace the GUID back to the component itself and then determine why it's being repaired. Did you validate the MSI? Might there by chance be user-level objects (files in the user profile or HKEY_CURRENT_USER registry entries) mixed with machine-level ones?

Are all the shortcuts allocated to one feature?


Yes. I have validated the MSI and there were no ICE57 error (entries in per user registry mixed with per machine).

All shortcuts are allocated in different subfeature.
Answered 01/08/2009 by: wilson
Senior Yellow Belt

Please log in to comment
0
OK, well, that leaves tracing which component is triggering the repair.

It seems odd that all the s/c are triggering a repair...
Answered 01/08/2009 by: VBScab
Red Belt

Please log in to comment
0
ORIGINAL: VBScab

OK, well, that leaves tracing which component is triggering the repair.

It seems odd that all the s/c are triggering a repair...



Not all shortcus are triggering a repair. Only two of the shortcuts are triggering a repair, the other two shortcuts are not.
FYI: The two shortcuts that triggering a repair are executable.
Answered 01/08/2009 by: wilson
Senior Yellow Belt

Please log in to comment
0
Could it be due to any temporary file?
The executable is removing files/registry during launch?
Permission problem to repairing a resource?

Giving us more details would help us help you
Answered 01/08/2009 by: AngelD
Red Belt

Please log in to comment
0
Hi Wilson,

through prism or picture taker cature the changes done by source as well by your msi and compare.
For e.g Run the picture taker take the intial snapshot and in the second snapshot run your source save the .pwc file.
now repeat the above process and instead of running exe run your msi.
Some resources must be missing due to which it self repairs.
Answered 01/12/2009 by: shweta_kar
Blue Belt

Please log in to comment
0
Not all shortcus are triggering a repair.

In response, I'd say againOK, well, that leaves tracing which component is triggering the repair.
Answered 01/13/2009 by: VBScab
Red Belt

Please log in to comment
0
Some resources must be missing due to which it self repairs.Not quite right. The resource may well be present but an indicator to its key path status may be broken/missing, which a new install of the source (if this is a captured MSI) wouldn't correct.

Wilson, you need to check the Event Viewer to get the ID of the component which is being repaired, trace that back in the MSI to the actual component and then work from there.
Answered 01/13/2009 by: VBScab
Red Belt

Please log in to comment
Answer this question or Comment on this question for clarity