Address correct registry entries from IPHost

Accessing Windows registry (local or remote) is a typical way of gathering useful data. However, there’s a typical pitfall that can cause unexpected scripts or programs behavior. Namely, accessing registry values across different architectures (say, 64-bit entries from 32-bit applications).

On 64-bit Windows, there’s so called WOW64, subsystem created to run 32-bit applications out of 64-bit OS. Among other features, WOW64 can interfere when application attempts to access registry. So called registry redirector replaces certain registry branches with logical views. Unless the application explicitly states which registry branch (“hive”) to access, it will be given access matching its architecture.

An example: checking “reboot required” state

To check whether Windows requires restart can be done by verifying existence of several registry keys, e.g. “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update”. Typically, “Script or Program” monitor type can be used. If both target OS and the one running IPHost are both 64-bit ones, the below can happen.

When check is performed from command line (by running VBScript or PowerShell etc scripts), it uses native (64-bit) applications, which do address corresponding (64-bit) registry hive, thus extracting the very information we look for.

When the same script is run out of IPHost (which is 32-bit application), the actual registry path becomes “HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update”, which isn’t containing the keys we look for. Thus the script, which worked fine under 32-bit OS, stops working.

If such a script behaves differently from native command-line and from IPHost, perhaps the script is just silently accessing different registry areas.

Quick solution

Simple workaround is to specify the exact target hive architecture, to avoid silent redirections mentioned above.

For example, if VBScript is used to access remote registry, then the code like below can be used:

Set objSWbemLocator = CreateObject("WbemScripting.SWbemLocator")
' Create value set to pass architecture option
Set objCtx = CreateObject("WbemScripting.SWbemNamedValueSet")
objCtx.Add "__ProviderArchitecture", 64
' Connect to remote and specify the target architecture explicitly
Set objWMIService = objSWbemLocator.ConnectServer(strComputer, "Root\DEFAULT", strDomain & "\" & strUsername, strPassword,,,,objCtx)

The integer value (64 in the above case) specifies the architecture. It can be obtained by querying Win32_OperatingSystem class, thus the actual target architecture can be set up automatically, the same script would work against any target OS architecture.

Have you encountered such a problem? Could you offer another example of architecture-depending issues? Feel free to contact us or leave a comment below.