RegistryGet not finding entries due to VirtualStore on Windows 10



I'm struggling to find consistencies across platforms due to registry virtualization.  When running through my PB 2017 IDE, the following code works, but when I compile as 32bit or 64bit app, and run the exe, it does not find the product code.

RegistryGet(HKEY_LOCAL_MACHINE\Software\WOW6432Node\Min-U-Script Pro", "Product Code", RegString!, gs_product_code)

Additionally, when I look at the registry, the path looks completely different:

Computer\HKEY_USERS\S-1-5-21-1312213260-3357453489-502601113-1001\Software\Classes\VirtualStore\MACHINE\SOFTWARE\WOW6432Node\Min-U-Script Pro

Please help with a registry strategy which will work across platforms.



Question Tags: 


Marco Meoni answered RegistryGet not finding entries due to VirtualStore on Windows 10


Hi Mitch,
that is the correct behavior and it happens because you have insufficient privileges to write directly to HKLM. It's called virtualization. You should keep things as they are and write/read from the same HKLM key you are writing to, Windows will transparently redirect for you.
As a background info, HKU contains user-specific configuration information for all logged users and the sequence of dash-separated numbers corresponds to that user SID. The key you wrote gets there because virtualization (google for Windows virtualization).
In essence, 32bit apps (like the PB IDE) will transparently access the appropriate 32bit registry hive, as well as the 64bit will. But you must be explicit when use an application of a different bitness and want to modify the registry (but you should have serious reasons for doing that).

For the sake of completeness, if you actually want to manage 64bit registry from PB, you can declare native RegOpenKeyEx API as local external function and access explicitly the WOW64, see for instance this link:

Marco's picture

Thanks for the quick response.  I did some more testing.  Still issues with permissions at runtime.  From the IDE this works.  It writes to the registry and then I can read it back.

li_ret=RegistrySet(gs_regpath + "\Min-U-Script", "regtest", RegString!, "test " + string(now(),"hh:mm"))
li_ret=RegistryGet(gs_regpath + "\Min-U-Script", "regtest", RegString!, ls_regtest)

When I run this from the exe, it fails.  I get a -1 returned.  If I run my exe as administrator, then it writes and reads.  If I then run again, not as administrator, then it only reads, but fails on the write.  So can I no longer write to the registry when not running as administrator?  Additionally, it does not seem to matter if I have the path as:







Olan Knight's picture

Mitch -
   That is correct; you must have ADMIN rights in order to write directly to the non-virtual sections of the Windows Registry.