Access the correct registry entries from IPNetwork Monitor
Accessing the Windows registry (local or remote) is a typical way of gathering useful data. However, there is a common pitfall that can cause scripts or programs to behave unexpectedly: accessing registry values across different architectures, for example, 64-bit entries from a 32-bit application.
On 64-bit Windows, the WOW64 subsystem allows 32-bit applications to run on a 64-bit OS. One consequence is the registry redirector, which provides separate logical registry views for 32-bit and 64-bit applications. Unless an application explicitly requests a different view, it will normally access the registry view that matches its own architecture.
An example: checking “reboot required” state
Checking whether Windows requires a restart can involve verifying the existence of one or more registry keys, for example under “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update”. Typically, a “Script or Program” monitor can be used for that. If the target OS is 64-bit and the monitoring process is running as a 32-bit application, the situation below can occur.
When the check is performed from a native 64-bit host process (for example, 64-bit PowerShell or 64-bit Windows Script Host), it addresses the 64-bit registry view and may return the information we expect.
When the same logic is run from a 32-bit process, the call can be transparently redirected to the 32-bit registry view under “HKLM\SOFTWARE\WOW6432Node\…”. As a result, a script that appears to work correctly from one host process may return different results when run from IPNetwork Monitor.
If such a script behaves differently between a native command-line session and IPNetwork Monitor, first verify which registry view each process is actually accessing. In many cases, the script is not failing at all — it is simply reading a different registry view.
Quick solution
A simple workaround is to specify the exact target registry view or provider architecture explicitly, to avoid the silent redirection described above.
For example, if VBScript is used to access the remote registry through WMI, code like the 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
' Optional: force WMI to use the requested provider or fail explicitly
objCtx.Add "__RequiredArchitecture", TRUE
' 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 and the same script can work against different target OS architectures. Similar issues can also appear in .NET-based tools, where it is better to request Registry32 or Registry64 explicitly instead of assuming the default view.
Have you encountered such a problem? Could you offer another example of architecture-depending issues? Feel free to contact us.