hcsshim: The hcsshim on Windows 10 1903 always fails to build Docker image
After I have updated my machine from Windows 10 1809 to 1903, I always experiencing errors when doing image build.
The error always shows that the problem is caused by hcsshim:
F:\dockerimages>docker build --rm -f Dockerfile -t dev/testimage .
Sending build context to Docker daemon 330.6MB
Step 1/11 : FROM mcr.microsoft.com/dotnet/framework/runtime:4.7.2-windowsservercore-ltsc2016
---> d529d6d68c79
Step 2/11 : SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';"]
---> Running in 3a7c4fcc808c
hcsshim::PrepareLayer failed in Win32: Incorrect function. (0x1) path=C:\ProgramData\Docker\windowsfilter\3a7c4fcc808c8794606111ba9fb67342560aa5bfa40a888d564e52871fbd8840
This issue is always reproducible on Windows 10 1903, and on previous version of Windows 10 it doesn’t happen. I have tested on other machines that have WIndows 10 1803 and Windows 10 1809, and using the same Docker for Windows Desktop (2.0.0.3), the image build is always finished/done successfully.
This has been reported before on Docker for Windows: docker/for-win#3884 especially this comment and the next comments after: https://github.com/docker/for-win/issues/3884#issuecomment-498939672
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 12
- Comments: 47 (5 by maintainers)
After debugging for a few hours I stumbled upon a call to AttachVirtualDisk which is used to mount the images.
Some undocumented flags were passed to the function during one of the calls and I found out that removing the undocumented flags resolves the issue for some reason.
I have created a simple program to patch the running
dockerddaemon in memory and remove the undocumented flags. It has been tested on 10.0.18362.175, however, I cannot guarantee that it would work on other builds.USE AT YOUR OWN RISK
Looks like regression is also tracked in https://github.com/microsoft/hcsshim/issues/708, and a workaround has been merged in https://github.com/microsoft/hcsshim/pull/718
Work is in progress to get that workaround merged into the Docker codebase (see https://github.com/moby/moby/pull/40128)
First you should compile the program. I created a c++ console application on Visual Studio 2015 but generally any c compiler that targets Win32 should work.
After that, you can use an elevated powershell to run the following command:
\path\to\generated\executable.exe p (ps dockerd).id. You can also revert the changes by running\path\to\generated\executable.exe u (ps dockerd).id.0x57 is well documented in: https://github.com/microsoft/hcsshim/issues/708 has been patched in hcsshim with a work around already for windows 1903. The work around being merged into docker can be found in terms of progress at: https://github.com/moby/moby/pull/40128 once merged in a new release will have to be made. 0x01 error has also already been patched and merged: https://github.com/moby/moby/pull/39679 you will just need a binary newer than that for that fix (or wait for the backport release https://github.com/docker/engine/pull/314 binaries).
This is not an hcsshim issue. I’m closing this. See https://github.com/docker/for-win/issues/3884#issuecomment-510973455
@jhowardmsft @jterry75 @jstarks
Is this repo active? This issue has been 6 days without any reply. Please confirm…
Hi, The patch works fine for Windows 11 with a new version of vmcompute.dll. Obviously you need to correctly find the new edx position. Be careful the check_integrity_bytes changed too.
I don’t know why that doesn’t work with the 376 value and that must be replace by another one but great job
Running on Windows
Version 10.0.18362, patch provided by @giniyat202 worked perfectly. Thanks a lot ! Also thanks to @imphasing for putting in a VS solution@bplasmeijer I don’t use Box or DropBox but I found that uninstalling OneDrive (which comes preinstalled with Windows 10) fixed the 0x57 error when using docker-compose.
@giniyat202 thanks for your help, I managed to figure it out now. It turns out that the check_integrity_bytes and check_integrity_offset for 18363.449 is identical to 18362.418. Just to expand on your instructions for those of us who are not x64dbg experts,
2 - If vmcompute.dll doesn’t appear in the modules list then keep pressing F9 until vmcompute.dll appears.
5 - In the References tab, double click on each reference to jump to the call in the CPU tab, then scroll up 3 lines and check if the preceding 3 instructions are “xor r8d,r8d”, “mov edx,376” and “mov rcx,qword ptr ss:[rbp-58]”
I use x64dbg for that. The exact steps required to update this patch are as follows:
vmcompute.dllinside x64dbg. You can find this file under%systemroot%\system32.Symbolstab, right clickvmcompute.dllmodule and selectDownload symbols for this module. You also need to make note ofBaseaddress next to the module.?MountVhdin the search bar below the right pane then double click the only resultCtrl-r376onedx, In my case it was the 4th reference.check_integrity_offsetshould be calculated as by subtractingBaseobtained in step 2 from the address ofxor r8d, r8dinstruction andcheck_integrity_bytesare the bytes starting from this instruction all the way to thejainstuction slightly below the callI will update my code once I receive the update (Windows update didn’t offer it for some reason)
@lyling I have just updated it for version 10.0.18362.175 and it should work as usual once you recompile it
Oh, I see a comment in https://github.com/moby/moby/issues/36831#issuecomment-498612392
If you have a different storage location configured, could you try if things work if you disable Windows defender, or exclude the location? https://support.microsoft.com/en-us/help/4028485/windows-10-add-an-exclusion-to-windows-security