View Full Version : file created by custom action not created

05-11-2006, 01:47 PM
I have an installscript custom action that creates an html file whose content is based on the products the user has selected to install. The custom action works on all the Windows platforms I have tested except for Windows Vista. I suspect it has something to do with how permissions are granted in Windows Vista.
The custom action is set to run in "deferred with execution in system context" mode. It is sequenced before InstallFinalize. So why is it not being created?
The log file shows that the custom action is being run but then fails at the point in my InstallScript where I call CreateFile().
Any help would be greatly appreciated.

05-11-2006, 01:48 PM
In case this info is pertinent, I am testing on build 5381 of Windows Vista.

05-11-2006, 05:58 PM
I have realized that none of my custom actions that run as "deferred in system context" mode are actually working on Windows Vista.

But if I take my same installation and build it with InstallShield 10.5 and add the msidbCustomActionTypeNoImpersonate bit (dec 2048) into the custom action table myself, magic happens and my custom actions work.

Christopher Painter
05-11-2006, 06:13 PM
Have you seen this?


Christopher Painter
05-11-2006, 06:25 PM
So I quickly made a Basic MSI with an InstallScript custom action that I made Defferred System Context within the Execute Transaction. It looks correct to me.

DeferredCA_CAD 51 DeferredCA /FOO=Hello
DeferredCA 3073 ISSetup.dll f1

The 51 is a set property CA and the 3073 is

msidbCustomActionTypeDll + msidbCustomActionTypeBinaryData + msidbCustomAction TypeInScript + msidbCustomAction TypeNoImpersonate

Can you confirm your CustomAction table shows the same attributes? Also does a Script CA work for you with the TypeNoImpersonate setting?

05-12-2006, 10:09 AM
My custom action calls an installscript function, I have verifed in the custom action table that the type is 3073.
But it's not just vista that the file fails to get created on. It's on Windows 2000 as well.
I have attached two sample installations.
sample_is10.zip contains a basic msi project created in InstallShield 10.5
sample_is12.zip contains the same basic msi project upgraded to the beta.
The installation created by InstallShield 10.5 creates the sample file.
Yet the installation created by the beta does not.

05-15-2006, 12:23 PM
Has anyone from InstallShield taken a look at this post???

05-15-2006, 02:02 PM
Hi Jennifer, it looks like the problem is with the use of MsiGetProperty in a deferred custom action. I think items like this will be the biggest hurdle both to document and to really sink the idea in.

I modified the line in your script where it logs the CreateFile to read:
SprintfMsiLog("_EditRelNotesHtml: Opened \"%s\\relnotes.html\" file for writing.", sDir);
and the log received ..."\relnotes.html"...
If you insert a MessageBox, or whatever, you will see the same thing. Since there is an empty directory provided, this will show up in the working directory, which is likely to be [SystemFolder]. Look and see if you have a [SystemFolder]relnotes.html on a system you've run this on.

The way to get the desired behavior is to pass in INSTALLDIR and any other properties as CustomActionData.

Christopher Painter
05-15-2006, 02:11 PM
Sorry, I didn't look at her source code. I realized from another thread that alot of IScript developers were going to be suddenly needing to use CustomActionData properly so I wrote a little sample and put it on InstallSite:



05-15-2006, 02:47 PM
Thanks Chris and Michael. I will try this fix now!

05-15-2006, 03:11 PM
I ran across Q104413 last week and asked support about the article. InstallShield support said that since my custom action was written in InstallScript, the article did not apply to me (I took this as meaning using CustomActionData property did not apply to me).
So no my question is does the kb article become relevant only in InstallShield 12 or was support wrong??

Christopher Painter
05-15-2006, 03:39 PM
Sure, just as in this thread:


I'm assuming that you understand deferred custom actions and the defferred custom action data property when I say the following.....

(MichaelU can correct me where I make mistakes...)

Prior to IS12 the IS Script runtime created a singleton object in DCOM using the Running Object Table. This object was created by an immeadiate execution custom action and had full access to the MSIHANDLE. Then when an InstallScript custom action fired it used this object to make MSI API calls such as MSIGetProperty. This alloweded custom actions running in defferred mode to do things that they really should not have ever been able to do.

Starting with IS12 this ROT implementation is gone and IS Functions are called just like any other Type 1 CA. This means ISScript no longer has the ability to access the MSIHANDLE from a defferred custom action.

So now you must schedule your Type51 CustomActionData property and use it to pump whatever data your IS CA needs at runtime.

This may seem bad but it's actually quite good as this is the way MSI was always meant to work in the first place.

05-15-2006, 03:42 PM
Ok, you've clarified the situation quite well Chris. But now I see I'm going to have to make a lot of changes to my installation just so I can start using InstallShield 12. I doubt I'm the only one though so I'll stop my belly-aching right now.

Christopher Painter
05-15-2006, 03:44 PM
As an aside you'll notice I mention in my signature "MSI-SPI++".... I wrote a program using MC++/C# that implements an IPC remoting pattern using .NET 2.0. This basically allows me to call MSI API's for an active install from completly outside of the install. I've slowly been working on a debug solution using this pattern.

The concept is you apply a transform to an install to activate the "spy" ( MSI remoting Host ) and then seperatly attach a debugging client to the host. Then through the host you can read/write properites and call MSI API's for the install.

It's been quite a learning experience but I've just been so swamped at work and at home ( my wife is very sick ) to make any real headway on it.

05-15-2006, 05:04 PM
Yup, Chris's point is straight on. Before IS12 we did something (it may be just holding a MSI handle in the singleton engine as Chris suggests; I'm not sure) to make properties available to InstallScript all the time. As of IS12, Q104413 applies to InstallScript actions because of the rearchitecture.

05-17-2006, 03:21 PM
I tested Michael's suggested fix and used CustomActionData to pass my directory properties.
His fix works and I am able to create the file. BUT....only on machines that I have "percieved" administrative rights on. (I say percieved because of how IS12 now handles the Privileged property - see my post on this)
But if I test my installation on a machine that I have limited rights on, the file does not get created. Is it a permissions issue? Since I set the custom action to run deferred in system context, I thought this means that it will run with elevated privileges regardless of the user's limited privileges. Am I understanding this correctly?

05-17-2006, 05:11 PM
My understanding is that's correct so long as one of several things is true:
The installing user has administrative privileges
The package has been advertised by an administrator
The system allows and the user has enabled Elevated Installs
Some other corner case I've forgotten
The new architecture actually makes the latter cases work a lot better, although I'm certainly confused as to why it would cause trouble for the full administrator case. Did you find any useful information in a verbose log like Robert suggested, particularly looking at the Privileged and AdminUser properties?

05-17-2006, 05:24 PM
I have attached two log files. One logfile is of a successful installation on my development machine. The second logfile is of a failed installation on a test machine that I am an administrator on. Note that the failed installation thinks it was successful but my file was not created, nor were any of my SprintfBox messages displayed.

05-17-2006, 05:43 PM
The following text is an excerpt of the logfile from the failed installation. For some reason the open script operation always fails on my test machine.

(UNKNOWN) InstallShield: Running InstallScript function f1
(UNKNOWN) InstallShield: IsBE.dll location: C:\Documents and Settings\tempadmin\Application Data\InstallShield\ISEngine12.0\IsBE.dll
(UNKNOWN) InstallShield: Using temp folder C:\DOCUME~1\TEMPAD~1\LOCALS~1\Temp\{48728B4A-D277-42A0-852D-6698692DFB80}
(UNKNOWN) InstallShield: Installing engine...
(UNKNOWN) InstallShield: Using product language 1033
(UNKNOWN) InstallShield: Extracting support file setup.inx to C:\DOCUME~1\TEMPAD~1\LOCALS~1\Temp\{48728B4A-D277-42A0-852D-6698692DFB80}\setup.inx
(UNKNOWN) InstallShield: Opening stream of file C:\WINDOWS\Installer\MSIA1.tmp
(UNKNOWN) InstallShield: Extracting support file ISRT.dll to C:\DOCUME~1\TEMPAD~1\LOCALS~1\Temp\{48728B4A-D277-42A0-852D-6698692DFB80}\ISRT.dll
(UNKNOWN) InstallShield: Extracting support file _isres1033.dll to C:\DOCUME~1\TEMPAD~1\LOCALS~1\Temp\{48728B4A-D277-42A0-852D-6698692DFB80}\_isres.dll
(UNKNOWN) InstallShield: Extracting support file String1033.txt to C:\DOCUME~1\TEMPAD~1\LOCALS~1\Temp\{48728B4A-D277-42A0-852D-6698692DFB80}\String1033.txt
(UNKNOWN) InstallShield: Skipping optional support file _isuser1033.dll
(UNKNOWN) InstallShield: Extracting support file IsConfig.ini to C:\DOCUME~1\TEMPAD~1\LOCALS~1\Temp\{48728B4A-D277-42A0-852D-6698692DFB80}\IsConfig.ini
(UNKNOWN) InstallShield: Need to install IsBE.dll
(UNKNOWN) InstallShield: Extracting support file IsBE.dll to C:\Documents and Settings\tempadmin\Application Data\InstallShield\ISEngine12.0\IsBE.dll
(UNKNOWN) InstallShield: Registering file C:\Documents and Settings\tempadmin\Application Data\InstallShield\ISEngine12.0\IsBE.dll
(UNKNOWN) InstallShield: Setting IsBE.dll refcount to -2
(UNKNOWN) InstallShield: Setting script cmdline...
(UNKNOWN) InstallShield: ProductCode is {A92EBDE2-A135-4BAE-8E84-06E2C5C62AFE}
(UNKNOWN) InstallShield: Initializing Engine
(UNKNOWN) InstallShield: Marshalling the , error = 0x80040155
(UNKNOWN) InstallShield: Open Script operation failed, error is 0x80040155
(UNKNOWN) InstallShield: Failed to invoke __ISWIUnInit, error is 0x80070057
(UNKNOWN) InstallShield: Failed to shutdown script engine for script C:\DOCUME~1\TEMPAD~1\LOCALS~1\Temp\{48728B4A-D277-42A0-852D-6698692DFB80}\setup.inx, error is 0x80070057
(UNKNOWN) InstallShield: Initialize() Failure, Failed to Initialize script support, Error = 0x80040155

05-17-2006, 07:57 PM
Please see my reply here (http://community.installshield.com/showthread.php?t=157854)

Christopher Painter
05-17-2006, 08:24 PM
My understanding is that's correct so long as one of several things is true:
The installing user has administrative privileges
The package has been advertised by an administrator
The system allows and the user has enabled Elevated Installs
Some other corner case I've forgotten
The new architecture actually makes the latter cases work a lot better, although I'm certainly confused as to why it would cause trouble for the full administrator case. Did you find any useful information in a verbose log like Robert suggested, particularly looking at the Privileged and AdminUser properties?

MichaelU is spot on here. Windows does not by default elevate all security packages. This would be a major security issue as all someone would have to do is use ORCA to craft some malicious code and then run it as SYSTEM. The invoking user must have admin rights or the package must be advertised ( blessed ) by someone with admin rights.

read the following for detailed information and step by step test cases:


05-18-2006, 10:44 AM
The files that Martin posted have fixed my problems. :)

05-18-2006, 11:46 AM
Thanks for letting us know. I'm glad it works now.

In case anyone is wondering... The latest version of the engine that I posted no longer requires any COM registration (except for some specific registration required only on 64-bit machines). As a result, many of the strange COM related errors like you may have experienced in the past under certain conditions should no longer occur. That's not to say we won't see any problems at all, there's always problems in all software, but this is a huge step in eliminating many of these types of COM related runtime issues that always came up only on certain machines\configurations and were a real bear to track down.

NOTE: This applies to any type of project that uses InstallScript (InstallScript, InstallScript MSI, Basic MSI w\ InstallScript CAs and Merge Modules w\ InstallScript CA), not just InstallScript custom actions. So, all types of projects should be better off.