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:
docker/for-win#3884 (comment)

Justin (@jterry75)

jhowardmsft Justin (@jterry75) John Starks (@jstarks)

Is this repo active? This issue has been 6 days without any reply.
Please confirm...

I'm also getting this error since upgrading my machine to 1903 when trying to build any dockerfile (that I've tried so far).

It seems to get to the first config step and then fail.

Was anyone able to fix this? I'm getting it as well.

Deep Debroy (@ddebroy)

/cc Deep Debroy (@ddebroy)

Just updated my Win 10 to 1903. Seeing the same issue.

got the same issue on win10 release 1903 when trying to copy content from a container to the file system:
docker cp [containerName]:[containerPath] [hostFilesystem]
resulting in
Error response from daemon: hcsshim::PrepareLayer failed in Win32: Incorrect function. (0x1) path=C:\ProgramData\Docker\windowsfilter\6a7019f5530c15951e6a7441dba27ed40a87c560b4ab5befe324aa26956c498d

Docker version 18.09.2, build 6247962

Justin (@jterry75)

Justin (@jterry75) jhowardmsft

Guys, please reply/response soon.
Is this repo actively monitored for issues too? Is it only active for code changes (commits) only?
Because I have seen active commits, but on issues are not having responses at all.

Please confirm, as this issue is now aged more than 3 weeks.... 😞

As for me, I think I'm going to rollback my Windows to be 1809 and I won't update to 1903 to build any docker container on Windows 10 1903 until this issue is solved, and this is quite a showstopper for me and my teams, including other folks that have experienced this issue too.

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 dockerd daemon 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

After upgrading to 1903, I couldn't build anything. The only thing that fixed it was removing the storage-ops.

antonkhelou

antonkhelou that's storage-ops in the daemon configuration? What storage-ops did you have configured?

Oh, I see a comment in moby/moby#36831 (comment)

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

I'm using the default storage location, and not using storage-opts
Changing the storage location, excluding the storage location and disabling Windows defender won't solve the problem in my case.
EDIT: using storage-opts results in a slightly different error Error response from daemon: hcsshim::PrepareLayer failed in Win32: The parameter is incorrect. (0x57) when using the hack in my earlier comment. when not using the hack, the error is not changed.

This is not an hcsshim issue. I'm closing this. See docker/for-win#3884 (comment)

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 dockerd daemon 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

how to use it?

I didn't have storage-opts set at all in my daemon.json. I also tried with "storage-opts": [ "size=20479M" ] but still no luck so I guess I just have to wait for Microsoft to fix the bug.

Ahmed Abdelfatah (@giniyat202)

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 dockerd daemon 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

how to use it?

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.

Using the patch with storage-opt NOT working;

I did try the patch but from error code hcsshim::PrepareLayer - failed failed in Win32: The parameter is incorrect. (0x01) to hcsshim::PrepareLayer - failed failed in Win32: The parameter is incorrect. (0x57)

without the storage-opt setting, docker build works fine!

(https://github.com/imphasing/dockerPatcher)

Ahmed Abdelfatah (@giniyat202) windows version 1903 (18362.418)

0x57 is well documented in: #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: moby/moby#40128 once merged in a new release will have to be made. 0x01 error has also already been patched and merged: moby/moby#39679 you will just need a binary newer than that for that fix (or wait for the backport release docker-archive/engine#314 binaries).

Ahmed Abdelfatah (@giniyat202)

Hi guys!

After ensuring these steps:

uninstalling Docker, deleting Docker data,
deleting/uninstalling online storage desktop (such as Box, DropBox)
having fresh install of Docker Desktop 2.1.0.4 with ensuring that I have no storage-opts in the Docker configuration,

Now I have successful Docker build!

I have this configuration:

Windows 10 1903 build 18362.476
Docker Desktop 2.1.0.4 (39773)
Docker Engine 19.03.4

Here's my Docker about box:

I have tried to apply the suggested patch from Ahmed Abdelfatah (@giniyat202) , but the patch didn't work for me.

NOTES:

Uninstall all of the online drive storage that permeates as having virtual file system, such as Box, Dropbox on your machine that is used to build Docker image.
The only one online drive storage that has nothing to do with this issue is Microsoft OneDrive. (don't ask me why, I really don't know 😞 )
Apparently before I have Windows 10 1903 updates of build 18362.449, this issue still happened. It seems something from Microsoft has fixed this issue (on Windows 10 side).
I have no problem running Docker build on both Windows 10 builds of 18362,449 and 18362.476, as long as I have at least Docker Desktop 2.1.0.4 (detail in the about box above).

Feel free to tell me if my suggestion doesn't work for some or all of you.

I've just updated Windows to 18363.476 and I am now able to build Windows images without setting "storage-opts": [ "size=20G" ]

Edit... actually, no. "docker-compose build" still fails with 0x57 but "docker build ." is able to build a Windows image. So my workaround for "docker-compose build" is "docker build -t ." to build my Windows image first, then run "docker-compose build" which will successfully use docker-compose.yml to create my container.

El-Gor-do

deleting/uninstalling online storage desktop (such as Box, DropBox) will solve the problem El-Gor-do

Bart Plasmeijer (@bplasmeijer)

Bart Plasmeijer (@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.

Looks like I spoke too soon, After uninstalling OneDrive then I was able to docker-compose but after rebooting, 0x57 occurs again despite no longer having OneDrive installed.

After upgrading to 1909 and the docker version is 19.03.5 and the same problem when i run image with storage-opt param,such as

Any one have the same problems?

Hello,
Always the same problem: "hcsshim::PrepareLayer - failed failed in win32 : Incorrect function. (0x1)"

Docker Engine 19.03.5
Docker Desktop 2.1.0.5
Windows 10 1903 build 18362.535

Configuration file:
{
"registry-mirrors": [],
"insecure-registries": [],
"debug": true,
"experimental": false,
],
"data-root": "E:\Docker"
}

I have always the same error with or without "storage-opts" and also when using default location.
I am nw on Docker am I need urgently to solve this issue.

Can You help me ?

Thanks.

João

Windows just did an update and laid down a new copy of this driver.

Rename the C:\Windows\System32\drivers\cbfs6.sys as something else (or delete it).
Remove the container.
Reboot.

See: docker/for-win#3884 (comment)

Ahmed Abdelfatah (@giniyat202)

Running on Windows Version 10.0.18362, patch provided by Ahmed Abdelfatah (@giniyat202) worked perfectly. Thanks a lot ! Also thanks to I'm phasing (@imphasing) for putting in a VS solution

Ahmed Abdelfatah (@giniyat202)

Hi,
I tried following the steps above and got as far as compiling this C++ program and then it threw some check integrity error and followed Ahmed Abdelfatah (@giniyat202) instructions on x64dbg but when you get to the last step it doesn't actually say what to do with the information.

I'm on Windows 10 20H2, have run windows update and have the latest docker (4.1.1)

The error I get seems the same. I don't know what to do with this check integrity error from the C++ app so bit lost what i can do now.

Sending build context to Docker daemon 5.632kB
Step 1/2 : FROM mcr.microsoft.com/windows/nanoserver:1809
---> 1dba00abbe16
Step 2/2 : USER ContainerAdministrator
---> Running in 7da904ee3667
hcsshim::PrepareLayer - failed failed in Win32: Incorrect function. (0x1)

thanks
*update, I have upgraded to the latest windows 10 version (21H1) and still same issue
I've just uninstalled box as per El-Gor-do suggestion and restarted and it now works

Problem still here

docker pull mcr.microsoft.com/windows/nanoserver:1909
1909: Pulling from windows/nanoserver
fe8c39bf0334: Extracting [==================================================>]  102.1MB/102.1MB
failed to register layer: re-exec error: exit status 1: output: hcsshim::ProcessBaseLayer \\?\C:\ProgramData\Docker\windowsfilter\c93bfe644648f253e1aedf8d036ef5ba16436fdb59097fe5c97eba860b6dbe59: The parameter is incorrect.

docker info
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Build with BuildKit (Docker Inc., v0.6.3)
  compose: Docker Compose (Docker Inc., v2.1.1)
  scan: Docker Scan (Docker Inc., 0.9.0)

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 0
 Server Version: 20.10.10
 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: inactive
 Default Isolation: hyperv
 Kernel Version: 10.0 19043 (19041.1.amd64fre.vb_release.191206-1406)
 Operating System: Windows 10 Pro Version 2009 (OS Build 19043.1348)
 OSType: windows
 Architecture: x86_64
 CPUs: 8
 Total Memory: 7.881GiB
 Name: CIBuilder
 ID: ***
 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

Is there any fix? dockerd patcher cannot work because it doesn't find vmcompute.dll.

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

Navigation Menu

Repository navigation

The hcsshim on Windows 10 1903 always fails to build Docker image #624

18 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

The hcsshim on Windows 10 1903 always fails to build Docker image #624

Description

Activity

eriawan commented on Jun 17, 2019

jbolduan commented on Jun 27, 2019

gatsby0121 commented on Jun 27, 2019

thaJeztah commented on Jul 1, 2019

xuelix commented on Jul 3, 2019

moo-ecxio commented on Jul 4, 2019

eriawan commented on Jul 4, 2019

giniyat202 commented on Jul 9, 2019

antonkhelou commented on Jul 11, 2019

thaJeztah commented on Jul 11, 2019

thaJeztah commented on Jul 11, 2019

giniyat202 commented on Jul 12, 2019

lowenna commented on Jul 12, 2019

lyling commented on Aug 6, 2019

18 remaining items

El-Gor-do commented on Nov 11, 2019

bplasmeijer commented on Nov 13, 2019

mitchcapper commented on Nov 13, 2019

eriawan commented on Nov 13, 2019

El-Gor-do commented on Nov 14, 2019

bplasmeijer commented on Nov 18, 2019

El-Gor-do commented on Nov 18, 2019

El-Gor-do commented on Nov 24, 2019

wawa0210 commented on Nov 28, 2019

jseixas01 commented on Jan 5, 2020

DDieterich commented on Jan 6, 2020

kaidokert commented on Feb 10, 2020

Bhodges94 commented on Oct 26, 2021

xakod commented on Nov 24, 2021

Antonin750 commented on Apr 15, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions