Have recently had a problem when I had to read and write 64-bit registry. One scenario I had was that we wanted to create a unique key under HKEY_LOCAL_MACHINE \ Software \ and then via GPO and a VMI filter, turn off offline folders about who logged in was who was managedBy in Active Directory. The WMI filter runs as 64-bit but the script that created the keys in the registry went as 32-bit.
I had to create and read 64-bit registry but the program was run in 32-bit and then you can not normally read / write in 64-bit registry. After some research online, I realized that I can solve this via VMI. Using the StdRegProv class containing methods that you can manipulate the system registry keys and values. StdRegProv is too installed in WMI namespaces root \ default and root \ cimv2.
Worth noting is that the X64 version of Windows can not run correctly 32-bit code. Since most programs are 32-bit, the x64 version of Windows will use emulator called WOW64, to allow 32-bit applications to run. One of the problems of running 32-bit code on a 64-bit operating system is that the OS should maintain full code separation. Microsoft has created a new folder named \ Windows \ SysWOW64 that is used to store 32-bit DLL files. In the 32-bit version of Windows, DLL files are normally stored in the \ windows \ system32 folder. However, the x64 version of Windows uses the \ Windows \ System32 folder folder for 64-bit DLL files.
By default, a program or script gets data from the corresponding provider when there are two versions of the provider. 32-bit provider returns data to a 32-bit application, including all scripts, and 64-bit provider returns data to 64-bit compiled applications. However, a program or script may request non-standard provider data, if available, by notifying WMI through methodological flags.
By using the __ProviderArchitecture flag, you can request access to 32-bit records in a 64-bit computer. The caller connects to 32-bit hive, whether it’s a 32- or 64-bit program.
The problem I received was that I could not access a 64-bit registry value when the script I was running was executed as 32-bit via the sccm client. But using __ProviderArchitecture and StdRegProv I came around this.
Naturally, one can reverse and read and write the 32-bit registry from a 64-bit session.