Closed rdebath closed 6 months ago
The module is there - but for some reason, your session is looking for the en-GB version:
The module is there in en-US.
What does this return in your container:
Both in BC23 and BC24?
and what does this return:
both in BC23 and BC24?
I have earlier seen people having issues with culture - let's see if we can fix this now
if you add -locale 'en-US' when starting the container - does it work then?
Similar problem here, it is expecting a de-DE folder in the Powershell Module. Not sure I can confirm the observations mentioned, it seems to work fine on Windows 11 with BcContainerHelper 6.0.16. On our agents (Server 2022), however, it has been throwing that error during compilation recently.
Edit: Can confirm it works on 6.0.15
I think I have found the root cause.
It seems like this fix (https://github.com/PowerShell/Microsoft.PowerShell.Archive/pull/46) never made it into the Windows Containers - even though it is 7 years old...
Now, the reason why 6.0.15 (and earlier versions) have worked is that they don't use a configurationName when creating a PowerShell session to the container. That however means that it cannot create a PS7 session - only a PS5 session. Now, I am using a configurationName, which causes the UI culture to be different. Looking at #3330 - this also could happen before.
The fix could be to patch the powershell archive module during startup. Please try this. Grab these 3 lines:
# Patch Microsoft.PowerShell.Archive to use en-US UI Culture (see https://github.com/PowerShell/Microsoft.PowerShell.Archive/pull/46)
$psarchiveModule = 'C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Microsoft.PowerShell.Archive\Microsoft.PowerShell.Archive.psm1'
Set-Content -path $psarchiveModule -value (Get-Content -encoding utf8 -raw -path $psarchiveModule).Replace("`r`nImport-LocalizedData LocalizedData -filename ArchiveResources`r`n","`r`nImport-LocalizedData LocalizedData -filename ArchiveResources -UICulture 'en-US'`r`n")
and place them in a local file called AdditionalSetup.ps1 Then add this file to your New-BcContainer in -myscripts @('full path of file')
If you can confirm this works, then I will check this in
Adding the -locale en-US
argument does not allow the program to run.
Removing dotnet Framework Assemblies
Using Symbols Folder: C:\Agent\_work\1\s\.alPackages
LCID Name DisplayName
---- ---- -----------
2057 en-GB English (United Kingdom)
LCID Name DisplayName
---- ---- -----------
1033 en-US English (United States)
The 'Expand-Archive' command was found in the module 'Microsoft.PowerShell.Archive', but the module could not be loaded. For more information, run 'Import-Module Microsoft.PowerShell.Archive'.
Exception Script Stack Trace:
The get-culture
changes from en-GB
to en-US
. The get-uiculture
stays as en-GB
.
The -locale en-US
changes the get-culture
but not the get-uiculture
Without the argument locales in Invoke-scriptInBcContainer
are all en-GB
.
This ALSO applies to V24.
The session data differs for V23 and V24, V24 uses powershell7 and V23 uses default powershell. For V23 the session data is ...
Session data ...
State : Opened
IdleTimeout : -1
OutputBufferingMode :
DisconnectedOn :
ExpiresOn :
ComputerType : Container
ComputerName : 2ce21018dcc7c559b980da33fe03fa14bec50389520c4b25ab405d0abc812539
ContainerId : 2ce21018dcc7c559b980da33fe03fa14bec50389520c4b25ab405d0abc812539
VMName :
VMId :
ConfigurationName : Microsoft.PowerShell
InstanceId : a3e3c0bb-3feb-4fd3-a7a3-53a5fb9caef5
Id : 1
Name : WinRM1
Availability : Available
ApplicationPrivateData : {DebugMode, DebugStop, UnhandledBreakpointMode, PSVersionTable...}
Runspace : System.Management.Automation.RemoteRunspace
For V24
Session data ...
State : Opened
IdleTimeout : -1
OutputBufferingMode :
DisconnectedOn :
ExpiresOn :
ComputerType : Container
ComputerName : 45122b0a79705c2fbf4c4c229615f74c968ede2b31939f1bdfa4dd50a10ec342
ContainerId : 45122b0a79705c2fbf4c4c229615f74c968ede2b31939f1bdfa4dd50a10ec342
VMName :
VMId :
ConfigurationName : PowerShell.7
InstanceId : 6ce6df48-ed20-40ea-a21a-b67bc2994cd8
Id : 1
Name : WinRM1
Availability : Available
ApplicationPrivateData : {DebugMode, DebugStop, UnhandledBreakpointMode, PSVersionTable...}
Runspace : System.Management.Automation.RemoteRunspace
WinRM has been turned on on that machine. So I turned it off and ignored the error.
Session V23 with WinRM turned off. (Turning WinRM off did not fix it.)
Session data ...
State : Opened
IdleTimeout : -1
OutputBufferingMode :
DisconnectedOn :
ExpiresOn :
ComputerType : Container
ComputerName : 90aba899952e1773d7ee0adce679cf5b69e99646d4880b16b5c2ee85a9632787
ContainerId : 90aba899952e1773d7ee0adce679cf5b69e99646d4880b16b5c2ee85a9632787
VMName :
VMId :
ConfigurationName : Microsoft.PowerShell
InstanceId : f54f2209-a6e5-4ec6-8f7f-b9285fa93505
Id : 1
Name : WinRM1
Availability : Available
ApplicationPrivateData : {DebugMode, DebugStop, UnhandledBreakpointMode, PSVersionTable...}
Runspace : System.Management.Automation.RemoteRunspace
All four combinations (23,24 and powershell, pwsh) return en-US when running a powershell with the bc-image just using docker.
PS C:\> get-uiculture ; get-culture
LCID Name DisplayName
---- ---- -----------
1033 en-US English (United States)
1033 en-US English (United States)
Host returns
PS C:\> get-uiculture ; get-culture
LCID Name DisplayName
---- ---- -----------
2057 en-GB English (United Kingdom)
2057 en-GB English (United Kingdom)
Grrrr.
Creating TVision as SQL User and add to sysadmin
Creating SUPER user
Access to the path 'C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Microsoft.PowerShell.Archive\Microsoft.PowerShell.Archive.psm1' is denied.
at <ScriptBlock>, C:\Run\my\AdditionalSetup.ps1: line 3
at <ScriptBlock>, C:\Run\navstart.ps1: line 243
at <ScriptBlock>, C:\Run\start.ps1: line 390
at <ScriptBlock>, <No file>: line 1
Initialization of container Build-S3B28523A160 failed
At C:\Program Files\WindowsPowerShell\Modules\BcContainerHelper\6.0.16\ContainerHandling\Wait-NavContainerReady.ps1:42
char:17
+ ... throw "Initialization of container $containerName failed" ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Initialization ...8523A160 failed:String) [], RuntimeException
+ FullyQualifiedErrorId : Initialization of container Build-S3B28523A160 failed
##[error]PowerShell exited with code '1'.
Finishing: Start Build Container
Ok, then maybe
# Patch Microsoft.PowerShell.Archive to use en-US UI Culture (see https://github.com/PowerShell/Microsoft.PowerShell.Archive/pull/46)
$psarchiveModule = 'C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Microsoft.PowerShell.Archive\Microsoft.PowerShell.Archive.psm1'
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule((whoami),'Modify', 'Allow')
$acl = Get-Acl -Path $psarchiveModule; $acl.AddAccessRule($rule); Set-Acl -Path $psarchiveModule -AclObject $acl
if (Test-Path $psarchiveModule) { Set-Content -path $psarchiveModule -value (Get-Content -encoding utf8 -raw -path $psarchiveModule).Replace("`r`nImport-LocalizedData LocalizedData -filename ArchiveResources`r`n","`r`nImport-LocalizedData LocalizedData -filename ArchiveResources -UICulture 'en-US'`r`n") }
Another thing I would like you to try is to set
$bcContainerHelperConfig.useWinRmSession = 'always'
in the latest 6.0.17 preview without the above overwrite and tell me if that fixes the issue. It will then not use the standard containerized connection, but instead always winrm, where I set the culture to en-US in the session.
Success! We were allowed to modify the permissions and the compile succeeded.
Thank you!
While using just 6.0.17-preview1193 without the overwrite does not seem to work on my end, it does work with the overwrite.
Setting json config.
"always" fails. "never" fails After adding: "winrm quickconfig -force" on the host. "always" succeeds "never" fails "allow" (default no configuration) fails.
{"MicrosoftTelemetryConnectionString": "",
"useWinRmSession": "always"}
This fails no winrm set always
### Running New-BCContainer
BcContainerHelper version 6.0.17-preview1193
Setting MicrosoftTelemetryConnectionString =
Setting useWinRmSession = always
WinRM service is not running, will not try to use WinRM sessions
Running on Windows, PowerShell 5.1.22621.2506
WARNING: Container name should not exceed 15 characters
BcContainerHelper is version 6.0.17-preview1193
BcContainerHelper is running as administrator
HyperV is Enabled
Host is Microsoft Windows 11 Enterprise - 10.0.22631.3296
UsePsSession is True
UsePwshForBc24 is True
UseWinRmSession is never
UseSslForWinRmSession is True
Docker Client Version is 24.0.7
Docker Server Version is 24.0.7
This fails no winrm set never
### Running New-BCContainer
BcContainerHelper version 6.0.17-preview1193
Setting MicrosoftTelemetryConnectionString =
Setting useWinRmSession = never
Running on Windows, PowerShell 5.1.22621.2506
WARNING: Container name should not exceed 15 characters
BcContainerHelper is version 6.0.17-preview1193
BcContainerHelper is running as administrator
HyperV is Enabled
Host is Microsoft Windows 11 Enterprise - 10.0.22631.3296
UsePsSession is True
UsePwshForBc24 is True
UseWinRmSession is never
UseSslForWinRmSession is True
Docker Client Version is 24.0.7
Docker Server Version is 24.0.7
Host WinRM enabled, set "always" success
### Running New-BCContainer
BcContainerHelper version 6.0.17-preview1193
Setting MicrosoftTelemetryConnectionString =
Setting useWinRmSession = always
Running on Windows, PowerShell 5.1.22621.2506
WARNING: Container name should not exceed 15 characters
BcContainerHelper is version 6.0.17-preview1193
BcContainerHelper is running as administrator
HyperV is Enabled
Host is Microsoft Windows 11 Enterprise - 10.0.22631.3296
UsePsSession is True
UsePwshForBc24 is True
UseWinRmSession is always
UseSslForWinRmSession is True
Docker Client Version is 24.0.7
Docker Server Version is 24.0.7
Host WinRM enabled, set "never" fails
### Running New-BCContainer
BcContainerHelper version 6.0.17-preview1193
Running on Windows, PowerShell 5.1.22621.2506
WARNING: Container name should not exceed 15 characters
BcContainerHelper is version 6.0.17-preview1193
BcContainerHelper is running as administrator
HyperV is Enabled
Host is Microsoft Windows 11 Enterprise - 10.0.22631.3296
UsePsSession is True
UsePwshForBc24 is True
UseWinRmSession is never
UseSslForWinRmSession is True
Docker Client Version is 24.0.7
Docker Server Version is 24.0.7
WinRM enabled, setting is default, fails
### Running New-BCContainer
Running on Windows, PowerShell 5.1.22621.2506
WARNING: Container name should not exceed 15 characters
BcContainerHelper is version 6.0.17-preview1193
BcContainerHelper is running as administrator
HyperV is Enabled
Host is Microsoft Windows 11 Enterprise - 10.0.22631.3296
UsePsSession is True
UsePwshForBc24 is True
UseWinRmSession is allow
UseSslForWinRmSession is True
Docker Client Version is 24.0.7
Docker Server Version is 24.0.7
OK - I also expect that setting "usePSSession" to false then works without the override.
It seems like the problem is only on getting a session using the containerId with a configurationName set
I think I have enough to make a fix. I will patch the Archice module in the generic image 1.0.2.21 I will add the patch to containerhelper if using generic image 1.0.2.20 or earlier
Shipped in preview
Please test the latest preview, thanks
Looks good here!
Looks good, "BcContainerHelper version 6.0.17-preview1194" is running fine with defaults, no WinRM on host.
shipped 6.0.17
Describe the issue I'm getting this error from
Compile-AppInBCContainer
, this only happens with V23 (not V24 or V25, haven't tested earlier). Google says this is likely a version skew. ... Hmmm.It happens with
baseimage:ltsc2022
on Windows10 when using HyperV. It does happen When usingbaseimage:2004
on Windows10 in process mode. It does NOT happen when usingbaseimage:ltsc2022
on Windows-server-2022 in process mode. It started in 6.0.16, locking the agents on 6.0.15 gives no error. Is that a DLL copied from the host ?I did this on a Win11 agent.
Also nothing from a default shell in the image.
But If I add the command
Import-Module Microsoft.PowerShell.Archive
intoC:\Program Files\WindowsPowerShell\Modules\BcContainerHelper\6.0.16\AppHandling\Compile-AppInNavContainer.ps1
at line 313, I get this:in this:
Scripts used to create container and cause the issue
Full output of scripts
Screenshots If applicable, add screenshots to help explain your problem.
Additional context
BTW:
There was an error creating your Issue: body is too long (maximum is 65536 characters).