Strange Behavior with PROCESSOR_ARCHITECTURE environment variable

[KZeronimo]

Checklist

• I have verified this is the correct repository for opening this issue.
• I have verified no other issues exist related to my problem.
• I have verified this is not an issue for a specific package.
• I have verified this issue is not security related.

What You Are Seeing?

I'm adding some processor-specific deployment steps to my packages, and I have planned to use $env:PROCESSOR_ARCHITECTURE to accomplish this.

Via a PowerShell Shell or the Boxstarter Shell $env:PROCESSOR_ARCHITECTURE returns the expected response (in my case ARM64)

When I do either of the following

START https://boxstarter.org/package/nr/url?https://gist.githubusercontent.com/KZeronimo/74c9146169ef05da0d264014be7c2084/raw/package-test.ps1

or

$(. Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://boxstarter.org/bootstrapper.ps1')); $?) -and $(Get-Boxstarter -Force | Out-Host; $?) -and $(Install-BoxstarterPackage -PackageName 'https://gist.githubusercontent.com/KZeronimo/74c9146169ef05da0d264014be7c2084/raw/package-test.ps1' -DisableReboots | Out-Host; $?)

The reported processor architecture is AMD64

What is Expected?

$env:PROCESSOR_ARCHITECTURE should report the correct processor architecture when used in a Boxstarter package deployment

To be clear I'm not sure if this is a Boxstarter or Chocolatey issue.

How Did You Get This To Happen?

1. Install a fresh copy of Windows 11 Professional on an ARM64-based device
2. Proceed with either "single line" package install method listed above

System Details

• Operating System: 10.0.22621.0, Windows 11 22H2 Build 22621.1344
• Windows PowerShell version: 5.1.22621.963
• Chocolatey CLI Version: 1.3.1
• Chocolatey Licensed Extension version: Chocolatey v1.3.1 (no packages installed)
• Chocolatey License type: Open Source
• Terminal/Emulator: Windows PowerShell

Installed Packages

Boxstarter 3.0.0
Boxstarter.Bootstrapper 3.0.0
Boxstarter.Chocolatey 3.0.0
Boxstarter.Common 3.0.0
Boxstarter.HyperV 3.0.0
Boxstarter.WinConfig 3.0.0
chocolatey 1.3.1

Output Log

[Log](https://gist.github.com/KZeronimo/8c75223cd2dc91207941533cc83d8f4c)

Additional Context

No response

[KZeronimo]

Quick update - I tested the following (Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Session Manager\Environment').PROCESSOR_ARCHITECTURE and am able to accomplish what I want

Please don't burn anytime on this issue - this is now for my understanding of what is happening.

[pauby]

There is nothing in this to confirm it is a Boxstarter issue. Can you test this via Chocolatey and see if it produced the same result?

[KZeronimo]

Hi @pauby - agreed and mentioned the same in the initial issue writeup irt Boxstarter v Chocolatey issue

What is the best way to test "with just chocolatey" and remove the usage of Install-BoxstarterPackage

[corbob]

This to me is the expected behaviour, and is likely coming from Chocolatey. The reason this is expected to me is that Chocolatey is compiled for all processors on .Net Framework. Unless it were to be built with 4.8.1, it wouldn't know about ARM64, so it'll be run in AMD64 emulation. Much like if it were compiled for 32 bit architectures, then it would show x86 in that variable (or alternatively if it's launched from a 32 bit context).

Microsoft has released 4.8.1 with support for ARM64, but given that it never shows as the recommended build for me, I'm not sure how prevalent it is, or if merely installing it would be enough to change this behaviour.

As for how to verify if this is Chocolatey or Boxstarter @KZeronimo you might try running the following in an administrative PowerShell (note: this is off the top of my head, so commands may not be exactly as described):

choco new testpackage --version 0.1.0
remove-item testpackage/tools/*
'Write-Host "We are using Processor: $env:PROCESSOR_ARCHITECTURE"' | Out-File testpackage/tools/chocolateyinstall.ps1
choco pack testpackage/testpackage.nuspec
choco install testpackage --source .

[KZeronimo]

Thank you @corbob for the explanation and the example. Results confirm the source of this behavior is from Chocolately.

Would you recommend pushing this as an issue into Chocolatey issue list?

[corbob]

Thanks for confirming that @KZeronimo. I would be curious if the behaviour is the same on the latest Alpha version of Chocolatey, but would only suggest running it on a non-production system.

As for if we should log it on the Chocolatey CLI repository, I will leave it up to @pauby to either move and reopen this issue, or open one over there if that's desired.