Fixed #393 - Make Docker available to 32 bit apps

[iancward]

When using WOW64, C:\Windows\System32 actually points to C:\Windows\SysWow64.

[iancward]

@ntrappe-msft @michbern-ms and chance you folks could review this PR?

[iankingori]

@iancward please provide some additional context on the specific scenario you are solving and an approach to test this.

[iancward]

Hi iankingori, the context is in the referenced issue: #393.

Namely, the docker-ce helper script in this repository installs docker.exe by copying it directly to C:\Windows\System32. When you're running a 32 bit application (e.g. msbuild.exe for Visual Studio 2019 or older), the %windir%\System32 directory is mapped to %windir%\SysWOW64 and therefore any attempts to call docker.exe installed by this helper script by a 32-bit application will fail, because it doesn't exist in the path.

TL;DR: this PR makes docker.exe available for 32 bit applications.

[iancward]

Hi @iankingori @ntrappe-msft any updates on this?

[iancward]

Hi @iankingori @ntrappe-msft any updates on this?

[Copilot]

Pull Request Overview

This PR addresses issue #393 by ensuring that the Docker daemon is available for 32‑bit applications running under WOW64 by copying dockerd.exe to both System32 and SysWow64.

• Added a copy operation targeting SysWow64 to support WOW64 redirection.
• Updated installation script to cover both 64‑bit and 32‑bit Docker daemon placements.

Comments suppressed due to low confidence (1)

helpful_tools/Install-DockerCE/install-docker-ce.ps1:647

• The new copy operation for the SysWow64 folder may require additional test coverage to ensure that the Docker daemon is correctly installed for 32-bit applications under WOW64.

Copy-File -SourcePath $DockerDPath -DestinationPath $env:windir\SysWow64\dockerd.exe

[iancward]

Hi @iankingori @ntrappe-msft any updates on this?

[iancward]

Hi @iankingori @ntrappe-msft @michbern-ms any updates on this?

[michbern-ms]

Hi, @iancward - sorry for the delay. Some of our team members were impacted by job eliminations and we're trying to get our house in order ... but I see you've been waiting a long time. Let me see what I can do.

[iancward]

Hi @michbern-ms any updates on this?

[fjs4]

Hi @iancward, it appears you're trying to work around the fact that by default trying to run a program from \windows\system32 when the parent is a 32-bit app, will actually try to launch from \windows\syswow64. Your proposed fix to put the 64-bit version of Docker in that location would work around the problem. However, the intention of that directory is to only container 32-bit binaries.

What is the parent 32-bit process? And how is it launched? Rather than trying to run the program from \windows\system32, you could instead try to run \windows\sysnative\Docker.exe. If the process interpreting that path is a 32-bit process, it will launch the 64-bit version of Docker.exe from \windows\system32 directory.

Will that approach work for you?

[iancward]

Hi @fjs4, as mentioned above, I'm using msbuild.exe, which in some circumstances is a 32-bit application. I'm not calling docker.exe directly, but it's being called by msbuild.exe when it's building a project with Docker targets, and it must exist in the Path, or the build will fail.

When you install Docker Desktop on Windows, it is installed to C:\Program Files\Docker\ and the bin folder is put in the path. However, if you're on Windows Server and use the helper script in this repo, instead of putting the Docker in C:\Program Files\Docker or elsewhere, it downloads a zip file of binaries and places docker.exe directly in C:\Windows\System32 which is inaccessible to 32-bit applications; you will receive an error that docker.exe is not found.

At the end of the day, docker.exe needs to be accessible in the Path 32-bit applications or we can't build our ASP.Net projects in CI/CD via msbuild.exe. I've successfully tested the changes in this PR and in fact have been using similar changes in our production environment

[fjs4]

Thanks for the additional clarity @iancward. I assume you're using an Exec command in your msbuild project file? If so, my suggestion was that you specify the path in the command, something like this:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Target Name="RunMyExecutable">
    <Exec Command="c:\windows\SysNative\Docker.exe <arguments>" />
  </Target>
</Project>

When invoked from a 32-bit build process, "SysNative" should force the system to launch the child process from \windows\system32.

Let me know if that helps. If not, could you share a snippet of your project file (to help me better understand).

[iancward]

Hi @fjs4,
I didn't add the docker configuration directly, I simply added Docker support to the .Net Framework solution following the documentation provided here.

And then on my build server (Windows Server 2019), I installed docker via the helper script in this repo. And we call msbuild.exe with the /t:containerbuild argument.

Instead of having to modify all of our projects, it would be nice if the script provided in this repo would work out of the box.

Maybe instead of copying the docker.exe file directly to C:\Windows\System32, it would be appropriate to add it to a C:\Program Files\Docker\ directory and then add it to the PATH?

[iancward]

@fjs4, @michbern-ms

Any updates on this?

[iancward]

@fjs4, @michbern-ms, @ntrappe-msft

Any updates on this?

[iancward]

@fjs4 @ntrappe-msft @michbern-ms and updates on this?

[iancward]

@fjs4 @ntrappe-msft @michbern-ms and updates on this?

[iancward]

@fjs4 @ntrappe-msft @michbern-ms and updates on this?

[iancward]

@fjs4 @ntrappe-msft @michbern-ms and updates on this?

@AvrumFeldman is this something you can review?

[smiezah-msft]

Thanks for raising this issue @iancward. After reviewing the behavior, it appears the underlying challenge is related to WoW64 filesystem redirection on 64-bit Windows. When a 32-bit process attempts to locate or launch Docker, Windows may redirect certain path lookups, causing the process to resolve a different location than expected.

Rather than placing the 64-bit Docker binaries in SysWOW64 (which is intended for 32-bit binaries), our recommendation would be to install Docker in a location outside of the redirected Windows system directories, such as Program Files, and ensure that location is explicitly added to the system PATH environment variable. This allows both 32-bit and 64-bit applications to locate and invoke the Docker executable consistently, without relying on filesystem redirection behavior.

In short, the issue is not that Docker itself is unavailable to 32-bit applications, but that the application's path resolution is affected by WoW64 redirection. Installing Docker in a non-redirected location and referencing it through the PATH provides a more robust and supportable solution.