Skip to content

Conversation

iancward
Copy link

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

When using WOW64, C:\Windows\System32 actually points to
C:\Windows\SysWow64.
@iancward
Copy link
Author

iancward commented Nov 6, 2024

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

@iankingori
Copy link

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

@iancward
Copy link
Author

iancward commented Jan 14, 2025

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
Copy link
Author

iancward commented Mar 6, 2025

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

1 similar comment
@iancward
Copy link
Author

iancward commented Apr 8, 2025

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

@ntrappe-msft ntrappe-msft requested a review from Copilot May 13, 2025 19:20
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Author

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

@iancward
Copy link
Author

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

@michbern-ms
Copy link
Contributor

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
Copy link
Author

Hi @michbern-ms any updates on this?

@fjs4
Copy link

fjs4 commented Aug 26, 2025

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
Copy link
Author

iancward commented Aug 26, 2025

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
Copy link

fjs4 commented Aug 26, 2025

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
Copy link
Author

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?

Copy link
Contributor

This issue has been open for 30 days with no updates.
no assignees, please provide an update or close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants