This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Abort issue seen in Windows 8.1 and newer Operating Systems
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Dec 16, 2013
01:47 PM
"Abort" script command does not work on Windows 8.1
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?
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?
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Dec 17, 2013
12:28 PM
Technical support has acknowledged that this is a known issue.
Still from technical support:
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.
"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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Dec 31, 2013
10: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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Sep 10, 2014
01:17 PM
MichaelU wrote:
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?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Sep 15, 2014
10:25 AM
santoshchalla wrote:
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