cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
MimerBg
Level 3

Major upgrade leaves old shortcut in add/remove on 64-bit Windows 8

I am using an Installscript MSI project. I have a major upgrade that I have tested with several versions and configurations. It works fine on all tested platforms except on 64-bit Windows 8. On Windows 8 only parts of the major upgrade is performed. I.e. all files are removed from the old installation directory, registry etc and all the new files etc. are installed properly.

What remains from the old installation is the following registry key with associated entries:
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Installshield_{guid}
and the files under:
c:\Program Files (x86)\Installshield Installation Information\{guid}

Everything else is properly removed including c:\WIndows\Installer\{guid} folder. The remaining registry entry causes the old version to show up under Add/remove programs. Using this shortcut invokes the Installshield wizard which runs for a few seconds and then gives error 1628, Failed to complete installation.

Has anyone else had this behavior or have any idea what is causing it? Any help greatly appreciated!

Regards
Bengt

PS. I have checked all the usual problems with major upgrades, such as: Same upgrade guid, new product guid, new package guid and version numbers within range. I have tried different versions of Windows installer, but I get the same behavior. I have checked the msi log file and it properly detects the old installation. I cannot see anything obvious that I can connect with my problems...
Labels (1)
0 Kudos
3 Replies
MimerBg
Level 3

We have done lots of further testing and have the following pattern:

The problem occurs on any platform (not only on Windows 😎 when the installation is compressed (web/diskimages/disk1), i.e. we use a single executable for the installation. If we use an uncompressed installation (with CD/diskimages/disk1) everything works fine.

If the old installation is compressed or not does not matter it is only the new that affects if the problem occurs or not.
0 Kudos
MimerBg
Level 3

I compared the output from MSI logging in a successful and an erroneous run. There were only two lines (of several thousand) that differed:

MSI (s) (FC:34) [16:43:18:723]: Note: 1: 2262 2: DigitalSignature 3: -2147287038
MSI (s) (FC:34) [16:43:18:736]: PROPERTY CHANGE: Modifying SETUPEXENAME property. Its current value is 'setup.exe'. Its new value: 'TEST64.exe'.

The first one is interesting: 2262 means: "Stream does not exist: [2]. System error: [3]" and -2147287038: "%1 could not be found".

I had only signed the web executable and not the contents of compressed installation (embedded .msi file). I changed this in the Installshield settings for signing and the problem was resolved:). Tricky - hard to guess that not signing the .msi file would have this effect...
0 Kudos
MimerBg
Level 3

I hate to come back on this... When we rebuilt everything again we had the same problem back:(

I turns out that when we build a compressed web distribution and the executable is called setup.exe it works. However, if we call it anything else the major upgrade leaves the old installation corrupt. It does not matter if we rename setup.exe afterwards or we set the final name inside Installshield - same behavior (setup.ini has correct LauncherName key in this case).

We have a naming scheme for downloaded files, and even if we skipped this and called it setup.exe, web browsers will rename the file if there is already an existing setup.exe in the download directory.

If we use msi-logging a correct installation produces 4 logfiles and the error case gives 3 log-files and an IS_xxxx.tmp file. The .tmp file is empty. The other three are the same (except for timestamps).

Has anyone seen this bug and been able to work around it? Any help would be greatly appreciated - we have been trying workarounds for days now...
0 Kudos