Hey everyone,
I have a new installation of PSU on Windows Server 2019 Standard. I have some ODBC-Drivers that still run in 32bit, which requires me to launch Powershell in 32bit. But even after putting the direct path to %WINDIR%\SYSWOW64...\powershell.exe, the process is still 64bit. Anybody ever done this successfully?
Thanks in advance!
Did you create a new environment in PSU that specifically uses the 32-bit PowerShell executable, and then set your script/job to use that environment?
Yep, even tried the direct path via C:/WindowsâŚ, %SYSDIR%, and %WINDIR%. I checked via [Environment]::Is64BitOperatingSystem which always returned True. When run in 32bit powershell console it would return False.
I just tested some scenarios and confirm that all of the attempts were in 64-bit PowerShell. Interesting. Have you filed a bug on GitHub yet?
Additonally, I used the command [Diagnostics.Process]::GetCurrentProcess().Path to see the path of the PowerShell instance and it shows C:\Program Files (x86)\Universal\Agents\5.1\Universal.Agent.exe which is strange because the environment for the script is set to the PowerShell 32-Bit environment I created that points to the full path C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
@adam? Is this normal?
Setting the same script to use the external PowerShell 7.5.0 results in C:\Program Files\PowerShell\7\pwsh.exe so it definitely is executing PowerShell directly in that case. Something about running the 32-Bit version seems to cause PSU to âbreakâ.
Hey Jesse,
I have not filed a bug yet, since I was also running into the issue of proxy not working properly for the PSGallery I wanted to make sure it wasnât just issues on my side.
Just checked further and noticed the same for me. Powershell 5 and 7 environment can be switched properly but just something about the direct path seems to break it.
I wanted to check if I can feed it the direct path to a separate pwsh.exe, if itâs maybe an issue with the direct path in general, will check that tomorrow morning.
You could try shelling the powershell.exe by using the Start-Process cmdlet and passing it all of the parameters needed, to see if that yields a better result.
Iâll try that just to verify but Iâd need to run almost all of the script (querying ODBC, manipulating data, writing data) since I canât pass the output back to the 64bit powershell. I saw the environment option and got excited 
Iâm currently using jenkins for powershell automation but am not particularly happy with it. Was hoping to use some of the features of PSU.
I checked a little further:
Running in Integrated Environment:
True
C:\Program Files (x86)\Universal\Universal.Server.exe
Major Minor Patch PreReleaseLabel BuildLabel
----- ----- ----- --------------- ----------
7 5 0
Running in Powershell 7 Environment:
True
C:\Program Files (x86)\Universal\Hosts\7.5\PowerShellUniversal.Host.exe
Major Minor Patch PreReleaseLabel BuildLabel
----- ----- ----- --------------- ----------
7 5 0
Running in Powershell 5.1 Environment:
True
C:\Program Files (x86)\Universal\Hosts\5.1\PowerShellUniversal.Host.exe
Major Minor Build Revision
----- ----- ----- --------
5 1 17763 7009
Running in Custom 32bit Environment (%SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe):
True
C:\Program Files (x86)\Universal\Hosts\5.1\PowerShellUniversal.Host.exe
Major Minor Build Revision
----- ----- ----- --------
5 1 17763 7009
Running in custom 64bit Environment (C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe):
True
C:\Program Files (x86)\Universal\Hosts\5.1\PowerShellUniversal.Host.exe
Major Minor Build Revision
----- ----- ----- --------
5 1 17763 7009
So the environment definitely changes something, it just doesnât properly launch alternative powershell paths.
Starting %SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe (by copying and pasting this in explorer) and running the same commands gives us the following outputs:
PS C:\Windows\system32> [Environment]::Is64BitProcess
False
PS C:\Windows\system32> [Diagnostics.Process]::GetCurrentProcess().Path
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
PS C:\Windows\system32> Write-Output $PSVersionTable.PSVersion
Major Minor Build Revision
----- ----- ----- --------
5 1 17763 7009
This is a limitation in 5.4 and below. The problem is that PSU always uses PowerShellUniversal.Host.exe, built for .NET Framework and it is always x86. Version 5.5 adds support for invoking powershell.exe directly. PSU was having some issues with assemblies but the 5.5 version removes some dependencies that prevent the powershell.exe executable from being used directly from running scripts.
PowerShellUniversal.Host does provide better control over assembly binding since itâs the startup process but does not currently support x86.
Thanks for the clarification.
I installed 5.5.0 last night with two different behaviours:
With Powershell Environment set to %SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe:
Error in PSU:
Error executing job: An error occurred trying to start process '%SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe' with working directory 'C:\ProgramData\UniversalAutomation\Repository'. Das System kann die angegebene Datei nicht finden.
With Powershell Einvornment set directly to C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe:
Powershell Output:
[Information] [3/26/2025 9:16:40 AM] Exception thrown from job entry point.
[Information] [3/26/2025 9:16:40 AM] System.IO.FileNotFoundException: Error loading native library. Not found in any of the possible locations: C:\Program Files (x86)\Universal\Hosts\netstandard2.0\grpc_csharp_ext.x86.dll,C:\Program Files (x86)\Universal\Hosts\netstandard2.0\runtimes/win-x86/native\grpc_csharp_ext.x86.dll,C:\Program Files (x86)\Universal\Hosts\netstandard2.0\../..\runtimes/win-x86/native\grpc_csharp_ext.x86.dll
[Information] [3/26/2025 9:16:40 AM] bei Grpc.Core.Internal.UnmanagedLibrary.FirstValidLibraryPath(String[] libraryPathAlternatives)
[Information] [3/26/2025 9:16:40 AM] bei Grpc.Core.Internal.UnmanagedLibrary..ctor(String[] libraryPathAlternatives)
[Information] [3/26/2025 9:16:40 AM] bei Grpc.Core.Internal.NativeExtension.LoadNativeMethodsUsingExplicitLoad()
[Information] [3/26/2025 9:16:40 AM] bei Grpc.Core.Internal.NativeExtension.LoadNativeMethods()
[Information] [3/26/2025 9:16:40 AM] bei Grpc.Core.Internal.NativeExtension..ctor()
[Information] [3/26/2025 9:16:40 AM] bei Grpc.Core.Internal.NativeExtension.Get()
[Information] [3/26/2025 9:16:40 AM] bei Grpc.Core.GrpcEnvironment.GrpcNativeInit()
[Information] [3/26/2025 9:16:40 AM] bei Grpc.Core.GrpcEnvironment..ctor()
[Information] [3/26/2025 9:16:40 AM] bei Grpc.Core.GrpcEnvironment.AddRef()
[Information] [3/26/2025 9:16:40 AM] bei Grpc.Core.Channel..ctor(String target, ChannelCredentials credentials, IEnumerable`1 options)
[Information] [3/26/2025 9:16:40 AM] bei UniversalAutomation.Host.GrpcProtocol..ctor(Int32 port)
[Information] [3/26/2025 9:16:40 AM] bei UniversalAutomation.Host.EntryPoint.Start(Int32 parentProcessId, Int32 port, Int32 universalPort)
[Information] [3/26/2025 9:16:40 AM] bei UniversalHost.AgentService.StartJob(Int32 port, Int32 parentProcessId, Int32 universalPort, IHostLogger logger)
[Information] [3/26/2025 9:16:41 AM] Ausnahme beim Aufrufen von "StartJob" mit 4 Argument(en): "Error loading native library. Not found in any of the
[Information] [3/26/2025 9:16:41 AM] possible locations: C:\Program Files (x86)\Universal\Hosts\netstandard2.0\grpc_csharp_ext.x86.dll,C:\Program Files
[Information] [3/26/2025 9:16:41 AM] (x86)\Universal\Hosts\netstandard2.0\runtimes/win-x86/native\grpc_csharp_ext.x86.dll,C:\Program Files
[Information] [3/26/2025 9:16:41 AM] (x86)\Universal\Hosts\netstandard2.0\../..\runtimes/win-x86/native\grpc_csharp_ext.x86.dll"
[Information] [3/26/2025 9:16:41 AM] In C:\Program Files (x86)\Universal\UniversalHost.psm1:30 Zeichen:13
[Information] [3/26/2025 9:16:41 AM] + [UniversalHost.AgentService]::StartJob($Port, $ParentProc ...
[Information] [3/26/2025 9:16:41 AM] + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Information] [3/26/2025 9:16:41 AM] + CategoryInfo : NotSpecified: (:) [], MethodInvocationException
[Information] [3/26/2025 9:16:41 AM] + FullyQualifiedErrorId : FileNotFoundException
[Information] [3/26/2025 9:16:41 AM]
Environment settings are complete default, other than the custom path pointing to powershell.exe.