[Solved] Registry Virtualization/Redirection - bug in AutoIt?

[Zedna]

According to these oficial information about Registry Virtualization/Redirection

https://docs.microsoft.com/en-us/windows/win32/sysinfo/registry-virtualization

https://docs.microsoft.com/en-us/windows/win32/sysinfo/32-bit-and-64-bit-application-data-in-the-registry

I can see some problematic behaviour of AutoIt's Registry functions RegEnumKey/RegRead, they seem to be NOT complementary with above definition of virtualization.

 

I use AutoIt for automatize application which stores its setup to the registry by RegWrite (not in AutoIt) to key 'HKEY_LOCAL_MACHINE\SOFTWARE\AppName'

When this is called with non admin user then it's automatically written to 'HKEY_CURRENT_USER\SOFTWARE\Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node\AppName'

so there are some options stored in HKLM and some other in HKCU.

And when that non-AutoIt application reads its setup it uses only RegRead with key HKLM (RegRead function) and ALL values are get (transparently by OS) by this 1 call - from HKLM + HKCU

 

But when I use AutoIt's RegEnumKey/RegRead to read the same values from HKLM then there are missing values stored in virtualised HKCU.

So I think that in AutoIt's implementation of RegEnumKey/RegRead there is some bug avoiding transparent functionality of OS (Windows) returning also values from virtualised location in HKCU registry.

 

Here is small approximate testing script, that should be running once normally and once "as Administrator" to see differences:

$reg_key1 = 'HKEY_LOCAL_MACHINE\SOFTWARE\Zedna'
; ? in fact : HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Zedna
RegWrite($reg_key1, 'Option1', 'REG_SZ', 'Value1')

; when run NOT "as Administrator" then returns nothing which is bug?
$value = RegRead($reg_key1, 'Option1')
MsgBox(0, 'Registry HKLM Option1', $value)

$reg_key2 = 'HKEY_CURRENT_USER\SOFTWARE\Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node\Zedna'

$value = RegRead($reg_key2, 'Option1')
MsgBox(0, 'Registry HKCU Option1', $value)

Tested on AutoIt 3.2.12.1 and 3.3.14.5 on Windows 10 (64bit) with the same (bad) result.

EDIT: Also with explicit directive for 32bit compiling (not 64bit) it's the same:

#AutoIt3Wrapper_UseX64=n

 

Please can somebody confirm this?

Is this really some bug in AutoIt?

Edited August 18, 2020 by Zedna

[Danyfirex]

Hello. It's not a a bug. 

In the "Registry Virtualization Scope"->"Registry virtualization is disabled for the following:" section says:

Processes that have requestedExecutionLevel specified in their manifests.

So for that reason You don't get the virtualization Enabled.

If you run from Scite It will not work at least you edit the AutoIt.exe executable and remove "requestedExecutionLevel" line from manifest.

If You run compiling your .au3 just add #AutoIt3Wrapper_res_requestedExecutionLevel=None on the top of your script and build it.

Saludos

PD: took me about 20 minutes to get loaded the input for write the message due to my internet speed. 😭

[Danyfirex]

Hello. It's not a a bug. 

In the "Registry Virtualization Scope"->"Registry virtualization is disabled for the following:" section says:

Processes that have requestedExecutionLevel specified in their manifests.

So for that reason You don't get the virtualization Enabled.

If you run from Scite It will not work at least you edit the AutoIt.exe executable and remove "requestedExecutionLevel" line from manifest.

If You run compiling your .au3 just add #AutoIt3Wrapper_res_requestedExecutionLevel=None on the top of your script and build it.

Saludos

PD: took me about 20 minutes to get loaded the input for write the message due to my internet speed. 😭

[Zedna]

Thank you Danyfirex! 👍

I will do investigating and later I will post here results ...

 

 

EDIT:

Yes. You are right.  

Default manifest's ExecLevel is "asInvoker" (I expected none) and after adding pragma compile level=none it works like it should work.

 

Directive for old AutoIt's versions:

#AutoIt3Wrapper_res_requestedExecutionLevel=None

Directive for new AutoIt's versions:

#pragma compile(ExecLevel, none)

 

Edited August 18, 2020 by Zedna