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
- :
- Re: Custom Actions fail with Error 3 on Wnidows Core OS
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 19, 2013
02:40 AM
Custom Actions fail with Error 3 on Wnidows Core OS
Hi Everyone,
I have a IS2012Spring Basic MSI project which I have converted over to IS2013. This project contains numerous custom actions (CAs) that still run fine on all Windows OS's except for Windows 2008 Core x86, x64 (including 2008 R2).
I should add these CAs run fine on Windows Core when the project is built with IS2012Spring. The CAs seem to be returning error 3 all the time - see log extract below:
[CODE]MSI (c) (B4:90) [15:58:35:666]: Doing action: INSTALL
Action 15:58:35: INSTALL.
Action start 15:58:35: INSTALL.
MSI (c) (B4:90) [15:58:35:666]: UI Sequence table 'InstallUISequence' is present and populated.
MSI (c) (B4:90) [15:58:35:666]: Running UISequence
MSI (c) (B4:90) [15:58:35:666]: PROPERTY CHANGE: Adding EXECUTEACTION property. Its value is 'INSTALL'.
MSI (c) (B4:90) [15:58:35:666]: Doing action: InitialiseLogging
Action 15:58:35: InitialiseLogging.
Action start 15:58:35: InitialiseLogging.
MSI (c) (B4:3C) [15:58:35:682]: Invoking remote custom action. DLL: C:\Users\ADMINI~1\AppData\Local\Temp\2\MSIEFE2.tmp, Entrypoint: f9
MSI (c) (B4:10) [15:58:35:682]: Cloaking enabled.
MSI (c) (B4:10) [15:58:35:682]: Attempting to enable all disabled privileges before calling Install on Server
MSI (c) (B4:10) [15:58:35:682]: Connected to service for CA interface.
InstallShield 15:58:35: Running InstallScript function f9
InstallShield 15:58:35: Opening stream of file C:\Users\ADMINI~1\AppData\Local\Temp\2\MSIEFE2.tmp
InstallShield 15:58:35: Extracting support file IsConfig.ini to C:\Users\ADMINI~1\AppData\Local\Temp\2\{7EC88D63-0A10-4C24-8A2D-F1254079F457}\IsConfig.ini
InstallShield 15:58:35: Extracted isconfig.ini to C:\Users\ADMINI~1\AppData\Local\Temp\2\{7EC88D63-0A10-4C24-8A2D-F1254079F457}\IsConfig.ini
InstallShield 15:58:35: Got '{0CCF62D0-CAD1-4724-8BE0-F2DFFD524CDD}' for TempPathGuid from isconfig.ini
InstallShield 15:58:35: Attempting to use temp path 'C:\Users\ADMINI~1\AppData\Local\Temp\2\{0CCF62D0-CAD1-4724-8BE0-F2DFFD524CDD}'
InstallShield 15:58:35: Using new temp path
InstallShield 15:58:35: Cleaning up temp file C:\Users\ADMINI~1\AppData\Local\Temp\2\{7EC88D63-0A10-4C24-8A2D-F1254079F457}\IsConfig.ini
InstallShield 15:58:35: Using temp folder C:\Users\ADMINI~1\AppData\Local\Temp\2\{0CCF62D0-CAD1-4724-8BE0-F2DFFD524CDD}
InstallShield 15:58:35: Installing engine...
InstallShield 15:58:35: Using product language 1033
InstallShield 15:58:35: Skipping optional support file _isuser_0x0409.dll
InstallShield 15:58:35: Setting script cmdline...
InstallShield 15:58:35: ProductCode is {787C32E7-3B36-4080-AC1E-92A9D9D9CF94}
InstallShield 15:58:35: Initializing Engine
Action ended 15:58:36: InitialiseLogging. Return value 3.
MSI (c) (B4:90) [15:58:36:135]: Doing action: SetupCompleteError
Action 15:58:36: SetupCompleteError.
Action start 15:58:36: SetupCompleteError.
[/CODE]
I have several projects that I've converted to IS2013 and all exhibit the same issue on Core - all worked fine when built with IS2012Spring.
Since these CAs all run fine on non-Core OS's it implies there may be something missing in Core that the IS2013 CA interface depends upon? Are there any changes to the CA interface between 2012Spring and 2013 that could account for this behaviour?
Thanks in advance.
I have a IS2012Spring Basic MSI project which I have converted over to IS2013. This project contains numerous custom actions (CAs) that still run fine on all Windows OS's except for Windows 2008 Core x86, x64 (including 2008 R2).
I should add these CAs run fine on Windows Core when the project is built with IS2012Spring. The CAs seem to be returning error 3 all the time - see log extract below:
[CODE]MSI (c) (B4:90) [15:58:35:666]: Doing action: INSTALL
Action 15:58:35: INSTALL.
Action start 15:58:35: INSTALL.
MSI (c) (B4:90) [15:58:35:666]: UI Sequence table 'InstallUISequence' is present and populated.
MSI (c) (B4:90) [15:58:35:666]: Running UISequence
MSI (c) (B4:90) [15:58:35:666]: PROPERTY CHANGE: Adding EXECUTEACTION property. Its value is 'INSTALL'.
MSI (c) (B4:90) [15:58:35:666]: Doing action: InitialiseLogging
Action 15:58:35: InitialiseLogging.
Action start 15:58:35: InitialiseLogging.
MSI (c) (B4:3C) [15:58:35:682]: Invoking remote custom action. DLL: C:\Users\ADMINI~1\AppData\Local\Temp\2\MSIEFE2.tmp, Entrypoint: f9
MSI (c) (B4:10) [15:58:35:682]: Cloaking enabled.
MSI (c) (B4:10) [15:58:35:682]: Attempting to enable all disabled privileges before calling Install on Server
MSI (c) (B4:10) [15:58:35:682]: Connected to service for CA interface.
InstallShield 15:58:35: Running InstallScript function f9
InstallShield 15:58:35: Opening stream of file C:\Users\ADMINI~1\AppData\Local\Temp\2\MSIEFE2.tmp
InstallShield 15:58:35: Extracting support file IsConfig.ini to C:\Users\ADMINI~1\AppData\Local\Temp\2\{7EC88D63-0A10-4C24-8A2D-F1254079F457}\IsConfig.ini
InstallShield 15:58:35: Extracted isconfig.ini to C:\Users\ADMINI~1\AppData\Local\Temp\2\{7EC88D63-0A10-4C24-8A2D-F1254079F457}\IsConfig.ini
InstallShield 15:58:35: Got '{0CCF62D0-CAD1-4724-8BE0-F2DFFD524CDD}' for TempPathGuid from isconfig.ini
InstallShield 15:58:35: Attempting to use temp path 'C:\Users\ADMINI~1\AppData\Local\Temp\2\{0CCF62D0-CAD1-4724-8BE0-F2DFFD524CDD}'
InstallShield 15:58:35: Using new temp path
InstallShield 15:58:35: Cleaning up temp file C:\Users\ADMINI~1\AppData\Local\Temp\2\{7EC88D63-0A10-4C24-8A2D-F1254079F457}\IsConfig.ini
InstallShield 15:58:35: Using temp folder C:\Users\ADMINI~1\AppData\Local\Temp\2\{0CCF62D0-CAD1-4724-8BE0-F2DFFD524CDD}
InstallShield 15:58:35: Installing engine...
InstallShield 15:58:35: Using product language 1033
InstallShield 15:58:35: Skipping optional support file _isuser_0x0409.dll
InstallShield 15:58:35: Setting script cmdline...
InstallShield 15:58:35: ProductCode is {787C32E7-3B36-4080-AC1E-92A9D9D9CF94}
InstallShield 15:58:35: Initializing Engine
Action ended 15:58:36: InitialiseLogging. Return value 3.
MSI (c) (B4:90) [15:58:36:135]: Doing action: SetupCompleteError
Action 15:58:36: SetupCompleteError.
Action start 15:58:36: SetupCompleteError.
[/CODE]
I have several projects that I've converted to IS2013 and all exhibit the same issue on Core - all worked fine when built with IS2012Spring.
Since these CAs all run fine on non-Core OS's it implies there may be something missing in Core that the IS2013 CA interface depends upon? Are there any changes to the CA interface between 2012Spring and 2013 that could account for this behaviour?
Thanks in advance.
(12) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 05, 2013
02:00 AM
We are also seeing this, but on all versions of Windows (7, XP)
I have been in contact with InstallShield support, but they haven't been very helpful (I must note that it's not that they don't want to help, they just can't).
My suspicion is something is wrong with the installscript engine, their reply is 'Unfortunately, this issue is might be due to the internal behavior change of installscript engine in installshield 2013.'
Nothing I tried so far works -- setting new style, commenting out code, ...
I should also not that it only fails when doing 'remote' installations.
I'm seriously considering either sticking with IS2012 or chucking out InstallScript CA's completely.
InstallShield 08:51:11: Setting script cmdline...
InstallShield 08:51:11: ProductCode is {...}
InstallShield 08:51:11: Initializing Engine
CustomAction CheckProperties returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 08:51:11: CheckProperties. Return value 3.
Action ended 08:51:11: INSTALL. Return value 3.
I have been in contact with InstallShield support, but they haven't been very helpful (I must note that it's not that they don't want to help, they just can't).
My suspicion is something is wrong with the installscript engine, their reply is 'Unfortunately, this issue is might be due to the internal behavior change of installscript engine in installshield 2013.'
Nothing I tried so far works -- setting new style, commenting out code, ...
I should also not that it only fails when doing 'remote' installations.
I'm seriously considering either sticking with IS2012 or chucking out InstallScript CA's completely.
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 05, 2013
02:58 AM
I think my issue is different to yours. Mine is exclusive to CA's that worked in 2012Spring but not when the project is converted to 2013 and even then only on Windows Core OS's.
So far this is unresolved, so I have reverted back to 2012Spring for these projects.
So far this is unresolved, so I have reverted back to 2012Spring for these projects.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 05, 2013
04:26 AM
I think my issue is different to yours.
Probably, but from the (lack of) log file information (both exit at the 'Initializing Engine' stage), as well as the fact that ours also work in IS2012 spring but not in IS2013, it may well be related somehow.
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 05, 2013
04:46 AM
Agreed on the log file information. There is nothing to help diagnose the problem other than the reported error 3.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 06, 2013
12:20 PM
We have discovered an issue that can occur when the InstallScript engine is initializing built in text substitutions/variables. Specifically, an issue can occur if running in a user account where user shell folders are set in the registry but do not exist on the file system. We have seen this occur when a user account is created but never logged on or when running in the local SYSTEM account. The engine uses the SHGetSpecialFolderLocation shell API to obtain these paths. This API also verifies that the path being returned exists on the system and returns an error if it does not. A change to this error handling results in the engine initialization failing to complete successfully.
The InstallScript engine initializes text substitution values for the following user shell folder paths:
- CSIDL_PERSONAL
- CSIDL_APPDATA
- CSIDL_COMMON_APPDATA
- CSIDL_LOCAL_APPDATA
- CSIDL_FONTS
- CSIDL_PROGRAMS
- CSIDL_COMMON_PROGRAMS
- CSIDL_DESKTOPDIRECTORY
- CSIDL_COMMON_DESKTOPDIRECTORY
- CSIDL_STARTUP
- CSIDL_COMMON_STARTUP
- CSIDL_STARTMENU
- CSIDL_COMMON_STARTMENU
The one path we have seen as an issue in the above mentioned scenarios is CSIDL_STARTUP. In such cases this folder does not exist on the file system in a user's profile, which causes the SHGetSpecialFolderLocation API to return a failure status and results in the initialization of the script engine being aborted.
On systems where you are seeing this type of failure in an MSI log with InstallScript actions, verify that the above shell folders exist in the user profile the custom action runs in ("COMMON" folders can be skipped since they will most likely be present).
If any of the above folders are missing, creating them, or logging on as the user to create them, should resolve the behavior. We are currently working on a code-based solution to this issue.
The InstallScript engine initializes text substitution values for the following user shell folder paths:
- CSIDL_PERSONAL
- CSIDL_APPDATA
- CSIDL_COMMON_APPDATA
- CSIDL_LOCAL_APPDATA
- CSIDL_FONTS
- CSIDL_PROGRAMS
- CSIDL_COMMON_PROGRAMS
- CSIDL_DESKTOPDIRECTORY
- CSIDL_COMMON_DESKTOPDIRECTORY
- CSIDL_STARTUP
- CSIDL_COMMON_STARTUP
- CSIDL_STARTMENU
- CSIDL_COMMON_STARTMENU
The one path we have seen as an issue in the above mentioned scenarios is CSIDL_STARTUP. In such cases this folder does not exist on the file system in a user's profile, which causes the SHGetSpecialFolderLocation API to return a failure status and results in the initialization of the script engine being aborted.
On systems where you are seeing this type of failure in an MSI log with InstallScript actions, verify that the above shell folders exist in the user profile the custom action runs in ("COMMON" folders can be skipped since they will most likely be present).
If any of the above folders are missing, creating them, or logging on as the user to create them, should resolve the behavior. We are currently working on a code-based solution to this issue.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 09, 2013
08:16 AM
Hi Josh,
Thanks for the information!
I wrote a small executable that creates all the folders mentioned, and is run as the first CA in my installation. Now it works! 🙂
Thanks for the information!
I wrote a small executable that creates all the folders mentioned, and is run as the first CA in my installation. Now it works! 🙂
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 09, 2013
08:23 AM
Hi Josh
You're absolutely spot on. Works for me too. As I was testing under Administrator I created the folder "Startup" under:
which was missing. The IS 2013 setup on Win 2008 Core x86 then ran successfully!
Also explains why it worked on Win 2008 R2 Core - that folder appears to be created by default, but not on Win 2008 x86/x64 Core.
You're absolutely spot on. Works for me too. As I was testing under Administrator I created the folder "Startup" under:
C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs
which was missing. The IS 2013 setup on Win 2008 Core x86 then ran successfully!
Also explains why it worked on Win 2008 R2 Core - that folder appears to be created by default, but not on Win 2008 x86/x64 Core.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 10, 2013
02:05 AM
Hi Josh,
I have the same error without message on an Windows XP :
[...]
Action 12:03:37 : InstallValidate. Validation de l'installation
Début de l'action 12:03:37 : InstallValidate.
Fin de l'action 12:03:43 : InstallValidate. Valeur renvoyée : 1.
Action 12:03:43 : ISLockPermissionsCost.
Début de l'action 12:03:43 : ISLockPermissionsCost.
Fin de l'action 12:03:44 : ISLockPermissionsCost. Valeur renvoyée : 3.
Fin de l'action 12:03:44 : INSTALL. Valeur renvoyée : 3.
Property(S): ...
[...]
=== Fin de l'écriture dans le journal : 01/10/2013 12:03:54 ===
MSI (c) (D8:9C) [12:03:54:247]: Produit : XXX -- L'installation a échoué.
MSI (c) (D8:9C) [12:03:54:247]: Windows Installer a installé le produit. Nom du produit : XXX. Version du produit : 4.50. Langue du produit : 1036. Réussite de l’installation ou état d’erreur : 1603.
[...]
My msi worked fine when built with IS2012, but not since it's build with IS2013.
I have made a test with IS2013 SP1, but I have the same error.
And I verify all folders you quote, but they are already all presents.
Would you have an other solution ? Thanks.
I have the same error without message on an Windows XP :
[...]
Action 12:03:37 : InstallValidate. Validation de l'installation
Début de l'action 12:03:37 : InstallValidate.
Fin de l'action 12:03:43 : InstallValidate. Valeur renvoyée : 1.
Action 12:03:43 : ISLockPermissionsCost.
Début de l'action 12:03:43 : ISLockPermissionsCost.
Fin de l'action 12:03:44 : ISLockPermissionsCost. Valeur renvoyée : 3.
Fin de l'action 12:03:44 : INSTALL. Valeur renvoyée : 3.
Property(S): ...
[...]
=== Fin de l'écriture dans le journal : 01/10/2013 12:03:54 ===
MSI (c) (D8:9C) [12:03:54:247]: Produit : XXX -- L'installation a échoué.
MSI (c) (D8:9C) [12:03:54:247]: Windows Installer a installé le produit. Nom du produit : XXX. Version du produit : 4.50. Langue du produit : 1036. Réussite de l’installation ou état d’erreur : 1603.
[...]
My msi worked fine when built with IS2012, but not since it's build with IS2013.
I have made a test with IS2013 SP1, but I have the same error.
And I verify all folders you quote, but they are already all presents.
Would you have an other solution ? Thanks.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 14, 2013
08:27 AM
Hi claudine: I don't believe your error is related to the other in this thread. Errors 3 and 1603 are general errors. The earlier report was in an InstallScript custom action called "InitialiseLogging" but your report is against our stock ISLockPermissionCost. I would suggest running validation against your .msi file, double-checking the values in the ISLockPermissions table for anything out of the norm, and posting a separate thread if those steps don't help you find the solution. (Also ensure your log is a verbose log - generated with /l*v or the full 'voicewarmup' logging policy - to be certain it contains all information possible. I can't tell whether yours was verbose, but it looks like it probably was not.)
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 14, 2013
09:39 AM
Hi MichaelU : Thanks for your response.
Yes, the log I quote is not a verbose log, but since, I have made a verbose log and I haven't more informations !
1) I already have verified the values in the ISLockPermissions and CreateFolder tables, and all the values are OK.
2) I have modified my msi by suppressing all that are in relation with ISLockPermisson, and the install is not even OK : it stoppes after InstalleFiles, on the ISXmlInstall action, always without message, with the return code 1603
3) If I install the previous version of my product built with InstallShield 2012, the install is OK. But, if I build the same project (of this previous version) without any modification, with InstallShield 2013, the install is not OK. If I verify the two msi, with the InstallShield MSI Diff tool, there are not difference between the two, on the ISLockPermissions and CreateFolder tables.
It seems to be a bug from InstallShield 2013, isn't it ?
I'm waiting for others customer's log who have the same error. For many customers, the install is OK.
If you have others ideas...
Yes, the log I quote is not a verbose log, but since, I have made a verbose log and I haven't more informations !
1) I already have verified the values in the ISLockPermissions and CreateFolder tables, and all the values are OK.
2) I have modified my msi by suppressing all that are in relation with ISLockPermisson, and the install is not even OK : it stoppes after InstalleFiles, on the ISXmlInstall action, always without message, with the return code 1603
3) If I install the previous version of my product built with InstallShield 2012, the install is OK. But, if I build the same project (of this previous version) without any modification, with InstallShield 2013, the install is not OK. If I verify the two msi, with the InstallShield MSI Diff tool, there are not difference between the two, on the ISLockPermissions and CreateFolder tables.
It seems to be a bug from InstallShield 2013, isn't it ?
I'm waiting for others customer's log who have the same error. For many customers, the install is OK.
If you have others ideas...
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 24, 2013
02:44 AM
Hello everybody
I still have the same problem. I now have 7 cases and the common point between all these customers is the processor: AMD Athlon XP (1500 + to 3000 +) and Sempron.
Do you have any idea? Because at the moment the only solution we can offer them is to stay in the old version (built with IS2012) or change the server!
Thanks.
I still have the same problem. I now have 7 cases and the common point between all these customers is the processor: AMD Athlon XP (1500 + to 3000 +) and Sempron.
Do you have any idea? Because at the moment the only solution we can offer them is to stay in the old version (built with IS2012) or change the server!
Thanks.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 28, 2014
04:06 AM
Hi Claudine
I have a very similar problem. I have migrated my projects from IS2008 to IS2013. Everything works fine on most of our computers. But there are still computers that are quite old - processor Intel Celeron 650MHz. What is common for this processor and yours AMD's is that they do not support SSE2 instructions! I suppose that new IS2013 dll's are built to use this instructions. I have made some test with one of IS2013 dll - SFHelper.dll. I simply load a library and then I call GetProcAddress of function SFStartupEx. On newer computers everything works fine, but with the old processor the program throws an exception "EXCEPTION_ILLEGAL_INSTRUCTION". When I change the SFHelper.dll to the old one, the program does not throw an exception and works fine also on old Celeron. I think that only solution to this problem is to rebuild all the IS2013 dll's without the need of SSE2 instructions. But that must Flexera do...
I have a very similar problem. I have migrated my projects from IS2008 to IS2013. Everything works fine on most of our computers. But there are still computers that are quite old - processor Intel Celeron 650MHz. What is common for this processor and yours AMD's is that they do not support SSE2 instructions! I suppose that new IS2013 dll's are built to use this instructions. I have made some test with one of IS2013 dll - SFHelper.dll. I simply load a library and then I call GetProcAddress of function SFStartupEx. On newer computers everything works fine, but with the old processor the program throws an exception "EXCEPTION_ILLEGAL_INSTRUCTION". When I change the SFHelper.dll to the old one, the program does not throw an exception and works fine also on old Celeron. I think that only solution to this problem is to rebuild all the IS2013 dll's without the need of SSE2 instructions. But that must Flexera do...
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)