/build/static/layout/Breadcrumb_cap_w.png

WinZip 11.1 and the AreExeFilesLocked CA

Here is an interesting approach how the WinZip package is trying to look for files in-use to prevent a successful install/repair/uninstall.

If you install WinZip as per-machine and then trigger a repair as a non-admin user the custom action AreExeFilesLocked is executed (always, no condition) to check for any running winzip related process. The repair fails with the following error message:
The WinZip component 'C:\Program Files\WinZip\winzip32.exe' is running, possibly in another user session. Please logout all other users and press the Retry button to continue, or press Cancel to abort the installation.
(We didn't want to abort the installation did we and there are no other users currently logged in to logout so hitting the Retry button multiple times won't do any good.)

There is no process with that name running.
Heck, I havn't even launched winzip yet since installing it!

The problem is that this custom action (AreExeFilesLocked) itself is locking this executable (winzip32.exe) as it has an open handle on it and therefore prevents a repair from occuring successfully.

Preventing the CA from being executed during a repair (ex. by adding a condition as NOT REINSTALL) or just preventing it from being executed at all; condition to resolve to false (ex. 1=0) or remove the CA from the InstallExecuteSequence table and the repair is a success.
This time any running winzip process will also be closed automatically to perform the repair without any files in-use.

What were they think about!?

0 Comments   [ + ] Show comments

Answers (3)

Posted by: bkelly 17 years ago
Red Belt
0
Goes to show there are still a lot of people who don't understand MSI as well as they should. A product as widely used [installed] as WinZip should really have the attention of someone who understands this kind of problem. Even worse-- like we who create packages for internal distribution, these kind of things should be identified during testing!
Posted by: anonymous_9363 17 years ago
Red Belt
0
What were they think about!?There's your mistake, Kim - you imagine that vendors think :)
Posted by: AngelD 17 years ago
Red Belt
0
Just a little correction.
prevent a successful install/repair/uninstall.
It should be "prevent a successful repair." as during install and uninstall this is performed under an admin/system context depending on the deployment solution.

Ian,
We sure hope anyway [:D]
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ