Sorry to open up another thread on major upgrade problems but I didn't find anything similar for InstallShield 2009 (SP2), InstallScript MSI yet here. And I'm facing this problem just newly, after conversion of my IShield 11.0 projects; all the years before I never had complaints about my authored major upgrades...
The issue I'm seeing is, on performing a major upgrade, during RemoveExistingProducts action, the running setup.exe just hangs up or results in a 1603 FeatureTransferError runtime message (though nothing changed with regard to features/components at all). If the hang appears, the verbose log states "Logging stopped", a 2nd setup.exe is spawning from within %TEMP% folder which apparently shall perform the uninstallation of the package being upgraded, and nothing happens afterwards. If I kill the 2nd setup.exe process in task manager, the 1st setup and its log continue with installing the new package; well, for a few milliseconds, I guess it's no wonder that this results in not very helpful error code 1708 (log) followed by 1603 (GUI).
This happens for both 32-bit/64-bit packages on both Vista and XP, but only if the previous package was built with IShield 2009! Upgrading old IShield 11 packages works perfect, as well as first time installations of course. Tomorrow back at work I'll see to get a full log attached here, though I didn't see anything suspicious so far...detection, elevation, everything looks correct. PackageCode, ProductCode and ProductVersion were changed of course. Postponing uninstallation after installation doesn't seem to matter, feature migration flag neither, ... I'm running out of ideas.
Anybody out there having hints what else I could check ... or even why this suddenly is a problem what worked fine for years?
Okay, here are the verbose MSI logs. Meanwhile I figured out the presumable culprits, 2 MSIHANDLE leaks:
InstallShield 15:05:53: Ready to initialize ForceRemove, Product code is {73934AAA-B577-4553-BF8A-F246FBB33C4F} MSI (c) (2C:08) [15:05:53:404]: Leaked MSIHANDLE (2) of type 790541 for thread 4872 MSI (c) (2C:08) [15:05:53:404]: Leaked MSIHANDLE (1) of type 790537 for thread 4872
Those finish the _mc_setup_loggin2 which is the one created by the package scheduled for upgrade; looks like this action fails, corrupts memory and leads to unpredictable behaviour afterwards. Btw, this is from the "error 1603" scenario; when the deadlock happens, this 2nd log isn't even created.
Coming back to this issue I found the reason, mainly a homemade problem, but before someone steps into the same trap the "InstallShield Best Practice Suite" sets:
It warned about custom action "ISVerifyScriptingRuntimes is scheduled in the InstallUISequence but not the InstallExecuteSequence" (ISBP06).
Though knowing that it's a very special CA solely related to InstallShield rather than Windows Installer I decided to get rid of it and added it to the Execute Installation Sequence. Bad idea, it caused this problem!
The warning is about this CA not being present but it must not be executed at this point. I fixed it now by setting an exec condition of (an unspecified non-public MSI property) Never_Ever_Set_This_Property_Because_It_Corrupts_Major_Upgrades.
