0

I'm attempting to access registry values (written by another program) that should be readily available via the HKEY_CURRENT_USER registry base key when accessed from the logged on user's context. Unfortunately, I'm accessing this information from a service, therefore from what I've gathered, I have two options:

  • Impersonate the logged on user for every piece of code that accesses the registry and access the registry using the HKEY_CURRENT_USER base key via HKEY_CURRENT_USER/SOFTWARE/Company/Product...
  • Get the logged on user's SID and access the registry using the HKEY_USERS base key via HKEY_USERS/{SID}/SOFTWARE/Company/Product...

I'd very much like to use the second solution, as it is far less complicated for the large codebase I'm working with. I've only recently learned of Registry Virtualization and the problems it can cause, so I'd like to verify that my solutions above will work and ask if there are any other solutions available to solve my problem.

Thanks for any knowledge you can offer on the subject, or articles you can point me towards that I may have been unable to find.

CODe
  • 2,253
  • 6
  • 36
  • 65
  • 1
    Doing per-user stuff from a service is almost always asking for pain. What is going on with the HKCU key in this case? – Billy ONeal May 15 '15 at 19:52
  • Thanks for the reply, I've been having issues where the program I'm attempting to monitor the registry values for has been putting their registry values in a location I'm not monitoring due to Registry Virtualization. – CODe May 15 '15 at 19:55
  • Would my second solution work for my case? Or would the program I'm monitoring potentially store/change their values in their key in another location due to RV? – CODe May 15 '15 at 19:57
  • I'm trying to back this up: why are you monitoring registry values in the first place? – Billy ONeal May 15 '15 at 19:57
  • I'm detecting the install of the program I'm monitoring and attempting to utilize a certain value they are writing to their program's registry key, they store this in the HKEY_CURRENT_USER base key. This should also be available in HKEY_USERS from what I've seen using their SID. – CODe May 15 '15 at 19:59
  • Unfortunately my program is reactive, therefore I really have little choice on whether to access per-user information from my service or not. From what I've dealt with so far, trust me, I'd rather not. I've explored other options and this is a unfortunate necessity. I'm just hoping someone can alleviate any pain caused by a corner case that I've not experienced for my listed solutions that I might find two months down the road. – CODe May 15 '15 at 20:08
  • The first option won't work. HKEY_CURRENT_USER is assigned to a particular user hive the first time it is used, and from that point on is unaffected by impersonation. If you are using impersonation, you need to use RegOpenCurrentUser to get a handle to the user's hive. Keep in mind that unless the user in question is already logged in interactively, the user hive won't be loaded, so neither option will work; in theory you can load it yourself if you know the user's password, but that's very complicated. Also keep in mind that the user logoff won't work properly if you've got a handle open. – Harry Johnston May 16 '15 at 03:09
  • So neither of my solutions will work, but using RegOpenCurrentUser along with impersonation to get the correct hive to query may be viable? Thanks for the help! If you could potentially elaborate and provide an answer, I'd really appreciate it. This stuff is surprisingly complicated for what I originally figured would be a simple registry query. – CODe May 16 '15 at 04:05

1 Answers1

0

Went with my second solution, seems to work just fine for multiple OS versions in multiple scenarios. After more research and little input from others here, not sure there are any other viable solutions available for this problem.

Get the logged on user's SID and access the registry using the HKEY_USERS base key via HKEY_USERS/{SID}/SOFTWARE/Company/Product...

CODe
  • 2,253
  • 6
  • 36
  • 65