13 replies to this topic

[bjh]

I have a CA constantly failing with "Return value 3", regardless of the code inside the InstallScript function,
regardless of its place in the Execute Sequence. From what I understand, the CA doesn't even enter the script function.

Thanks in advance for any tip/hint,
Jean

[Leigh Ravenhall]

I have had a similar problem, caused by the script engine failing to initialise/install.  If you are logging everything, check at about line 150, where it should be doing the StartUp Action.  Check to make sure the script engine installs/initialises successfully.

[bjh]

I checked the log, indeed. This is where I found the "Return value 3" error in the first place.
It starts like this:
MSI © (27:11): Doing action: SomeAction

and it imediately exists with error.

I forgot to note that there is no condition on this action, so this is not the problem.

Thanks again,
Jean

[Joe Fegan]

You'll get this error if the function you're trying to call is not exported from the DLL.

[bjh]

The action launches an InstallScript function and inside that function (after different kinds of blind tries)
I only put now a call to MessageBox.

[Joe Fegan]

More detail might help people to help you. Maybe the entry in the CustomAction table and even the code of the function if it's not too long.

I don't know anything about InstallShield functions but I have seen return code 3 when trying to call a custom action in a C++ DLL (action type 1) when I forgot to export the function from the DLL using a DEF file or __declspec(dllexport). Maybe there's something equivalent going on here?

[Ian Blake]

I had an apparently mysterious Return Value 3 from one of my CAs this morning.

I tracked my problem down to an invalid pointer that would of caused a page fault or similar.  This was obviously trapped by windows installer and the CA killed.

[Jimmyc]

I have a similiar problem also.

I call a function in a DLL that returns ERROR_SUCCESS and it always
initiates a rollback. I have a messagebox immediatly before the return so I
know its getting immediately before the return(ERROR_SUCESS)....
The function is called via a deferred CA that is sequenced immediately
before InstallFinalize.
The CA type is 1025, or deferred, stored in binary, "call function in
windows installer DLL", wait for action to finish....
If I set the CA to "ignore return option" (i.e. check the checkbox), then it
continues the install.....

As far as I can tell the CA (i.e. RegisterDLL) never does return, according to the log it seems that
InstallFinalize takes over...
The messagebox "Sucess" does display and here are the last 2 lines in the CA
(DLL) function called RegisterDLL.
I'm sure I did something stupid...;) but it's not obvious to me...

Last 2 lines in DLL:
MessageBox(NULL, TEXT("Success"), TEXT("GOOD"), NULL);
 return ERROR_SUCCESS;

Logfile:
Action 8:57:00: RegisterDLL.
MSI (s) (F8:E0): Executing op:
CustomActionSchedule(Action=RegisterDLL,ActionType=1025,Source=BinaryerDL,Ta
rget=RegisterDLL,CustomActionData=C:\Program
Files;Typical;C:\DOCUME~1\wild\LOCALS~1\Temp\{25E1F9BC-B8E6-4332-BE40-531966
6553BE}\;C:\Program Files\Log_Server.log;C:\Program
Files\AutoTuner\bin;C:\Program Files\Autotuner\Saved Installations;WORK TO
DO;VADB;COM_DLLS.TXT;COM_SERVERS.TXT;COM_SERVICES.TXT)
MSI (s) (F8:E0): Creating MSIHANDLE (2967) of type 790536 for thread 2272
Action ended 8:59:39: InstallFinalize. Return value 3.
MSI (s) (F8:E0): User policy value 'DisableRollback' is 0
MSI (s) (F8:E0): Machine policy value 'DisableRollback' is 0
MSI (s) (F8:E0): Executing op:
Header(Signature=1397708873,Version=110,Timestamp=716064477,LangId=1033,Plat
form=0,ScriptType=2,ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttribu
tes=0)
MSI (s) (F8:E0): Executing op: DialogInfo(Type=0,Argument=1033)
MSI (s) (F8:E0): Executing op: DialogInfo(Type=1,Argument=Autotuner)
MSI (s) (F8:E0): Executing op:
RollbackInfo(,RollbackAction=Rollback,RollbackDescription=Rolling back
action:,RollbackTemplate=,CleanupAction=RollbackCleanup,CleanupDescription=R
emoving backup files,CleanupTemplate=File: )
Action 8:59:39: Rollback. Rolling back action:
Rollback: RegisterDLL
MSI (s) (F8:E0): Executing op: ActionStart(Name=RegisterDLL,,)
MSI (s) (F8:E0): Executing op:

[Jimmyc]

I think I found my problem. In the DLL function that I call, a call is made to another exported function in another DLL. Evidently, the call corrupts something enough were the return value is corrupted and the install mechanism thinks the CA returned something other than ERROR_SUCCESS.... I put a try catch(...)
around the call and caught nothing. I can't
debug it since it is a deferred CA and do not want to change the CA to
immediate... Anyhow, I do not like the way the
installer can be fooled so easily....:)

[Ian Blake]

You can debug deferred CAs.

I do it like this

Add a line to display a message box at the start of the CA.

When the message box is displayed load visual studio and use build>debug>attach to process...

Open the source file. Set a break point just after the message box line.

Click the Ok button on the message box and the debugger should halt at your break point ready to debug the function.

[Jimmyc]

I';ve tried that more than once,however, can never get to the actual code... Yeah, I copied my map/pdb's everywhere.... :), but no code...

Someone from installshield told me that this was a limitation. Here is his response:

Unforturnately, there's a limitation in MSI that prevent us to run "Call a
function in a standard dynamic-link lib" type of DLL under deferred mode.
(We need to query the database to find your DLL's entry point, in deferred
mode, the MSI handle is not good for anything. That's the reason why your
DLL was not called. It was bad that our document failed to mention this.

...try immediate....etc...

What type of deferred CA are you debugging?

[Ian Blake]

I use plain type 1 dlls or 1025 when deferred.

If the dll was compiled on the same machine as the execution you shouldn't need to do anything with the pdb files etc.  Visual studio should make the connection between msi385.tmp and MyDLL.dll for you.

My understanding of Installshield's standard DLL is that they wrap your dll with a function of theirs.  This will need to extract your dll from the binary table which is not possible as most of the database is unavailable at this point.

So define your own wrapper function in your dll

unit _stdcall MyWrapper(MSIHANDLE hIWI)
{
  char buffer[1000];
  char *p1, *p2 etc.
  int result;

  MsiGetProperty(hWI, "CustomActionData",  buffer);

  // Parse the buffer into p1,p2 etc.

  result = MyRealFunction(p1, p2 etc)

  return result=good
     ? ERROR_SUCCESS
     :  ERROR_INSTALL_FAILURE;
}

MyWrapperCA
Source: MyDLLBinary
Target: MyWrapper

And a type 51 CA SetMyWrapper tosupply your properties to the wrapper
Source :  MyWrapperCA
Target: [PROP1];[PROP2];etc.

[kris]

I am having the same problem as "bjh" ..... I have an IScript function called through a CA.....it is constantly failing with "Return value 3", regardless of the code inside the InstallScript function...now I only have a MessageBox in the function, and it never displays this message box, so obviously it's dying before it enters my function.  Here is the part in the log file where it failed:

MSI © (F0:A0): Doing action: Start_MySQL_svc
Action start 18:09:43: Start_MySQL_svc.
MSI © (F0:A0): Creating MSIHANDLE (99) of type 790542 for thread 1696
1: f13: Function failed, the user might cancel the installation.
Action ended 18:09:44: Start_MySQL_svc. Return value 3.
MSI © (F0:A0): Doing action: SetupCompleteError
Action start 18:09:44: SetupCompleteError.
Action 18:09:44: SetupCompleteError. Dialog created
Action start 18:09:45: CleanUp.

I am getting desperate....I have tried endless amounts of things...including taking the new setup.exe (I am using ISWI 2.03) to update for any patches and have changed the MSI version in setup.ini.  Nothing's working!  Is this an IS bug?  This error only occurs on SOME systems.....and it's noted that it fails on version that have MSI 2.0 or higher...and it WORKS on systems with MSI vesion UNDER 2.0!!!!

Can anyone help????  

[kris]

it appears that my CA's that run InstallScript code all work fine through the Exectue Sequence, but once it leaves the execute sequence and goes back into the User Interface Sequence, then none of my CA's to run InstallScript code will perform correctly....

what's going on?