This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Problem with KB3072630 InstallScript and RegDBGetKeyValueEx
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 11, 2015
11:32 AM
Problem with KB3072630 InstallScript and RegDBGetKeyValueEx
Sigh, On Installshield 2014 (btw. issue also affects 2012) I am having issues with reading registry CURRENT_USER subkeys when KB3072630 is installed.
Specifically in InstallScript, RegDBKeyExist( ) and RegDBGetKeyValueEx( ) both fail. I used the directions in KB3072630 to disable it and these functions again work.
I tried the hotfix suggested by MichealU for DCostello's similar issue. No dice, updating the IsLockPermissions.dll with the hotfix did not work.
Any thoughts of what I can do, The value I need is place in the registry with a Custom Action "After CostFinalize", and then used for a set of custom action that execute After DuplicateFiles. I have verified the value is still being written to the registry, I just can no longer read it.
Is there a different/better way to pass the two strings, or a way to get RegDBGetKeyValueEx to work. I do not want to be disabling KB3072630 on end user machines.
(KB3072630 work around is described in the patch: https://support.microsoft.com/en-us/kb/3072630 )
(Installsheild 2015 hotfix for IsLockPermissions.dll: https://flexeracommunity.force.com/customer/articles/en_US/ISSUE/ISDEV-Windows-Update-KB3072630-causes-Registry-permission-changes-to-HKCU-to-fail )
Specifically in InstallScript, RegDBKeyExist( ) and RegDBGetKeyValueEx( ) both fail. I used the directions in KB3072630 to disable it and these functions again work.
I tried the hotfix suggested by MichealU for DCostello's similar issue. No dice, updating the IsLockPermissions.dll with the hotfix did not work.
Any thoughts of what I can do, The value I need is place in the registry with a Custom Action "After CostFinalize", and then used for a set of custom action that execute After DuplicateFiles. I have verified the value is still being written to the registry, I just can no longer read it.
Is there a different/better way to pass the two strings, or a way to get RegDBGetKeyValueEx to work. I do not want to be disabling KB3072630 on end user machines.
(KB3072630 work around is described in the patch: https://support.microsoft.com/en-us/kb/3072630 )
(Installsheild 2015 hotfix for IsLockPermissions.dll: https://flexeracommunity.force.com/customer/articles/en_US/ISSUE/ISDEV-Windows-Update-KB3072630-causes-Registry-permission-changes-to-HKCU-to-fail )
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 11, 2015
12:32 PM
If you need to access HKCU, the simplest answer is to ensure that your action has its In-Script Execution set to something that doesn't include "System Context" such as just "Deferred Execution". If there are other reasons this action needs to be executed in the system context, you need to find another way to find the correct registry keys for the "current user" you have in mind, such as by locating the correct user under HKU. (Be careful not to over-generalize the HKU approach, as not all user-specific registry data is always available in multi-user systems.)
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 11, 2015
12:41 PM
Micheal,
So you are saying use something other than Deferred Execution in System Context, like maybe plane Deferred Execution. I will play around with that field and report back if successful.
So you are saying use something other than Deferred Execution in System Context, like maybe plane Deferred Execution. I will play around with that field and report back if successful.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 12, 2015
03:06 PM
Michael,
Thankyou for your help on this. Removing the action from the system context worked to a point. Sadly, the script is for setting up an OEM camera we have made by a third party vendor. The camera for setup needs the script to execute in the System Context. Fun, fun, long story short, I took a hard look at why the registry was used and by rewriting this script was able to do what was needed to this camera without passing items through the registry.
Thankyou Again
Kevin Flanagan
Of course I did manage to break other things, but that will be a future post 😉
Thankyou for your help on this. Removing the action from the system context worked to a point. Sadly, the script is for setting up an OEM camera we have made by a third party vendor. The camera for setup needs the script to execute in the System Context. Fun, fun, long story short, I took a hard look at why the registry was used and by rewriting this script was able to do what was needed to this camera without passing items through the registry.
Thankyou Again
Kevin Flanagan
Of course I did manage to break other things, but that will be a future post 😉
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)