PXLabs

Introduction

The Windows Registry is a critical component of the operating system that stores configuration settings, application options, and system parameters. On 64-bit Windows systems, the registry is divided into two views: one for 64-bit applications and another for 32-bit applications. This duality is essential for compatibility but can trip up administrators and scripters who aren’t aware of it.

A common pitfall is hardcoding the Wow6432Node path to access the 32-bit registry view. While this might seem like a shortcut, it introduces fragility, inflexibility, and maintenance challenges. In this post, we’ll explore better, more reliable ways to navigate registry views using PowerShell.

What is Wow6432Node?

The Wow6432Node key exists as part of the WOW64 (Windows on Windows 64) subsystem. WOW64 enables 32-bit applications to run on 64-bit versions of Windows by redirecting certain system operations, including registry access.

When a 32-bit application accesses HKLM\Software, the WOW64 subsystem redirects that call to HKLM\Software\Wow6432Node. This redirection ensures that 32-bit applications do not interfere with 64-bit ones, maintaining compatibility and stability.

While this setup works transparently for compiled applications, manually hardcoding the Wow6432Node path in scripts bypasses the system’s built-in redirection logic and introduces potential issues.

Why You Shouldn’t Hardcode Wow6432Node

Reliability Issues

Hardcoding Wow6432Node creates brittle scripts. If Microsoft changes the WOW64 behavior in future Windows versions, your script may break unexpectedly. And let’s be honest, no one wants a call at 3 AM because of a registry redirection failure.

Inflexibility

Hardcoded paths won’t adapt to 32-bit systems, where Wow6432Node may not even exist, or behave as expected. It’s like showing up to a unicycle race with training wheels. It completely misses the point.

Maintainability

Hardcoding registry paths makes your scripts harder to read, understand, and maintain. Others reviewing your code (or future you) may have trouble determining the intended behavior (and silently curse your name).

Accessing Alternate Registry Views in PowerShell

Using Reg.exe with sysnative and syswow64

You can use the reg.exe utility from different system directories to control which registry view you’re accessing:

• Access 64-bit registry view from 32-bit PowerShell:

& "C:\Windows\sysnative\reg.exe" query HKLM\Software

• Access 32-bit registry view from 64-bit PowerShell:

& "C:\Windows\syswow64\reg.exe" query HKLM\Software

sysnative is a virtual folder that allows 32-bit processes to access 64-bit system files. It’s not a typo; it’s a secret passageway.

Running a 32-bit PowerShell Instance

You can launch a 32-bit PowerShell session on a 64-bit system by running:

C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

In this instance, PowerShell cmdlets like Get-ItemProperty will automatically operate on the 32-bit registry view.

Perfect when you’re trying to see the world through the eyes of a 32-bit app. Not so much if you need to access both 32-bit and 64-bit information.

Using .NET Classes for More Control

For scenarios requiring explicit control over registry views, use the .NET Microsoft.Win32.RegistryKey class. This allows specifying access flags like KEY_WOW64_32KEY and KEY_WOW64_64KEY:

$reg64 = [Microsoft.Win32.RegistryKey]::OpenBaseKey('LocalMachine', 'Registry64')
$subKey64 = $reg64.OpenSubKey('Software\MyApp')
$subKey64.GetValue('SettingName')

$reg32 = [Microsoft.Win32.RegistryKey]::OpenBaseKey('LocalMachine', 'Registry32')
$subKey32 = $reg32.OpenSubKey('Software\MyApp')
$subKey32.GetValue('SettingName')

It’s a bit more verbose but consider it the Swiss Army knife of registry access.

Real-World Example: Enumerating Installed Applications

One common task is listing installed software from the registry. But wait there’s a twist! On a 64-bit OS, you need to check both views to get the full picture.

PowerShell Provider (Matches Session Bitness)

Get-ChildItem 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall' |
  ForEach-Object {
    Get-ItemProperty $_.PsPath | Select-Object DisplayName, DisplayVersion
  }

The above command uses the registry provider and will return results based on the bitness of the session. If you’re in a 32-bit PowerShell process, you’ll see the 32-bit view. If you’re in 64-bit, you’ll see the 64-bit view.

.NET-Based (Explicitly 64-bit View):

$reg64 = [Microsoft.Win32.RegistryKey]::OpenBaseKey('LocalMachine', 'Registry64')
$uninstall = $reg64.OpenSubKey('Software\Microsoft\Windows\CurrentVersion\Uninstall')
$uninstall.GetSubKeyNames() | ForEach-Object {
    $sub = $uninstall.OpenSubKey($_)
    [PSCustomObject]@{
        DisplayName = $sub.GetValue('DisplayName')
        DisplayVersion = $sub.GetValue('DisplayVersion')
    }
}

.NET-Based (Explicitly 32-bit View):

$reg32 = [Microsoft.Win32.RegistryKey]::OpenBaseKey('LocalMachine', 'Registry32')
$uninstall = $reg32.OpenSubKey('Software\Microsoft\Windows\CurrentVersion\Uninstall')
$uninstall.GetSubKeyNames() | ForEach-Object {
    $sub = $uninstall.OpenSubKey($_)
    [PSCustomObject]@{
        DisplayName = $sub.GetValue('DisplayName')
        DisplayVersion = $sub.GetValue('DisplayVersion')
    }
}

The .NET-Based examples explicitly set the registry view, making your script agnostic of the session’s bitness; an important step toward consistency and completeness.

If you’re only checking one view, you’re missing half the guests at the party and that might include the ones who ate all your RAM.

The Limitations of Get-ItemProperty and the Registry:: Provider

The PowerShell registry provider (e.g., HKLM: or Registry::) is convenient, but it does not allow specifying registry view access flags. That means:

• Get-ItemProperty always uses the view of the currently running PowerShell process (32-bit or 64-bit).
• You can’t force it to use KEY_WOW64_32KEY or KEY_WOW64_64KEY.

For scripts that must work across registry views, relying solely on the registry provider is insufficient; unless you enjoy writing incomplete inventory reports and chasing ghost apps.

Summary

Understanding how Windows handles 32-bit and 64-bit registry access is crucial for writing reliable PowerShell scripts. Avoid the temptation to hardcode Wow6432Node. Doing so may lead to brittle and inflexible code.

Instead, use appropriate tools and techniques:

• Use reg.exe from the correct system folder.
• Run the right bitness of PowerShell.
• Use .NET classes for granular control.

These methods will help ensure your scripts are robust, adaptable, and future-proof, and might just earn you a few extra kudos from your fellow admins.

Further Reading

• Windows Registry Provider – Microsoft Learn
• WOW64 Implementation Details – Microsoft Learn
• Microsoft.Win32.RegistryKey Documentation – Microsoft Docs