32-bit vs 64-bit WMI Registry Calls (StdRegProv)

NOTES

• This article is mainly aimed at VBScript. PowerShell may have the same challenges
• This article uses registry locations/values for an application and not a Microsoft-supplied registry locations/values. This is because Microsoft appears to have copied all of their registry locations/values to both 32-bit and 64-bit registry locations.

Using the StdRegProv class to manipulate registry information is common among many system administrators. The addition of new architectures, such as 64-bit, introduces the need to evaluate past coding models.

A base connection to the StdRegProv class only connects to the architecture from which its being called. Without specifying the connection architecture, values are read/written based on the architecture calling the StdRegProv.

• Using the StdRegProv class, without specifying the connection architecture, to make a remote registry call using a 32-bit shell will only have access to 32-bit registry information.
• Using the StdRegProv class, without specifying the connection architecture, to make a remote registry call using a 64-bit shell will only have access to 64-bit registry information.
• Using the StdRegProv class with specifying the connection architecture, to make a remote registry call using a 32-bit or 64-bit shell will have access to the architecture specified by the connection.

A WMI registry call using the StdRegProv class without specifying the connection architecture would look like this:
A WMI registry call using the StdRegProv class with specifying the connection architecture would look like this:

Secure Information Storage

My suggestion for centralized password management can stores passwords, credit card information, secure notes, etc.

LastPass

Why are 32-bit shortcuts needed on 64-bit systems?

A 64-bit system normally contains shortcuts to 64-bit versions of operating system applications, such as cmd.exe, odbcad32.exe, wscript.exe, cscript.exe, etc. Creating shortcuts to 32-bit versions of these same applications may be necessary in order to access objects, such as 32-bit ODBC drivers.

As an example, running the 64-bit version of odbcad32.exe (located in system32) will show 64-bit version ODBC drivers, but not 32-bit. Running the 32-bit version of odbcad32.exe (located in syswow64) will show 32-bit version ODBC drivers, but not 64-bit.

Running a script, such as VBScript that utilizes 32-bit ODBC drivers, from a 64-bit version of cmd.exe (located in system32) may fail because of it inability to access 32-bit ODBC drivers. The same script will run successfully using the 32-bit version of cmd.exe.

Threat Protection

My suggestion for non-managed threat protection that is feature rich and has a free version for home use.

Comodo Internet Security