Я пытаюсь запустить PowerShell (x86) в Windows Docker Контейнер из PowerShell, но он не запускает новую оболочку. Я бегу Docker от AWS Windows EC2, бегущего от Windows_Server-2019-English-Full-ContainersLatest-2020.02.12
AMI. Нужны ли мне какие-то специфические c DLL для этой работы?
У меня есть Dockerfile, который выглядит примерно так:
FROM mcr.microsoft.com/windows/insider:10.0.17763.107
...
SHELL ["PowerShell", "-Command"]
...
CMD PowerShell
После запуска контейнера я пытаюсь запустить 32 -bit PowerShell с помощью приведенной ниже команды, но она не запускает новую оболочку. Я думаю, что это просто ошибки.
C:/Windows/SysWOW64/WindowsPowerShell/v1.0/powershell.exe
Я пытался поймать ExitCode, используя следующие команды:
$Process = Start-Process -PassThru -Wait -FilePath "C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe"
Write-Output "ExitCode = $($Process.ExitCode)"
Какие выходные данные:
ExitCode = -1073741502
Какие, вероятно, означает STATUS_DLL_INIT_FAILED
( Что означает ExitCode -1073741502? )
Команды, которые я пытаюсь выполнить в контейнере Docker, работают, когда я запускаю его из PowerShell на хосте EC2 , Я могу проверить, запустив [Environment]::Is64BitProcess
, который возвращает False
.
————————
Это версия docker, которую я использую на AWS EC2 основан на Windows_Server-2019-English-Full-Base-2020.02.12 (ami-00cb4c0d60b9476f4)
PS> docker version
Client: Docker Engine - Community
Version: 19.03.5
API version: 1.40
Go version: go1.12.12
Git commit: 633a0ea
Built: Wed Nov 13 07:22:37 2019
OS/Arch: windows/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 19.03.5
API version: 1.40 (minimum version 1.24)
Go version: go1.12.12
Git commit: 633a0ea
Built: Wed Nov 13 07:36:50 2019
OS/Arch: windows/amd64
Experimental: false
Другое обновление:
Команды фактически работают, когда я запускаю из другого EC2, который я создал некоторое время назад на основе ami-0d4df21ffeb914d61
( Это также Windows_Server-2019-English-Full-Base
, но ami больше не публикуется c)
Другое обновление:
Похоже, что это проблема с ami. Был в состоянии заставить его работать с предыдущей версией, Windows_Server-2019-English-Full-Base-2020.01.15 (ami-09f2114fecbe506e2)