Update: The problem suddenly went away by itself and I haven't reproduced it since. I can only assume there was some strange problem with the registry permissions that wasn't showing up in the permissions UI, but otherwise I have no idea what the problem was or what solved it.
Context
In my installer I have a custom action that needs to read some registry values that a previous version of the software may have created (they are not created by the installer). The software runs under the SYSTEM account and the installer runs elevated. The OS, installer, and custom action are all 64-bit. The values are in HKLM.
Problem
Attempting to read the values in the custom action using RegQueryValueEx
always returns ERROR_FILE_NOT_FOUND
implying that they don't exist even when they do.
I have determined that if the custom action creates a registry value using RegSetValueEx
then it can read it, even on subsequent executions when it doesn't write to the value. I tested this by temporarily adding calls to RegSetValueEx
and RegQueryValueEx
for a new value, running the installer, removing the RegSetValueEx
call, and re-running the installer.
I have also determined that the custom action is able to successfully write to values created by the application and can then read them back immediately, but still cannot read them on subsequent executions.
Ruled-out answers
The tests above confirmed that the value is located in the correct registry path, ruling out redirection, typos, etc.
The tests also ruled out a local dummy registry that only contains values that the custom action writes to, as the custom action could read the value it created in subsequent executions when it didn't write to it.
The most obvious potential cause was a permissions issue, but the value created by the custom action and another value created by the application (that can't be read by the custom action) have identical permissions as far as RegEdit is able to show me.
I've attempted to search for other instances of people having this issue, but I'm only really finding results related to 32-bit registry redirection and permissions, neither of which seem to be the issue here.
Any solutions or further tests I could run to narrow the issue down would be appreciated.