x86 version of OneDS has wrong architecture information in ext_os_ver when running in 64-bit version of Windows

[maosypin]

getOsBuildLabEx() is a method that is used to get the OS version. It uses RegGetValueA() function to access the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\BuildLabEx registry, which contains the os version string.

On my machine, the value of the registry is 17763.1.amd64fre.rs5_release.180914-1434, but when looking at the events sent from Omaha (32-bit installer application) the version differs in the architecture part: 17763.1.x86.rs5_release.180914-1434. It is because the actual registry that is being accessed is HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\BuildLabEx, which is default behavior for RegGetValueA().

[maosypin]

Looking at the documentation for RegGetValueA(), the way to workaround that is to set dwFlags parameter to RRF_SUBKEY_WOW6464KEY.

[maosypin]

This bug is a high priority bug because it affects an important field which is used on the backend.

[maxgolov]

@micasill - Miguel, could you please take a look at this one?

[micasill]

I did some testing for this, as far as I could test using RRF_RT_REG_SZ | RRF_SUBKEY_WOW6464KEY for dwFlags appears to solve this issue.
Please check this PR @maosypin

[bliptec]

RRF_SUBKEY_WOW6464KEY is only available on win10 TH1+, so a different approach should be used to maintain down-level support. May need to follow this guidance to open the registry with a different view: https://docs.microsoft.com/en-us/windows/win32/winprog64/accessing-an-alternate-registry-view?redirectedfrom=MSDN

@maxgolov suggested maybe using IsWow64Process, but there's concerns about that working properly on new platforms, specifically ARM.

For now, we worked around this on Edge by doing

#ifndef RRF_SUBKEY_WOW6464KEY
#define RRF_SUBKEY_WOW6464KEY  0x00010000
#endif

but there are concerns about this not behaving properly due to not being supported (although current behavior is still better than pre-fix)

@maosypin FYI