ReturnCode of CustomAction always 1603 (21.9)

[PascalQuenteux]

During our evaluation of the advanced installer we encountered a problem. We have an exe that is called in a CustomAction.
The return code of this exe should be the return code of the AdvancedInstaller to enable further error handling.
Unfortunately, the return code is always set to 1603 after the CustomAction. This is a very important problem for our Support (They need the real return code).

Our AdvancedInstaller version is 21.9

Enclosed the part in the log:
---------------------------------------------------------

Result-ExitCode : 1004
Failure
SFXCA: RUNDLL32 returned error code: 1004
CustomAction launchFileUI1.CA.dll returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Aktion beendet um 15:01:41: launchFileUI1.CA.dll. Rückgabewert 1603.

----------------------------------------------------------


Thanks in advance,
Pascal

[Catalin]

Hello Pascal and welcome to our forums,

Please note that it is not Advanced Installer that handles the return codes, but rather Windows Installer (msiexec).

1603 is the common code for fatal error.

MsiExec.exe and InstMsi.exe error messages (for developers)

Custom Action Return Values

Note that custom actions that are executable files must return a value of 0 for success. The installer interprets any other return value as failure.

Logging of Action Return Values

That being said, what we would need to do here is add some more details to the Custom Action - for instance, if it's a C# custom action, we could use the Session.Log to add some details depending on the return code of your EXE.

Hope this helps!

Best regards,
Catalin

[PascalQuenteux]

The setup is to be executed at the customer's site via powershell. It is very important to our support that the ReturnCode that our exe returns can be seen in the powershell via LastErrorResult. If this is not possible with AdvancedInstaller or with the Windows Installer (msiexec), we unfortunately cannot change our in-house setup engine to advancedInstaller or to Windows Installer. We have already added the ErrorCode of our exe to the log, but unfortunately this is not enough for our support.

We would appreciate if you could help us out.

Best regards,
Pascal

[Catalin]

Hello Pascal,

As previously explained, this is how the WIndows Installer handles the error codes (please read the links I have provided if you haven't already).

Although your EXE returns a special code, msiexec will interpret it as it follows:

- is it 0? then success

- is it different than 0? then failure

A possible solution I am thinking about is the use of a PowerShell custom action that launches your EXE and then captures its error code and then writes it in the log file. We would use this instead of the "LaunchFile" for your EXE.

Note: in order to write something to a log from your Inline PowerShell script, you can simply use Write-Host cmdlet. This should add all the details you need into the MSI log file.

Best regards,
Catalin

[PascalQuenteux]

Hello Catalin,

Thanks for your hints so far, but to make our problem as transparent as possible, we send you the following examples via Email to "support at advancedinstaller dot com" with the following prefix before the title "[Quenteux1603]".

The examples includes following files:

"TestInstaller2.0.aip" - Project file with our settings
"Files.zip" - The files that will be included in the installation routine, by the AIP file
"CustomAction" - This includes all the compiled files for the custom action, as well as the used codelines in the visual studio solution
"ReturnCodeTest2.exe" -- This is our provided Execution File which will be called by the CustomAction
---

Our process should look like this:

Step 1) CMD/Powershell will start setupTest.exe, which will initiate the installation process of the advancedeinstaller package.
Step 2) Inside the setupTest.exe we have a customaction "call function from attached native DLL" that calls our own exe "ReturnCodeTest2.exe" which is also included in the "Files.zip" files which will be placed/installed by the installation routine
Step 3) The "ReturnCodeTest2.exe" will return a customized errorcode in our example 1001 (but it could be the range from e.g. 1000 till 1005, depending on the parameters that will be given into)
Step 4) The setupTest.exe should abort the setup process and print our Errorcode 1001 into the starting shell (Step 1)

---

As said in the Step2 we used the "call function from attached native DLL" method. In our first tries, we tried to call the "ReturnCodeTest2.exe" directly with the method "Launch installed file". But I read an article which preferred this to get our customaction passed through the shell. E.g --> viewtopic.php?t=25528
---

For our company, the process, which is described in these small steps, is absolutely necessary to buy your product otherwise we unfortunately need to re-evaluate other solutions.

I hope you can now better get your head around this issue. If there are any other topics where we can support you, please feel free to reach out to me.


Best Regards

Pascal

[Catalin]

Hello Pascal,

Thank you very much for the provided resources.

I'm afraid, however, that what you want to achieve might not be doable, as a result of a Windows Installer limitation.

So basically we have our process (custom action), as part of another process, the EXE/MSI.

Even if we launch the EXE using a batch script and then get the return code (%ERRORLEVEL%), the returned code will be that of the EXE.

%~dp0ReturnCodeTest.exe
echo %ERRORLEVEL%

So, the first process that executes is the custom action, that returns a code that is interpreted by the EXE and then the EXE returns another code to the command prompt (either 0 or 1603).

Here is an answer from a StackOverflow thread where the OP wanted to achieve something similar to this:

Well an MSI install doesn't always return 1603. The primary reason for a 1603 is a failing custom action where Windows Installer doesn't know why the custom action code failed, and that custom action code was not robust enough to handle its own errors and provide a message before causing the install to fail (and probably roll back). The verbose log should tell you why it failed.

What I'm thinking about is basically getting the return code of the EXE and spawning a messagebox with some details about the error.

Obviously, the best approach would be to have it written in the log file, but you mentioned you want it as obvious as possible for your support team.

Would that work for you?

Best regards,
Catalin

[Catalin]

Unfortunatley, I wasn't quite able to provide a solution to this, but sure thing, James!

If there is anything else I could help you with, please let me know.

Best regards,
Catalin