The Sysnative 64 bit Witch Project

Though it may seem dated, ensuring that 64-bit registry keys are appropriately configured is still crucial when deploying Win32 apps. This step is often required before the application can be successfully installed. To address this, using the sysnative path can be important for accessing the correct system directories on 64-bit systems. In this blog, I will first show you the differences between data stored on a 64-bit device and then explain why deploying or reading a 64-bit registry change in a Win32 app could cause issues.

1. Differences

Before I show you the differences between 64 and 32 bits, we need to know what WoW64 means. You could get confused about the name itself if you don’t know what WoW64 means! For example, 32-bit apps access their files from the SysWoW64 folder…Is this folder the 64-bit folder? Let me explain.

WoW64 (Windows 32-bit on Windows 64-bit) is a subsystem of the Windows operating system that can run 32-bit applications on 64-bit Windows. It is included in all 64-bit versions of Windows.

Program files:

On a 64-bit computer, 64-bit programs store their files in C:\Program Files, 32-bit programs store their files in C:\Program Files (x86).

Windows Folder:

On a 64-bit computer, if a 64 bits program wants to access the system-wide folder it opens the c:\windows\system32 folder, if a 32 bits program wants to access the system-wide folder it will be redirected to C:\Windows\SysWOW64.

Registry:

On a 64-bit computer, if we write a registry key from a 64 bits process it will be stored in the HKEY_LOCAL_MACHINE\SOFTWARE, if we write a registry key from a 32-bits process  it will be  redirected to the HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node

Now we know some differences, I will give you an example:

If you install a 32-bit application on a 64-bit version of Windows and it tries to write to the C:\Program Files folder, WoW64 points it at C:\Program Files (x86). If it wants to access the C:\Windows\System32 folder, WoW64 points it at C:\Windows\SysWOW64.  This process is automatic and is done by a build-in file system redirect

Sysnative:

Sysnative is a virtual folder/alias, that can be used to access the 64-bit System32 folder from a 32-bit application or script.

For example, You could access this 64 bits folder from a 32 bits program like CMD (c:\windows\syswow64\cmd.exe)

2. Win32 App Registry Change

If you want to deploy an application that requires a license server, you will need to define one before installing the client app itself. 

Creating a custom-made Win32 app would be the best solution. Create a new folder and place your client MSI installation file in it and a PowerShell script to deploy the register setting and start the MSI client installation:

$flexreg = (Get-ItemProperty "HKLM:\Software\FLEXlm License Manager").SW_D_LICENSE_FILE
#Start-Process -Wait -NoNewWindow "msiexec" -ArgumentList "/i","$pwd\DraftSight.msi","/qb","LICENSETYPE=3"
if (!$flexreg) {
    New-Item -Path "HKLM:\Software" -Name "FLEXlm License Manager" -Force
    New-ItemProperty "HKLM:\Software\FLEXlm License Manager" -Name "SW_D_LICENSE_FILE" -Value 'portnr@servername' -PropertyType STRING -Force
} elseif ($flexreg -like '*portnr@servername*') {
Exit
} else  {
    New-ItemProperty "HKLM:\Software\FLEXlm License Manager" -Name "SW_D_LICENSE_FILE" -Value $flexreg';portnr@servername' -PropertyType STRING -Force

But now comes the trouble: When deploying this registry setting, the registry key will be created inside the wow6432node when you use a Win32App.

The Microsoft Intune Management Extension is responsible for deploying the Win32 app. Considering the differences between 64 and 32 bits, take a look at where the extension is installed.  

As shown above, it is installed in the c:\program files (x86) folder and what did we learn about this folder? So by default behavior (when you did not change anything), Intune will trigger the Win32 app installation in a 32-bit process context and as I told you earlier, the key will be created in the wow6432node.

Luckily (or maybe not), this 64 vs. 32-bit issue could affect the outcome when you deploy a Win32 app and Device Query a bit. In the blog below I stumbled upon the fact that Intune Pivot (DeviceQuery) also tries to find the registry values in the wrong registry key.

https://call4cloud.nl/2024/02/device-query-dead-of-64-bits

3. 64 vs. 32 and Synative

So, what options do we have to change this weird behavior? Should we ask the Sysnative Witch to fix it?Or will we alter some PowerShell scripts and maybe add some .NET functionality to them? Here are some options we have to deal with the 64/32 bits issue!

Option 1:

This option is probably one of the coolest. Let me tell you why and how it could give you way more functionality.

As mentioned in the above Microsoft link, the RegistryKey class in the Microsoft.Win32 namespace is part of the .NET Framework. It provides a nice way to interact with the Windows Registry and allows us to deal with 64 and 32-bit keys.

-We could use Registry64 when working with 64-bit registry locations.

-We could use Registry32 when interacting with the 32-bit registry view.

The best thing about using a .NET approach is that it works in both ways. We could run it from an X64 PowerShell session or from a x86 based PowerShell session.

We could run something like this to determine if we have a 32-bit or 64-bit registry key in our system. The same idea but with a couple of “if” and “else” added to it

# 64-bit view
$key64 = [Microsoft.Win32.RegistryKey]::OpenBaseKey([Microsoft.Win32.RegistryHive]::LocalMachine, [Microsoft.Win32.RegistryView]::Registry64)
$subKey64 = $key64.OpenSubKey("SOFTWARE\Microsoft\Office\ClickToRun\Configuration")

# Check if the key is present in the 64-bit view
if ($subKey64 -ne $null) {
    $regkey_value64 = $subKey64.GetValue("Platform")
    Write-Host "Value in 64-bit view: $regkey_value64"
} else {
    Write-Host "Key not found in 64-bit view"
}

# 32-bit view
$key32 = [Microsoft.Win32.RegistryKey]::OpenBaseKey([Microsoft.Win32.RegistryHive]::LocalMachine, [Microsoft.Win32.RegistryView]::Registry32)
$subKey32 = $key32.OpenSubKey("Software\Microsoft\Office\ClickToRun\Configuration")

# Check if the key is present in the 32-bit view
if ($subKey32 -ne $null) {
    $regkey_value32 = $subKey32.GetValue("Platform")
    Write-Host "Value in 32-bit view: $regkey_value32"
} else {
    Write-Host "Key not found in 32-bit view"
}

Besides trying to Get the proper registry value (32 bits or 64 bits) we could also Set the value in both places just by specifying the Registry32 or Registry64 switch.

$key = [Microsoft.Win32.RegistryKey]::OpenBaseKey([Microsoft.Win32.RegistryHive]::LocalMachine, [Microsoft.Win32.RegistryView]::Registry32)
$subKey = $key.OpenSubKey("Software\Microsoft\Office\ClickToRun\Configuration", $true)  # Note the $true parameter to make the key writable
$subKey.SetValue("Platform", "NewValue", [Microsoft.Win32.RegistryValueKind]::String)  # Use the correct RegistryValueKind for a string value. Dword Or String
$regkey_value = $subKey.GetValue("Platform")
$regkey_value

$key = [Microsoft.Win32.RegistryKey]::OpenBaseKey([Microsoft.Win32.RegistryHive]::LocalMachine, [Microsoft.Win32.RegistryView]::Registry64)
$subKey = $key.OpenSubKey("Software\Microsoft\Office\ClickToRun\Configuration", $true)  # Note the $true parameter to make the key writable
$subKey.SetValue("Platform", "NewValue", [Microsoft.Win32.RegistryValueKind]::String)  # Use the correct RegistryValueKind for a string value. Dword Or String
$regkey_value = $subKey.GetValue("Platform")
$regkey_value

As shown above, remember to add the $true while opening the subkey; otherwise, the registry key is NOT writable!

Option 2:

When we are deploying a Win32 App and want to add the registry value, we could, Instead of specifying the regular install command as shown below

We could specify the “CMD sysnative path”. The sysnative path is used to access the 64-bit system directory (System32) from a 32-bit process (In this example The 32-bit Intune Management Extension)

You could also use the sysnative path when you need to install Printer Drivers using a Win32 app.

Deploy Intune Printer Drivers | PnPutil | Printbrm | PrnDrvr (call4cloud.nl)

Option 3:

We have some options left. This option is a little different and uses a different approach. I found no documentation proving this is a proper solution, but who cares? It works…

It would be best if you created a Powershell script, in this script, you will need to define an additional PowerShell script, which needs to be transferred to the disk and you will need to configure a system task to run the additional PowerShell script. The scheduled task would run the script in the 64-bit context.

Another option would be to create the additional PowerShell script itself and make sure you attach it to the intunewin file.

$content = @'
$flexreg = (Get-ItemProperty "HKLM:\Software\FLEXlm License Manager").SW_D_LICENSE_FILE
#Start-Process -Wait -NoNewWindow "msiexec" -ArgumentList "/i","$pwd\DraftSight.msi","/qb","LICENSETYPE=3"
if (!$flexreg) {
    New-Item -Path "HKLM:\Software" -Name "FLEXlm License Manager" -Force
    New-ItemProperty "HKLM:\Software\FLEXlm License Manager" -Name "SW_D_LICENSE_FILE" -Value 'portnr@servername' -PropertyType STRING -Force
} elseif ($flexreg -like '*portnr@servername*') {
Exit
} else  {
    New-ItemProperty "HKLM:\Software\FLEXlm License Manager" -Name "SW_D_LICENSE_FILE" -Value $flexreg';portnr@servername' -PropertyType STRING -Force
}'@

Out-File -FilePath $(Join-Path $env:ProgramData CustomScripts\test.ps1) -Encoding unicode -Force -InputObject $content -Confirm:$false

# register script as scheduled task
$Time = New-ScheduledTaskTrigger -AtLogOn
$User = "SYSTEM"
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ex bypass -file `"C:\ProgramData\CustomScripts\test.ps1`" -Verb RunAs"
Register-ScheduledTask -TaskName "test" -Trigger $Time -User $User -Action $Action -Force
Start-ScheduledTask -TaskName "test"

Option 4:

This option may be one of the most commonly used ones.  When you add this script to the top of your own PowerShell script, the script host will rerun the PowerShell script, but this time in the 64 bits context

If ($ENV:PROCESSOR_ARCHITEW6432 -eq "AMD64") {
    Try {
        &"$ENV:WINDIR\SysNative\WindowsPowershell\v1.0\PowerShell.exe" -File $PSCOMMANDPATH
    }
    Catch {
        Throw "Failed to start $PSCOMMANDPATH"
    }
    Exit
}

Some explanation about the script: 
This PowerShell script checks if the environment variable $ENV:PROCESSOR_ARCHITEW6432 equals "AMD64", which indicates that a 32-bit process is running on a 64-bit Windows system. If true, it attempts to restart the script using the 64-bit version of PowerShell (SysNative\WindowsPowershell\v1.0\PowerShell.exe) by executing the current script ($PSCOMMANDPATH) in a 64-bit context. If the attempt fails, it throws an error. Finally, the script exits to prevent further execution in the 32-bit process.This approach ensures the script runs in a 64-bit environment if required.

As shown below, when we use this option, we will notice that it now deploys the registry key to the proper path, NOT the wow6432node registry key!

Conclusion:

It is crucial to know the differences between 64 and 32 bits and how they can work together, in my opinion. Hopefully, this blog showed you how to deal with some of the challenges you could encounter when deploying a Win32app, and you need to Get or Set a 64-bit registry key!