Files not extracted - results in upgrade failure

[drivard]

Hi,
My company writes white label software and generates distinct, branded installers for several partners using Advanced Installer version 15.8. We create these for both the development/testing environments and production. We have encountered a problem where the only the production installers for only one specific partner fail to upgrade. The observed behavior is that the old version will be uninstalled, but the new version will not be installed.

Some relevant information about our process:
- we use a template .aip project as a base for generating the separate installers. This template project is duplicated using /duplicate and then customized using a command file
- When installers are generated for non-production environments, the installer name has a prefix indicating the environment (i.e. if the name of the production installer is InstallerName.exe, the installer generated for the QA environment will be QA_InstallerName.exe)

The following error is found in the logs for a failed upgrade:

Code: Select all

Product: [Branded prodcut name] -- Error 1308. Source file not found: [path to file]  Verify that the file exists and that you can access it.

Checking the extract location shows that the files are not being extracted. I found the following forum posts indicating the version number should be used in the extract location:
viewtopic.php?t=33761
viewtopic.php?f=2&t=11474

However, making this change did not change the observed behavior and the upgrade still failed in the same manner.

I have also found this forum post:
viewtopic.php?t=30337#p81105

and tried the recommendation of adding the "ExtractFilesFirst" property with a value of "1". This partially resolved the problem, however while the upgrade completed successfully, the Exit Dialog did not display at the end, nor did our custom action in the Finish Dialogs stage run.

Bizarrely, I have found that changing the installer name seems to resolve the problem. However, this still appears to be exclusive to the specific brand and changing another brand's installer to the "broken" name does not have the expected effect of the second brand's upgrade failing. This indicates to me that the name itself is not the root of the problem, and therefore this is unlikely to work as a permanent fix.

I can provide logs and aip project files by email.

Thank you,
Libby

[Catalin]

Hello Libby,

This error may be caused by an Advanced Installer limitation regarding the file extraction.

Currently, the .EXE setup files built with Advanced Installer extract the embedded files (MSI, CAB, etc) asynchronously during the "Wizard Dialogs Stage" to improve the installation time. Our old method was to extract the files at the very beginning of the installation, before the UI dialogs appear.

By setting the "ExtractFilesFirst" property to "1" in "Install Parameters" page, the old extraction method should be used.

However, what happens in your case is really strange - the fact that the "ExitDialog" is not spawned.

Have you tested this on multiple machines or only on the development machine? If you have tested this on multiple clean machines and this problem still reproduced, then yes, please forward me the following:

1) the .AIP file for the older version of the product
2) the .AIP file for the newer version of the product
3) a download link for the older version (which was built using the .AIP from file point 1)
4) a download link for the newer version (which was built using the .AIP file from point 2)

Optional: you can also send me the log file. Even though I can create the log files directly on my machine, I would like to have a look over the log created on your machine as well.

Also, additional information about the environment would be useful. For instance, do you deploy the setups on a Windows 10 machine or is it an older machine?

Looking forward to hearing from you.

Best regards.
Catalin

[drivard]

Hi Catalin,
Thank you for the quick response!

We mostly install on Windows 10, but we do support Windows 8.x for our customers. For this issue, we have only been testing on Windows 10.

Last night, an email was sent to support@advanceinstaller.com by my co-worker, Libby, which contains the info AIP files as well as logs.
We will email download links for the installers separately.

Regards,
Dennis

[drivard]

An email with download links has been sent.

[Catalin]

Hello Libby, Dennis,

Thanks for the provided files.

I have tested this using the sent setups, but unfortunately I was not able to replicate the behavior.

However, I have investigated the .AIP files and I may have found the culprit here. This behavior may be caused by the fact that you have an "EXE setup with resources inside" package type and, on both versions (4.0.0 and 4.0.1), you have the same extraction folder ("Builds" page --> "Configuration" tab --> "Extract Location" field).

With that being said, could you please change the extract location for your second setup (open the 4.0.1 .AIP file --> "Builds" page --> "Configuration" tab --> change the "Extract Location"), rebuild the project and test the scenario once more?

After doing so, if this works, you can simply include the [ProductVersion] property in the "Extract location" path, so the path will be changed every time you will increase the version. This is the best "programmatic" way I can think of right now, which will not require you to manually change it every time you will want to perform an upgrade.

Hope this helps.

Best regards,
Catalin

[drivard]

Hi Catalin,

The change you suggest is actually one I have already tried, and I found it had no impact on the observed behavior.

Thanks,
Libby

[Catalin]

Hello Libby, Dennis,

It's unfortunate to hear that the suggested method did not work.


I will try to further investigate this. However, please keep in mind that this might take some time taking in consideration the fact that I can not reproduce this on my machine.

In what regards your environment, have you tried testing this on a clean machine, or have you tested this only on the development machine? If it's the second, could you please try and test this on a clean machine as well (i.e. a Virtual Machine).

One more thing I can think of is maybe an Antivirus program that blocks the file that appears in the log file ("Sentinel.exe"). With that being said, could you please try to temporarily disable your antivirus and try the scenario once more?

Additionally, I have noticed that you are using a LZMA compression. When you get "source file not found" error, could you please go to the following location:

C:\Users\<user>\AppData\Roaming\PlumChoice, Inc.\ATT\install

At that location, a random folder should be created where the archive is extracted. Please have a look in that folder and search for the Sentinel.exe file to see if it's there.

Hope this helps somehow.

Best regards,
Catalin

[drivard]

Hi Catalin,

I appreciate the response. With respect to the environment, we are able to replicate this behavior on both a clean and a development machine. I have tested on a virtual machine without antivirus enabled and still encountered the problem.

With respect to the "source file not found" error, on upgrades where this problem occurs I have found that none of the files have been extracted at all. This is what led me to try adding the "ExtractFilesFirst" parameter with value "1", with results described above.

Thanks,
Libby

[bkdroid13]

Its great post and help me a lot. please keep continue posting.

[drivard]

Hi Catalin,

We were able to determine the cause of our problem. We have a custom action to shut down the application if it is running at the start of the upgrade/uninstall which takes the executable name as a parameter.

For all brands except the one where we saw this problem, the installer name and the application exe are different. However for the brand where we saw this problem the installer name was the same as the application exe name. This had the result of the installer process getting shut down in addition to the application when the custom action ran during the upgrade, resulting in the observed behavior where the old version would uninstall and the new version would not install. Additionally this explains why changing the installer name consistently resolved the problem.

Thanks for all of your help on this!
Libby

[Catalin]

Hello Libby,

Thank you for your followup on this and for sharing your solution with us. I am sure this will be of help for further users facing a similar scenario.

I am really glad you got this working.

Best regards,
Catalin