PDA

View Full Version : "Abort" script command does not work on Windows 8.1



kmoulton
12-16-2013, 02:47 PM
I have several InstallScripts that use the "abort" command. However, this command no longer works on windows 8.1. It does not abort the install. I discovered this in a script I was running on Windows 8.1

To verify this, I created a simple InstallScript custom action in which all I did was call "abort". When I ran it on windows 8 it worked and caused the install to be interrupted. When I ran it on Windows 8.1 the install continued to run as it normally does.

Is this a known issue?

kmoulton
12-17-2013, 01:28 PM
Technical support has acknowledged that this is a known issue.


"Below is the change log for the work order IOA-000081302 for the release notes for Installshield 2013"

“InstallScript custom action code that uses the abort statement now triggers the installation to abort under appropriate conditions as expected. Previously, the custom action that contained the abort statement returned a value that indicated an error instead of the end user aborting. Thus, the abort statement may not have worked. In one scenario on Windows 8.1 target systems, the issue caused the custom action to stop running but the installation continued.
Note that the abort statement will now result in a custom action returning ERROR_INSTALL_USEREXIT (1602). This does not abort an installation when called from a control event. To abort in that case, your custom action must instead return ERROR_INSTALL_FAILURE (1603).”

Still from technical support:



The intent of the abort method is to indicate that the installation was cancelled. Thus, when called in an InstallScript custom action run from a DoAction event, it should have caused the custom action to return ERROR_INSTALL_USEREXIT (1602). When an action called from a DoAction event returns ERROR_INSTALL_USEREXIT (1602), the MSI installer is not forced to exit and continues.

There was an issue with the abort method that caused it to return, in some circumstances, an error indicating failure, ERROR_INSTALL_FAILURE (1603). If a custom action called from DoAction event returns 1603, it causes the installer to exit. This was not the correct or intended behavior.

The issue that caused the incorrect return code was discovered due to the fact that when run on Windows 8.1, the same code rather than returning 1603 returned 0. This caused the installer to just continue after the custom action rather than causing the installer to exit. While investigating this issue the underlying issue with abort was discovered and fixed. Now, when abort is called in an InstallScript custom action, it correctly returns ERROR_INSTALL_USEREXIT (1602). Unfortunately, this results in a change in behavior for users who expected abort to cause the installer to exit.

The resolution for this would be to use ERROR_INSTALL_FAILURE instead of "abort" statement.

We understand that there will be some effort involved in updating installers that use the abort method in InstallScript custom actions, however, the resulting changes will make for better, more reliable installations.

In my particular case, I was not using DoAction and was just calling the abort method in InstallScript.

I don't necessarily agree with this decision, but at least technical support was swift to reply and acknowledge the situation.

MichaelU
12-31-2013, 11:41 AM
Thanks for the follow-up. If you haven't installed SP1, I would suggest doing so; it is supposed to resolve the part of the behavior on Windows 8.1 (or Windows Server equivalent) systems that resulted in the abort statement returning 0. Since you're not using it from a DoAction, either 1602 or 1603 should end the installation.

The DoAction case is still a good cautionary note. Even with this fix, there is a behavior change between versions of InstallShield: in some versions it returns 1602; in others 1603. If you ever do use similar code in a DoAction, you may want to explicitly control the return value.

santoshchalla
09-10-2014, 01:17 PM
Thanks for the follow-up. If you haven't installed SP1, I would suggest doing so; it is supposed to resolve the part of the behavior on Windows 8.1 (or Windows Server equivalent) systems that resulted in the abort statement returning 0. Since you're not using it from a DoAction, either 1602 or 1603 should end the installation.

The DoAction case is still a good cautionary note. Even with this fix, there is a behavior change between versions of InstallShield: in some versions it returns 1602; in others 1603. If you ever do use similar code in a DoAction, you may want to explicitly control the return value.

I am also facing same problem with abort, as per the above suggestion i have changes from "Abort" to "ERROR_INSTALL_FAILURE" , now my installer is not working in the earlier os also(win 7 win 2008..etc)... how we can fix this problem?

kmoulton
09-15-2014, 10:25 AM
I am also facing same problem with abort, as per the above suggestion i have changes from "Abort" to "ERROR_INSTALL_FAILURE" , now my installer is not working in the earlier os also(win 7 win 2008..etc)... how we can fix this problem?

Just move to InstallShield 2013 and continue to use abort. This will resolve the abort issue.

--Kim