cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Ron_Schaeffer
Level 6

RegDBSetKeyValueEX fails under Win Server 2008 on 64bit

We have an existing installer which has run fine to this point. Now, when we run it under Win Server 2008 on 64bit hardware, we are experiencing a failure in RegDBSetKeyValueEx; initially I was suspicious of the 64bit (we have numerous 64bit redirection issues elsewhere), but I'm now thinking this might be a security issue.

We are attempting to create a custom name value in our product uninstall key so as to retain some info provided in install dialogs. This is done by a Custom Action calling an InstallScript function which calls RegDBSetKeyValueEx; the CA is in the Exec Sequence, After BindImage, and is Immediate mode, synchronous execution. Code snippets are:

MsiGetProperty (hMSI, "ProductCode", szCode, nvSize);
RegDBSetDefaultRoot ( HKEY_LOCAL_MACHINE );
szKey = "SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\" + szCode ;
szNumName = "CustomEnvName";
szNumValue = svCustomEnvName;
nType = REGDB_STRING;
nSize = -1;
nReturn = RegDBSetKeyValueEx (szKey, szNumName, nType, szNumValue, nSize);

On our Win Server 2003 / 32 bit systems, this creates the custom name value without issue (prior to the uninstall key actually existing).

On a Win Server 2008 / 64 bit system it fails with a return status of "-2147024891".

At the same time, I can use Regedit and manually create keys under "SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall" (using the same log on session as I'm running the install under).

I'm stumped (I'm a bit of novice wrt security) - thoughts anyone?

Thanks
Labels (1)
0 Kudos
(3) Replies
joshstechnij
Level 10 Flexeran
Level 10 Flexeran

A custom action that modifies system resources, especially machine wide resources (i.e. HKLM registry keys, files located in Program Files, etc.) should be scheduled as a deferred in system context custom action. An immediate custom action on Windows Vista and 2008 and newer, in normal cases, will not have sufficient privileges to modify privileged resources.

The error code you are seeing translates to "Access is denied." Changing the in-script execution setting to "deferred in system context" for this custom action will then run the custom action with elevated privileges.
0 Kudos
Ron_Schaeffer
Level 6

Yes, that has resolved that issue - now the Custom Action executes without error. Thank you very much for that John!

However, I use a number of properties (all in CAPITALS) with which I pass in the values to use in this custom action (they were not part of the example in the interests of brevity). Because this is now a deferred custom action these properties don't appear to be available now - I'm going to do some more digging in the docs tonight and see what I can find about that.

Thanks again John!
0 Kudos
DanCla
Level 5

If you haven't found how to pass properties to deferred custom actions the link below may help.

http://helpnet.acresso.com/robo/projects/installshield12helplib/accessingprops-deferredcas.htm
0 Kudos