Jenkins Powerhell plugin runs 32 bit Powershell and I need 64bit

Question

I am new to Jenkins PowerShell integration, and my scripts will not run because (I believe) I need PowerShell to run on a 64-bit version. Duration:

[Environment]::Is64BitProcess 

in my execution sequence gives false , and then the cmdlet that I use ( Get-WindowsFeature ) is shown as not recognized as a cmdlet, etc. Any way to execute 64-bit powershell scripts? Thanks!

Answer 1

Environment

• Jenkins on Windows (mine works as a service)
• plus a Powershell plugin (for running Powershell scripts as "build steps")

Jenkins usually calls the correct version of powershell.exe . However, the executor / slave process must run on a 64-bit JRE so that PowerShell can also work in 64-bit mode.

A simple tester project with the following Powershell script can show the 32-bit and 64-bit nature described above:

 $env:Path # Path will have the right Powershell available [intptr]::size # outputs: 4 = 32-bit, 8 = 64-bit Stop-WebAppPool FOOBAR # fails when 32-bit, succeeds when 64-bit 

An example of output to the console (additional empty lines for clarity):

 [Powershell Test] $ powershell.exe -NonInteractive -ExecutionPolicy ByPass "& 'C:\Windows\TEMP\hudson123456789.ps1'" C:\Windows\system32;C:\Windows;C:\Windows\System32\WindowsPowerShell\v1.0\ 4 Stop-WebAppPool : Retrieving the COM class factory for component with CLSID {688EEEE5-6A7E-422F-B2E1-6AF00DC944A6} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)). At C:\Windows\TEMP\hudson123456789.ps1:7 char:1 

---

Decision

tl; dr ... Install the 64-bit JRE and configure Jenkins to the 64-bit version.

I used chocolatey to install a pretty fresh JRE through PowerShell "Administrator":

First, install Chocolatey:

 iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1')) 

Search for the latest available version https://chocolatey.org/packages?q=java (Chocolatey has several packages for the same thing, often not fully updated).

Then install the JRE (using the one with the larger number of JREs):

 choco install -y javaruntime 

Or:

 choco install -y jre8 

Finally, I edited my jenkins.xml configuration jenkins.xml that it works using the 64-bit JRE instead of the built-in JRE.

Modified by:

 <executable>%BASE%\jre\bin\java</executable> 

To ( specify the path corresponding to your instance ):

 <executable>C:\Program Files\Java\jre1.8.0_66\bin\java</executable> 

This should be an “always fresh” symbolic link (processed by system updates), which should allow your Jenkins instance to survive Restart and update events :

 <executable>C:\ProgramData\Oracle\Java\javapath\java.exe</executable> 

Then I restarted Jenkins. Powershell execution woke up to 64-bit power. Note : I use one instance of Jenkins, which performs a dual function as a “server” and a “slave executor” at the same time. For fully autonomous subordinates, I would suggest that the implementation of any actions to transfer the processes of slave agents to 64-bit mode would lead to similar success.

Full automation? According to the documentation for the jre8 package using command line switches, you can even force fixed destination paths for the JRE and exclude 32-bit and / or 64-bit editions if fully automated non-interactive steps are required. https://chocolatey.org/packages/jre8

Answer 2

I am not familiar with Jenkins, but it looks like this is a 32-bit process.

Can you specify the location of the PowerShell executable? If so, try using this path: C:\Windows\SysNative\WindowsPowerShell\v1.0\powershell.exe

If you cannot do this, you can do this in code in your "execution sequence" using Invoke-Command :

 Invoke-Command -ComputerName . -ScriptBlock { [Environment]::Is64BitProcess } 

All code in the script block will be run in a separate 64-bit process, and the results will be serialized and returned.

Explanation

Tracks

On 32-bit Windows, the system folder is C:\Windows\System32 . On 64-bit Windows, the 64-bit system folder also has C:\Windows\System32 . But the system folder for 32-bit processes when installing 64-bit Windows is actually C:\Windows\SysWOW64 .

For compatibility, a 32-bit process in a 64-bit OS will have any calls to C:\Windows\System32 transparently redirected to C:\Windows\SysWOW64 , without the knowledge of the process.

To enable a 32-bit process for referencing a real System32 on a 64-bit OS, you can use C:\Windows\SysNative .

Since PowerShell has a 32-bit and a 64-bit version and lives inside system folders, you need to use the above rules to refer to the correct executable, depending on whether you call it from a 64-bit or 32-bit process.

A typical scenario (you want to name the version of the same bitness) is easiest (just call powershell.exe or specify it through System32 ), but it gets hairy if you want to reference another version.

Invoke-Command Method

The Invoke-Command cmdlet allows you to run code, usually on another computer, but you can run it on the same computer. This will trigger a completely separate process, and any output will be serialized and sent back to the calling process.

The caveat to this method is that you must enable PowerShell remoting on the machine using Enable-PSRemoting or Group Policy (shameless startup).

The default profile ( Microsoft.PowerShell ) that you connect to on a 64-bit machine will be the 64-bit version of PowerShell, regardless of the OS of the caller.

By the way, if you want to use Invoke-Command to connect to the 32-bit version, you can do this by explicitly specifying the Microsoft.PowerShell32 profile.

Answer 3

OK, so the answer was pretty simple, but all the time unsuccessfully. Basically, the module did not exist on both Powershell paths (x86 and x64), so copying the modules to the 32-bit powershell environment fixes the problem.

Answer 4

additional offers:

1. check the 32bit-JRE path, delete the path or delete the 32bit-JRE - the path with the 64-bit JRE can also swap
2. check the PowerShell paths, delete the 32-bit PowerShell path (.. \ SysWOW64 \ ..) and add another path (.. \ System32 \ ..)

It worked for me!