EnhancedUI crashes upgrade if FolderDlg has Volume Cost List

[toddpatt]

Ahoy,

I'm using AI 7.7 build 28804

It seems that an upgrade will hang/crash if:
(1) the existing version of the app is running
AND
(2)the upgrade package is using the Enhanced UI and contains a "Volume Cost List" on the FolderDlg

Here are the steps to reproduce the problem:

===== Project =====
* type = Enterprise
* add a "Volume Cost List" control to the FolderDlg
* select "Automatically upgrade older product versions" option
* enable Enhanced UI

===== Build =====
* build version 1.0.0 and set aside
* build version 1.0.1 with a new Product Code

===== Install Base =====
* install version 1.0.0
* notice the "Volume Cost List" displays properly on the FolderDlg
* start your app so that the main window is open, leave the app running

===== Install Upgrade =====
* run the 1.0.1 installer
* on the WelcomeDlg click "Next"
* at this point the installer window goes white and doesn't respond - must be manually killed

* now disable the Enhanced UI option and use the basic UI instead, rebuild version 1.0.1
* ensure version 1.0.0 of your app is still running
* repeat the same steps as above to install the upgrade
* now the upgrade doesn't hang, the FolderDlg with the Volume Cost List is displayed properly, and the upgrade completes normally (eventually triggers the FilesInUse dlg, but that is expected)

===== Environment =====
I have tested on WinXP and Win7 - the problem exists on both.

===== Additional Notes =====
* If the "Volume Cost List" control is removed, but the Enhanced UI is still enabled, the upgrade does not crash.
* If version 1.0.0 of the app is not running, the upgrade does not crash. It's only a problem if the EnhancedUI is enabled, and the "Volume Cost List" is added, and the base version is running.


Thanks,
Todd

[Cosmin]

Hi Todd,

Unfortunately we are unable to reproduce this behavior on our test machines. Does your machine have any special drives (for example a mapped network drive) or drive settings? If it doesn't, can you please send us the .AIP (project) files you are using to support at advancedinstaller dot com so we can investigate them?

Regards,
Cosmin

[toddpatt]

Thanks for your reply.

I can reproduce this problem on several different machines, all of which have a single physical drive, no removable media (USB sticks, etc) attached, and no mounted network drives. There is nothing noteworthy about the drive settings, all set to default values.

I can send a very simple project-file which I created specifically to reproduce this bug.

Also, I did some additional testing and I think I may have uncovered another aspect of the problem, which may be why it was not reproducible on your side.

===== WinXP =====
Hang can be reproduced with original requirements: EnhancedUI + VolumeCostList + base version is running
Also note, I can reproduce the hang with either of the following "Installation Type" values:
- "per-user only"
- "per-machine if user is administrator, per-user otherwise"

Here is a screen-shot of the hang on WinXP:

AI - hung on FolderDlg - WinXP.JPG (8.86 KiB) Viewed 10150 times

===== Win7 =====
Hang can be reproduced with the original requirements (EnhancedUI + VolumeCostList + base version is running), but only if the "Installation Type" is set to "per-user only". If the Installation Type is left as the default value ("per-machine if user is administrator, per-user otherwise"), the hang does not occur, but the value of the "Required" column on the VolumeCostList is a negative number:

AI - bad value on VolCostList - Win7.JPG (56.1 KiB) Viewed 10150 times

Assuming the requirements are met (including the "per-user only" install type), here is a screen-shot of the hang on Win7:

AI - hung on FolderDlg - Win7.JPG (35.63 KiB) Viewed 10150 times

Hopefully this allows you to reproduce the problem.

Thanks,
Todd

[GabrielBarbu]

Hi Todd,

Thank you for the detailed report! I have now been able to reproduce the issue.
A bugfix will be included in a future version of Advanced Installer.

Best regards,
Gabriel

[toddpatt]

Thanks for confirming, Gabriel.

As a final data-point, I just wanted to mention that all of the machines on which I reproduced this bug are 32-bit. The problem may or may not exist on 64-bit hardware; I do not currently have access to any 64-bit machines to test it.

I'll look for the fix in a future version.

Thanks again,
Todd