difference between ARP and re-running setup.exe

[Kelter]

This is baffling. Here goes:

BasicMSI project
All features are set to "disallow advertise."

Scenarios:
I install my product, and restart.

----
-I then re-run Setup.exe (with cmdline parameters for logging) to enter maintenance mode.
-I opt for "Modify." The custom setup selection tree is properly initialized.
-I alter the install state for several features, [Next] [Next] [Finish]
the proper modifications are made to the system.
-I re-run Setup.exe again.
-Again, the customSetup selection tree is initialized with the proper feature states.
----
-I open "Programs and Features".
-I select my product, and click "Change" to enter maintenance mode.
-I opt for "Modify." The custom setup selection tree has all feature states set to "Advertise!!!!!!"

For debugging purposes, i tried running the "modifypath" from the registry, but with /lv "filepath" appended for logging and observe the same behavior. I took logs of two identical sessions invoked differently, (ran a few regular expression find/replace iterations to filter out timestamps, etc) and 'diff'ed them.

The order of actions was the same between the two sessions. The first difference that appears to matter is that within the MaintenanceWelcome action the line
MSI: PROPERTY CHANGE: Adding MsiSelectionTreeSelectedAction property. Its value is '1'.
has a '3' in the log of the session wit hthe proper behavior.

If i understand the meaning of that line, however, it's evidence of the symptom, and not the source of the problem.

Does anybody have any kind of hint as to what would cause this discrepency in invocation methods?

[Christopher_Pai]

Can you paste the entire MaintenanceWelcome log section?

[Stefan_Krueger]

And maybe even upload the complete log of the failing install?

[Kelter]

Here's that section:

[CODE]
MSI (c) (2C:90) [09:55:05:442]: Doing action: MaintenanceWelcome
Action start 9:55:05: MaintenanceWelcome.
MSI (c) (2C:94) [09:55:05:458]: PROPERTY CHANGE: Modifying CostingComplete property. Its current value is '0'. Its new value: '1'.
MSI (c) (2C:94) [09:55:05:458]: Note: 1: 2205 2: 3: BindImage
MSI (c) (2C:94) [09:55:05:458]: Note: 1: 2205 2: 3: PublishComponent
MSI (c) (2C:94) [09:55:05:458]: Note: 1: 2205 2: 3: SelfReg
MSI (c) (2C:94) [09:55:05:458]: Note: 1: 2262 2: Extension 3: -2147287038
MSI (c) (2C:94) [09:55:05:458]: Note: 1: 2205 2: 3: Font
MSI (c) (2C:94) [09:55:05:473]: Note: 1: 2727 2:
Info 2898.For MSSansBold8 textstyle, the system created a 'Tahoma' font, in 0 character set.
Info 2898.For MSSWhiteSerif8 textstyle, the system created a 'Tahoma' font, in 0 character set.
MSI (c) (2C:24) [09:55:08:531]: PROPERTY CHANGE: Adding _IsMaintenance property. Its value is 'Change'.
MSI (c) (2C:24) [09:55:09:748]: PROPERTY CHANGE: Modifying ProgressType0 property. Its current value is 'install'. Its new value: 'Modify'.
MSI (c) (2C:24) [09:55:09:748]: PROPERTY CHANGE: Modifying ProgressType1 property. Its current value is 'Installing'. Its new value: 'Modifying'.
MSI (c) (2C:24) [09:55:09:748]: PROPERTY CHANGE: Modifying ProgressType2 property. Its current value is 'installed'. Its new value: 'modified'.
MSI (c) (2C:24) [09:55:09:748]: PROPERTY CHANGE: Modifying ProgressType3 property. Its current value is 'installs'. Its new value: 'modifies'.
MSI (c) (2C:24) [09:55:09:748]: PROPERTY CHANGE: Adding MsiSelectionTreeSelectedFeature property. Its value is 'DocSDK'.
MSI (c) (2C:24) [09:55:09:748]: PROPERTY CHANGE: Adding MsiSelectionTreeSelectedAction property. Its value is '1'.
MSI (c) (2C:24) [09:55:09:748]: PROPERTY CHANGE: Adding MsiSelectionTreeSelectedCost property. Its value is '0'.
MSI (c) (2C:24) [09:55:10:247]: Note: 1: 2727 2:
MSI (c) (2C:24) [09:55:10:762]: Note: 1: 2727 2:
MSI (c) (2C:24) [09:55:11:261]: Note: 1: 2727 2:
MSI (c) (2C:24) [09:55:11:776]: Note: 1: 2727 2:
MSI (c) (2C:24) [09:55:12:540]: Doing action: ISSetupFilesCleanup
Action start 9:55:12: ISSetupFilesCleanup.
MSI (c) (2C:C4) [09:55:12:540]: Invoking remote custom action. DLL: C:\Users\mkelter\AppData\Local\Temp\MSI6147.tmp, Entrypoint: SFCleanupEx
Action ended 9:55:12: ISSetupFilesCleanup. Return value 1.
Action ended 9:55:12: MaintenanceWelcome. Return value 2.[/CODE]

And also the two full logs as attachments (with company and product names changed to protect the innocent.) Let me know what you make of it...i'm befuddled.

Just to clarify the dialog sequence,

MaintenanceWelcome
MaintenanceType
CustomSetup

logCM.txt is the log when invoked from "Programs and Features". "install.txt" is the log from re-running the .exe.

[Kelter]

Perhaps a more specific question might get us where we're going:

If, during an upgrade, the Install States of the package's features are updated on MigrateFeatureStates, then what action sets feature states during a "Modify" operation? My best guess would be CostFinalize, but this runs before the dialog sequence in both cases...

Darned thing worked just great when re-running the setup launcher...

[Kelter]

I noticed one difference between the logs that might be significant: When run from "Programs and Features," the installer deletes the ALLUSERS property after the SetupInitialization action. I think this might be causeing the problem, because the setup may be looking for feature installstate information in the Per-User location instead of the Per-Machine location.

I tried adding ALLUSERS to the SecureCustomProperties property, but this didn't change the behavior.

I then tried adding an action after SetupInitialization to reset ALLUSERS to 1. The log shows ALLUSERS being deleted, then reset by my CA, then deleted again later on.

Next, I removed the entry from SecureCustomProperties, and had the same result.

I then tried resetting ALLUSERS just prior to SetupInitialization, still no dice.

This problem doesn't manifest itself in XP. ALLUSERS doesn't get automatically cleared, and the install states are reflected accurately in CustomSetup.

Why does ALLUSERS get deleted? Why does it only get deleted when the installation is run from "Programs and Features?" Am I on the right track as far as this being a possible cause for the CustomSetup behavior discrepency?

More importantly, how do i get "ALLUSERS" to persist!?

[Kelter]

Okay, so i finally found this thread

http://community.installshield.com/showthread.php?t=172412

and used the silly owrkaround suggested there. Namely, i created several CAs which set the ALLUSERS property after every action that resets it.

This is pretty rediculous, I must say, expecially since there's no real explanation for this behavior in the first place...i don't see a circumstance where it would be desireable without some much better determinism in the background.

[Kelter]

Okay, so resetting the ALLUSERS property didn't work. I used the hotfix suggested in the thread mentioned in my previous post, and that didn't work either. ALLUSERS no longer gets reset, however, the CustomSetup mis-behavior persists.

The problem does not exist on XP. It oonly mis-behaves on Vista, and only when doing a "modify" from "Programs and Features." This sounds like an IS bug unless someone has another suggestion.

Please, if one of you whicked smaht guys can help out here, I'd be psyched, andi woudln't have to call in a support issue.

Thanks in advance.

[#9]

I'm not sure which silly workaround 🙂 you tried, but there's a hotfix for it now:
http://support.installshield.com/kb/view.asp?articleid=Q113652

I think that should resolve your issue.

[Kelter]

I tried that hotfix...

I used the hotfix suggested in the thread mentioned in my previous post, and that didn't work either. ALLUSERS no longer gets reset, however, the CustomSetup mis-behavior persists.

So the CustomSetup Selection Tree misbehavior is persisting despite the good behavior of the ALLUSERS property...

[#11]

On closer inspection, I'm not familiar with these types of lines:

MSI (c) (64:CC) [09:54:37:674]: Note: 1: 2727 2:
MSI (c) (64:CC) [09:54:38:189]: Note: 1: 2727 2:
MSI (c) (64:CC) [09:54:38:704]: Note: 1: 2727 2:
MSI (c) (64:CC) [09:54:39:219]: Note: 1: 2727 2:
MSI (c) (64:CC) [09:54:39:733]: Note: 1: 2727 2:
MSI (c) (64:CC) [09:54:40:248]: Note: 1: 2727 2:
MSI (c) (64:CC) [09:54:40:763]: Note: 1: 2727 2:
MSI (c) (64:CC) [09:54:41:262]: Note: 1: 2727 2:
MSI (c) (64:CC) [09:54:41:777]: Note: 1: 2727 2:

That error indicates that the Directory table entry is invalid. I'm not sure how you're encountering this.

What exactly are you doing in that dialog?

Do you have screenshot perhaps?

[Kelter]

While logging verbosly, if CustomSetup is open, those lines appear every half second or so...
I verified that this only happens on the CustomSetup, and also that it happens on XP and Vista.


NOTE: This might or might not be related, so take it with a grain of salt...on Vista feature costs are not calculated for the FeatureCost string in the custom setup dialog...i thought i'd mention this here in case it provided a clue to the solution to this problem. That problem is described in more detail here. If this doen't help you with the problem in this thread, then go ahead and ignore this info.

[#13]

Indeed, looking at a test project I see the same lines every 5 - 10 seconds or so.

At any rate, reading through your other post, I'm confused. Why are you using Feature Conditions the way you are? Basically, Feature Conditions are designed to be evaluated only based on a single set of inputs. What you're doing is running the Costing process twice, which likely isn't a huge issue. However, it is a technical abuse of the feature condition process and running the costing process from a dialog may be the cause of the issue you're seeing.

However, from a design perspective, I can't see how this would be desirable. If you're trying to enable/disable features based on a selection, why not utilize the built-in functionality provided in the dialogs rather than by setting the INSTALLLEVEL property?

[Kelter]

Onl by means of the FeatureConditions can I make features appear/disappear from the Custom setup dialog. I do this during the dialog sequence because I need user input to do so. More specifically, the (Serial Number) entered in the Customer Information dialog determines which features the user paid for. There is no built-in feature in the dialogs to accomplish this. The unfortunate thing is the false asumption that evaluation of feature conditions and file costing should be coupled as a single standard action.

Technical abuse? Is that a crime? 😉 Hey, if there's only one way to use any given tool, then it woudln't be much of a tool, would it? How would you differentiate between the definitions of "technical abuse" and "manipulating a tool?" Engineering is all about manipulating tools.

Why should this behave just fine on xp and not on vista?

--
PS: Thanks a whole bunch for helping me look into this.

[Stefan_Krueger]

From the logs it seems like you cancelled the setup, and I don't see information about feature and component states and requests in the log.

[Kelter]

If you think a more complete log would be helpfull, I'll generate some, but as far as the existing log is concerned, the subtle evidence of misbehavior is in this line:

re-running setup:
MSI: PROPERTY CHANGE: Adding MsiSelectionTreeSelectedAction property. Its value is '1'.
This is the correct state. All of the feature states are correctly reflected in this case.

'modify' from "Programs and Features"
MSI: PROPERTY CHANGE: Deleting MsiSelectionTreeSelectedAction property. Its current value is '3'.
Indeed, not only the Selected item, but all of the installed items (features) in the tree were set as "advertised."

I only included that portion of the log, because whatever caused the difference must have occured prior to that point and i didn't want to water down the log...(would that leave it "waterlogged"...nevermind)

I'll generate and filter another log, but in the meantime, what i'd observed from finishing the installation during InstallValidate is a whole bunch of

Installed: Advertised, Request: Null, Action: Null

..which reflects that the install initially detected feature states as "advertised," i made no changes in CustomSetup, and therefore, no actions were taken...

I'll make another post with some more detailed logging and chronology sometime before i go to lunch.

BTW: I find it handy to filter out timestamps/random-generated.msi names, etc for the sake of diffing logs. If any of you find it usefull, say so and i'll include these filtered logs in addition to the raw ones in my next post.


Thanks again...i've found answers to many of my problems in posts from both of you in the past, and obviously from installsite as well. :cool:

[Kelter]

Here's the scenario:

[InstallVista.txt]
The initial installation.
In CustomSetup I set the "Samples" feature to "Not installed." Subfeatures of the MSVSSupport feature were properly initialized to not install.
The Feature States were initialized properly.
(The Feature _costs_ were not initialized, however.)
The installation succeeded and properly setup the system.

[PandFModifyVista.txt]
In Programs and Features, i clicked "Change."
All features were initialized to "Advertised" (BTW, as i'd said before, all my features are set to disallow advertise") except for "Samples" which was set to "Not Installed" (appropriately) and "Tools" which was also initialized to "Not Installed" (not good.)
I finished the install and noticed some funnyness in the log (in particular, the installvalidate section). Here's an example:

The feature Demo (which falls under the 'samples" feature) was listed as "Installed Advertise, Request: Absent, Action Absent." The component Demo.exe which falls under the Feature Demo was listed as "Installed: Absent, Req: Null, Action: Null." This is insteresting becausethat feature and it's components were actually installed, etc. This makes about as much sense as all the other instaled features being listed as advertised.

Upon examinig my system after the fact, no changes were actually made. Even the features marked "Action: absent" were not modified/removed.

[2ndPandFModifyVista.txt]
I did another modify at this point and all the features initialized to "Not Installed".
On install, this error was thrown

MSI (s) (90:70) [08:32:56:894]: Product: 8.1 -- Error 1402.Could not open key: UNKNOWN\Products\7ABB86F5F6A187744A9B0837FBE1E7FE\Patches. System error 1018. Verify that you have sufficient access to that key, or contact your support personnel.

In the xp installs, you can see that i did a full install, then did a modify, and switched a few feature states. Everything behaved perfectly, including the feature costs.

Thanks again!

[Stefan_Krueger]

I see a lot of clearing and setting of the ALLUSERS property in the log. This makes me think it might be a variant of the problem described at http://support.installshield.com/kb/view.asp?articleid=Q113652 "HOTFIX: InstallScript Initialization Code Modifying ALLUSERS Property"
Do you have this hotfix installed?

[Kelter]

Yes. I even verified that ISSetup.dll in all three locations have a Modified date of 10\15\07, and i'd restarted _everything_ before building, and still observed those same results.

Baffling, isn't it?

[Kelter]

The about box says "With licensing hotfix."

...just to confirm.

[#21]

Can you visit the key HKEY_CLASSES_ROOT\Installer\Products\7ABB86F5F6A187744A9B0837FBE1E7FE using regedit on your machine and verify that it does or does not exist.

To be honest, I think this would likely allow us to pin it down. I'm not sure that the XP behavior is truely relevant.

The specific line that's likely causing this issue is
MSI (c) (C0!48) [08:27:10:605]: PROPERTY CHANGE: Deleting ALLUSERS property. Its current value is '1'.
which should not be happening if you've installed that Hotfix.

Could you confirm the version of the 3 instances of the ISSetup.dll file in that Zip file. You should be able to unzip it to C:\Program Files\Macrovision\IS2008 successfully and get it working.