5 replies to this topic

[reflex]

Hi guys,

I hope some light can be shed on this...

I have a VBScript custom action (Type 38) which is running in the InstallExecute sequence. The installation runs fine on a whole host of machines except for one machine (Windows 2000).
It returns this error when it tries to run the CA:

MSI (s) (48:B4): Creating MSIHANDLE (64) of type 0 for thread 948
MSI (s) (48:B4): Failed to marshal script action.
MSI (s) (48:B4): Failed to marshal script action.
MSI (s) (48:B4): Closing MSIHANDLE (64) of type 0 for thread 948
MSI (s) (48:B4): Closing MSIHANDLE (63) of type 790542 for thread 948
Action ended 7:46:25: ConvertCase. Return value 3.

Does anyone know why this is happening or has it happened to anyone else before?

All the custom action is doing is some string manipulation, changing the value of properties to be all upper-case.

Thanks in advance

Pete

[Stefan Krueger]

Does the script run on that machine if you save it as .vbs file and launch it directly? I suspect the VBScript may be disabled or damaged on that machine. Or a virus scanner is preventing VBS from running.

[reflex]

I have asked the client to try and run a .vbs file manually to see if that is the problem, still waiting for a response back.

Thanks for the pointers, I will keep you informed as to the outcome.

[reflex]

This one is about to make me go mad.

We have tested stand-alone .vbs files on the machine and they work fine, disabled Anti-Virus software and tried a few other permutations only for the problem to persist.
The machines are all set up off the same image and there are only 2 different hardware specs in the machines that are being used. So far, out of a deployment base of 90 machines 5 machines have the same problem. Anybody got any further ideas as to what the problem could be?

Regards

Pete.

[Zweitze]

The one thing I can think of, is that the script contains IF..THEN..ELSE or SELECT CASE, or something like that, causing the script engine to take different paths compared to similar systems.

Some ideas:

Check if parts of the script code uses the WScript object, eg
WScript.Echo "test"
The WScript object does exist when the script is run by WScript.exe and CScript.exe, but it does not exist when the script is run by other software, in this instance Msiexec.exe.

Change the script, include generic error handling:
On Error Resume Next
Maybe your script raises an error, in certain circumstances.

Try moving the CA to the UI sequence, after installation. Maybe your script attempts some user interface, which is not always available - in the Execute sequence, it depends on the impersonation setting of the Windows Installer service.

Maybe your script uses some Active Scripting features that are not supported on the target system. Look at http://www.microsoft.com/scripting for the latest sripting engine (5.6, also part of IE 6.0)

Try writing to the log inside your script, to determine what line is causing the failure. Use Session.Message(.., Info)

[dlphillips1]

Wow, the lame responses from IS on this subject are more reminders of how little they know about the Windows Installer.

The failure you are seeing, "Failed to marshal script action", is caused by the inability of the Windows Installer to instantiate a COM object to support its runtime script engine. This failure is most often caused by the lack of or corrupted registration of the Microsoft OLE Automation library OLEAUT32.DLL.

You should confirm that this file is installed on your target system, and that is is correctly registered using regsvr32.exe.

Note that Microsoft recently updated this file in Patch MS07-43 (KB921503) and MS08-08(KB943055). Since these are both important security updates, you should have both of them already installed. Also, for Windows Xp and 2003 SP1, this file should be a protected system file, and any attempt to unregister it will return an access violation. However, it's registry signature could also be corrupted.

Regards

Dave