1

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.

Kemp
  • 3,467
  • 1
  • 18
  • 27
  • The typical is as you state: bitness issues, permission, wrong paths specified, but there is also a registry hive for the system account. Is the custom action running in system context you say? I am a bit confused. Is this application a service running as localsystem? If so, is the registry key in HKLM? What you need is proper debugging with step-through. Did you get that set up? If not, [here is an answer you must read thoroughly on MSI custom action debugging](https://stackoverflow.com/a/52880033/129130). Start with [the video](https://www.youtube.com/watch?v=ayeBB97_NwA) please. – Stein Åsmul Jan 29 '21 at 04:36
  • Maybe [this step-by-step answer on C# custom actions](https://stackoverflow.com/a/60384739/129130) can help too? – Stein Åsmul Jan 29 '21 at 04:38
  • @SteinÅsmul Correct, the application is a service running under the SYSTEM account and the keys are in HKLM. This particular custom action is C++. I have logging liberally sprinkled through the custom action and the return value from `RegQueryValueEx` is `ERROR_FILE_NOT_FOUND` indicating I attempted to read a value that didn't exist. I'm not sure what a debugging session will show me beyond that as the variables involved (e.g. the key handle) are completely opaque and I'm already logging all the inputs I'm providing and the return values. – Kemp Jan 29 '21 at 14:17
  • I would recommend you spend an hour getting proper step-through-debugging working. It is quite easy once you follow the steps. I am willing to guarantee you that as you step through the code looking at the variables, the paths and the calls pending, you will find the solution. You can even step over, change variables and drag the step-cursor back and forth to re-run commands with your own tweaks - just like normal debugging. Set a breakpoint and get this fixed. – Stein Åsmul Jan 29 '21 at 14:47

0 Answers0