Unable to install Latest Visual C++ Redistributable in Windows Containers

[Jeb135]

Describe the Bug

I apologize if this is not the correct forum for this issue, but I am at a loss on where else to report this issue. I am Unable to install Latest Visual C++ Redistributables (found here: https://aka.ms/vs/17/release/vc_redist.x64.exe) into windows containers. When the executable vc_redist.x64.exe runs inside the container either during a build or during runtime, nothing happens.

Steps to Reproduce

1. Build the following dockerfile docker build -t redist_test:latest .

# escape=`

# docker build -t redist_test:latest .
# docker run --rm -it --entrypoint powershell redist_test:latest

ARG BaseRepo=mcr.microsoft.com/dotnet/framework/aspnet
ARG BaseRepoTag=4.7.2

FROM $BaseRepo:$BaseRepoTag as base
SHELL ["Powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue'; $verbosePreference='Continue';"]

RUN [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; `
    Invoke-RestMethod -Uri https://aka.ms/vs/17/release/vc_redist.x64.exe -OutFile vc_redist_x64.exe; `
    Start-Process -filepath C:\vc_redist_x64.exe -ArgumentList "/install", "/passive", "/norestart", "'/log C:/redist_log.txt'" -Passthru | Wait-Process;

2. Run the image docker run --rm -it --entrypoint powershell redist_test:latest
3. Notice no log file from executable was created
4. Search for signs that the redistributable was installed in the container, such as Get-Item -Path HKLM:\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0\VC\Runtimes\x64, and you won't find anything.
5. Any assemblies that require the redistributables to run will fail to load.

Other Information

Unfortunately, there are no error messages that occur to list. To note a few other things I have tried or other observations I have made while trying to diagnose the issue:

• I have tried every combination of arguments for the executable, such as no logging, /passive vs /quiet, etc.
• Running the executable at build time or runtime doesn't appear to change anything.
• I have only tested in the ASPNET images, both tags 4.7.2 and 4.8, as the app I need the redistributables for is ASP.NET based
• There is one info level System Event Log entry that occrurs when Start-Process is used to run the executable:

Index Time          EntryType   Source                 InstanceID Message
   ----- ----          ---------   ------                 ---------- -------
     683 Oct 20 16:36  Information Application Popup              26 CriticalAppShutdownCleanupTimeout

The best I can tell is that the executable is not abiding by the arguments to run silently, and attempting to pop up a window and failing silently? Seeing as this is the only source of C++ 2019 Redistributables I figure this must work in a non-interactive environment right?

Output of docker version

Client:
 Version:           master-dockerproject-2022-03-26
 API version:       1.42
 Go version:        go1.17.8
 Git commit:        dd7397342a
 Built:             Sun Mar 27 00:09:40 2022
 OS/Arch:           windows/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          master-dockerproject-2022-03-26
  API version:      1.42 (minimum version 1.24)
  Go version:       go1.18
  Git commit:       8941dcfcc5
  Built:            Sun Mar 27 00:05:42 2022
  OS/Arch:          windows/amd64
  Experimental:     false

Output of docker info

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.8.2)
  compose: Docker Compose (Docker Inc., v2.9.0)
  extension: Manages Docker extensions (Docker Inc., v0.2.8)
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc., 0.6.0)
  scan: Docker Scan (Docker Inc., v0.17.0)

Server:
 Containers: 52
  Running: 0
  Paused: 0
  Stopped: 52
 Images: 182
 Server Version: master-dockerproject-2022-03-26
 Storage Driver: windowsfilter
  Windows:
 Logging Driver: json-file
 Plugins:
  Volume: local
  Network: ics internal l2bridge l2tunnel nat null overlay private transparent
  Log: awslogs etwlogs fluentd gcplogs gelf json-file local logentries splunk syslog
 Swarm: active
  NodeID: qtua9l1p2l9halezs4l0ae6uv
  Is Manager: true
  ClusterID: ua8jix4r9tihua2fo75pblyb6
  Managers: 1
  Nodes: 1
  Default Address Pool: 10.0.0.0/8
  SubnetSize: 24
  Data Path Port: 4789
  Orchestration:
   Task History Retention Limit: 5
  Raft:
   Snapshot Interval: 10000
   Number of Old Snapshots to Retain: 0
   Heartbeat Tick: 1
   Election Tick: 10
  Dispatcher:
   Heartbeat Period: 5 seconds
  CA Configuration:
   Expiry Duration: 3 months
   Force Rotate: 0
  Autolock Managers: false
  Root Rotation In Progress: false
  Node Address: 192.168.58.4
  Manager Addresses:
   192.168.58.4:2377
 Default Isolation: process
 Kernel Version: 10.0 17763 (17763.1.amd64fre.rs5_release.180914-1434)
 Operating System: Microsoft Windows Server Version 1809 (OS Build 17763.737)
 OSType: windows
 Architecture: x86_64
 CPUs: 2
 Total Memory: 16GiB
 Name: DEV01
 ID: BX6Y:OQBU:JRIL:W4A6:X6O2:77H5:I3BJ:KUMB:PR33:SICG:OHB5:ZXZF
 Docker Root Dir: C:\ProgramData\docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: Community Engine

[mthalman]

Have you looked through #15? There are some solutions posted there.

[Jeb135]

I have with no luck. Everything I've researched about the issue (including #15 ) seem to claim that the cmdlet Start-Process solves the problem but I haven't had it work in any of my testing unfortunately. The only difference I can tell between what I am doing and what #15 is doing is the redistributable version, but when running the exe's locally there doesn't seem to be a difference on them besides version numbers in the registry.

[Jeb135]

So the same dockerfile on a Windows Server 2022 VM host works, but the original host I was using running Windows Server 2019 fails. Anyone have any ideas why this would be the case? The only difference is the host OS version, the docker version is the exact same.

[Jeb135]

Additionally, after an OS upgrade of the original 2019 host to 2022, this began working. So this must be an issue with Windows Server 2019 hosts? @mthalman

[mthalman]

That's interesting. That sounds like something the Windows containers team can help diagnose. I'd recommend posting an issue to https://github.com/microsoft/Windows-Containers.

[Jeb135]

Will do, thanks!

[Jeb135]

microsoft/Windows-Containers#288 opened here, in case others are looking for it.