search

docker / for-win

Bug reports for Docker Desktop for Windows
https://www.docker.com/products/docker#/windows
1.86k stars 291 forks source link

An error occurred while attempting to build Docker image #3884

Closed vinaychandra closed 3 years ago

vinaychandra commented 5 years ago

Information

Create new project from ASP.NET Core 3 API template with Enable Docker Support checked. This is the sample DockerFile

#Depending on the operating system of the host machines(s) that will build or run the containers, the image specified in the FROM statement may need to be changed.
#For more information, please see https://aka.ms/containercompat

FROM mcr.microsoft.com/dotnet/core/aspnet:3.0-nanoserver-1809 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/core/sdk:3.0-nanoserver-1809 AS build
WORKDIR /src
COPY ["WebApplication1/WebApplication1.csproj", "WebApplication1/"]
RUN dotnet restore "WebApplication1/WebApplication1.csproj"
COPY . .
WORKDIR "/src/WebApplication1"
RUN dotnet build "WebApplication1.csproj" -c Release -o /app

FROM build AS publish
RUN dotnet publish "WebApplication1.csproj" -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "WebApplication1.dll"]

This is the full build output when trying to run the image from VS 2019

1>------ Build started: Project: WebApplication1, Configuration: Debug Any CPU ------
1>C:\Program Files\dotnet\sdk\3.0.100-preview5-011568\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(157,5): message NETSDK1057: You are using a preview version of .NET Core. See: https://aka.ms/dotnet-core-preview
1>WebApplication1 -> C:\Users\vinay\source\repos\WebApplication1\WebApplication1\bin\Debug\netcoreapp3.0\WebApplication1.dll
1>docker build -f "C:\Users\vinay\source\repos\WebApplication1\WebApplication1\Dockerfile" -t webapplication1:dev --target base  --label "com.microsoft.created-by=visual-studio" --label "com.microsoft.visual-studio.project-name=WebApplication1" "C:\Users\vinay\source\repos\WebApplication1"
1>Sending build context to Docker daemon  19.97kB
1>
1>Step 1/6 : FROM mcr.microsoft.com/dotnet/core/aspnet:3.0-nanoserver-1809 AS base
1> ---> 03ea2d12b576
1>Step 2/6 : WORKDIR /app
1> ---> Running in b43c8006530c
1>hcsshim::PrepareLayer - failed failed in Win32: Incorrect function. (0x1)
1>C:\Users\vinay\.nuget\packages\microsoft.visualstudio.azure.containers.tools.targets\1.7.8\build\Container.targets(196,5): error CTP1001: An error occurred while attempting to build Docker image.
1>Done building project "WebApplication1.csproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Note that I am able to login (docker login works) but the build fails in another step.

StephenDoherty commented 5 years ago

I have the same exact config and the latest docker desktop. Hopefully this can be resolved soon.

adrian-j-programmer commented 5 years ago

This is a complete blocker for me as well after the update to 1903. Can we get an ETA on the fix for this issue?

TheRichCarey commented 5 years ago

This is still a blocker 3 months on with the exact same issue. Our work machines have also now gone over to 1903 with no ability to migrate backwards.

Same issue reported in the MS hcsshim project which has been closed and redirected here.

What is the ETA on this, as this could cause a huge impact now 1903 is in the final stages of rollout.

Most simple dockerfile i can create to repo is:

FROM mcr.microsoft.com/windows/nanoserver:1809

SHELL ["powershell"]

Running with Debug I get [cut down] 

Version: 2.1.0.1 (37199)
Channel: stable
Sha1: 0a6675341101baa9fd3e4ee7c6606d832bc54abd
Started on: 2019/08/31 11:58:20.410
Resources: C:\Program Files\Docker\Docker\Resources
OS: Windows 10 Pro
Edition: Professional
Id: 1903
Build: 18362

The log is massive but this is the section executing when the failure takes place.

Analysis symbol: 
Rechecking for solution: 0
Report Id: b9593400-a89a-4994-b0a5-66a78a735a7c
Report Status: 268435456
Hashed bucket: abdd14e236dc79baab069654505e665a
Cab Guid: 0
[12:33:37.620][ApiProxy          ][Info   ] time="2019-08-31T12:33:37+01:00" msg="Cancel connection..."
[12:33:37.620][ApiProxy          ][Info   ] time="2019-08-31T12:33:37+01:00" msg="proxy >> GET /v1.40/events\n"
[12:33:37.622][ApiProxy          ][Info   ] time="2019-08-31T12:33:37+01:00" msg="proxy << GET /v1.40/events (5m0.0127478s)\n"
[12:33:37.625][WindowsDaemon     ][Info   ] debug: Client context cancelled, stop sending events
[12:33:37.625][WindowsDaemon     ][Info   ] debug: Calling GET /v1.40/events
[12:34:07.999][ApiProxy          ][Info   ] time="2019-08-31T12:34:07+01:00" msg="proxy >> HEAD /_ping\n"
[12:34:08.000][ApiProxy          ][Info   ] time="2019-08-31T12:34:08+01:00" msg="proxy << HEAD /_ping (960.1µs)\n"
[12:34:08.000][WindowsDaemon     ][Info   ] debug: Calling HEAD /_ping
[12:34:24.248][ApiProxy          ][Info   ] time="2019-08-31T12:34:24+01:00" msg="proxy >> HEAD /_ping\n"
[12:34:24.249][ApiProxy          ][Info   ] time="2019-08-31T12:34:24+01:00" msg="proxy << HEAD /_ping (604.7µs)\n"
[12:34:24.249][WindowsDaemon     ][Info   ] debug: Calling HEAD /_ping
[12:34:24.319][ApiProxy          ][Info   ] time="2019-08-31T12:34:24+01:00" msg="proxy >> POST /v1.40/build?buildargs=%7B%7D&cachefrom=%5B%5D&cgroupparent=&cpuperiod=0&cpuquota=0&cpusetcpus=&cpusetmems=&cpushares=0&dockerfile=Dockerfile&labels=%7B%7D&memory=0&memswap=0&networkmode=default&rm=1&shmsize=0&t=imago&target=&ulimits=null&version=1\n"
[12:34:24.322][WindowsDaemon     ][Info   ] debug: Calling POST /v1.40/build?buildargs=%7B%7D&cachefrom=%5B%5D&cgroupparent=&cpuperiod=0&cpuquota=0&cpusetcpus=&cpusetmems=&cpushares=0&dockerfile=Dockerfile&labels=%7B%7D&memory=0&memswap=0&networkmode=default&rm=1&shmsize=0&t=imago&target=&ulimits=null&version=1
[12:34:24.333][APIRequestLogger  ][Info   ] [20c7428a-3942-4c99-8ec7-2a6d8a28aa8b] POST http://unix/usage
[12:34:24.334][APIRequestLogger  ][Info   ] [20c7428a-3942-4c99-8ec7-2a6d8a28aa8b] POST http://unix/usage -> 200 OK took 0ms
[12:34:24.331][WindowsDaemon     ][Info   ] debug: [BUILDER] Cache miss: [powershell #(nop)  SHELL [powershell]]
[12:34:24.332][WindowsDaemon     ][Info   ] debug: [BUILDER] Command to be executed: [powershell #(nop)  SHELL [powershell]]
[12:34:24.339][WindowsDaemon     ][Info   ] debug: hcsshim::GetLayerMountPath [path=C:\ProgramData\Docker\windowsfilter\9999b28a8a8d2410b5363df8f12de229ee6f211fb8951475d66df081ca76739a]
[12:34:24.339][WindowsDaemon     ][Info   ] debug: Calling proc (1) [path=C:\ProgramData\Docker\windowsfilter\9999b28a8a8d2410b5363df8f12de229ee6f211fb8951475d66df081ca76739a]
[12:34:24.340][WindowsDaemon     ][Info   ] debug: Calling proc (2) [path=C:\ProgramData\Docker\windowsfilter\9999b28a8a8d2410b5363df8f12de229ee6f211fb8951475d66df081ca76739a]
[12:34:24.341][WindowsDaemon     ][Info   ] debug: hcsshim::GetLayerMountPath - succeeded [path=C:\ProgramData\Docker\windowsfilter\9999b28a8a8d2410b5363df8f12de229ee6f211fb8951475d66df081ca76739a mountPath=C:\ProgramData\Docker\windowsfilter\9999b28a8a8d2410b5363df8f12de229ee6f211fb8951475d66df081ca76739a]
[12:34:24.341][WindowsDaemon     ][Info   ] debug: hcsshim::CreateScratchLayer [path=C:\ProgramData\Docker\windowsfilter\3fc8deaedda003cd59c6271c75e58b3e8e8260949af59c3bdee500a4bff6b53c]
[12:34:24.342][WindowsDaemon     ][Info   ] debug: hcsshim::NameToGuid [name=9999b28a8a8d2410b5363df8f12de229ee6f211fb8951475d66df081ca76739a]
[12:34:24.342][WindowsDaemon     ][Info   ] debug: hcsshim::NameToGuid - succeeded [name=9999b28a8a8d2410b5363df8f12de229ee6f211fb8951475d66df081ca76739a guid=8265635e-a19c-5afe-bf46-1a9fa9262751]
[12:34:24.349][WindowsDaemon     ][Info   ] debug: hcsshim::CreateScratchLayer - succeeded [path=C:\ProgramData\Docker\windowsfilter\3fc8deaedda003cd59c6271c75e58b3e8e8260949af59c3bdee500a4bff6b53c]
[12:34:24.371][WindowsDaemon     ][Info   ] debug: WindowsGraphDriver Get() id 3fc8deaedda003cd59c6271c75e58b3e8e8260949af59c3bdee500a4bff6b53c mountLabel 
[12:34:24.371][WindowsDaemon     ][Info   ] debug: hcsshim::ActivateLayer [path=C:\ProgramData\Docker\windowsfilter\3fc8deaedda003cd59c6271c75e58b3e8e8260949af59c3bdee500a4bff6b53c]
[12:34:24.394][WindowsDaemon     ][Info   ] debug: hcsshim::ActivateLayer - succeeded [path=C:\ProgramData\Docker\windowsfilter\3fc8deaedda003cd59c6271c75e58b3e8e8260949af59c3bdee500a4bff6b53c]
[12:34:24.395][WindowsDaemon     ][Info   ] debug: hcsshim::PrepareLayer [path=C:\ProgramData\Docker\windowsfilter\3fc8deaedda003cd59c6271c75e58b3e8e8260949af59c3bdee500a4bff6b53c]
[12:34:24.395][WindowsDaemon     ][Info   ] debug: hcsshim::NameToGuid [name=9999b28a8a8d2410b5363df8f12de229ee6f211fb8951475d66df081ca76739a]
[12:34:24.396][WindowsDaemon     ][Info   ] debug: hcsshim::NameToGuid - succeeded [name=9999b28a8a8d2410b5363df8f12de229ee6f211fb8951475d66df081ca76739a guid=8265635e-a19c-5afe-bf46-1a9fa9262751]
[12:34:24.398][WindowsDaemon     ][Error  ] hcsshim::PrepareLayer - failed failed in Win32: Incorrect function. (0x1) [path=C:\ProgramData\Docker\windowsfilter\3fc8deaedda003cd59c6271c75e58b3e8e8260949af59c3bdee500a4bff6b53c error=hcsshim::PrepareLayer - failed failed in Win32: Incorrect function. (0x1)]
[12:34:24.399][WindowsDaemon     ][Info   ] debug: hcsshim::DeactivateLayer [path=C:\ProgramData\Docker\windowsfilter\3fc8deaedda003cd59c6271c75e58b3e8e8260949af59c3bdee500a4bff6b53c]
[12:34:24.401][WindowsDaemon     ][Info   ] debug: hcsshim::DeactivateLayer - succeeded [path=C:\ProgramData\Docker\windowsfilter\3fc8deaedda003cd59c6271c75e58b3e8e8260949af59c3bdee500a4bff6b53c]
[12:34:24.403][ApiProxy          ][Info   ] time="2019-08-31T12:34:24+01:00" msg="proxy << POST /v1.40/build?buildargs=%7B%7D&cachefrom=%5B%5D&cgroupparent=&cpuperiod=0&cpuquota=0&cpusetcpus=&cpusetmems=&cpushares=0&dockerfile=Dockerfile&labels=%7B%7D&memory=0&memswap=0&networkmode=default&rm=1&shmsize=0&t=imago&target=&ulimits=null&version=1 (84.2395ms)\n"
[12:34:24.403][ApiProxy          ][Info   ] time="2019-08-31T12:34:24+01:00" msg="Cancel connection..."
[12:34:24.403][ApiProxy          ][Warning] time="2019-08-31T12:34:24+01:00" msg="ignored error: The handle is invalid."
[12:34:56.593][WindowsDaemon     ][Error  ] svchost (8408,R,98) TILEREPOSITORYS-1-5-18: Error -1023 (0xfffffc01) occurred while opening logfile C:\WINDOWS\system32\config\systemprofile\AppData\Local\TileDataLayer\Database\EDB.log.
TheRichCarey commented 5 years ago

Confirmed on a fresh install of Windows 10 this afternoon too. Also 1903 Build 18362.295

I am slightly concerned as this effectively means docker is now incompatible with Windows? Is this even the right repo to report this, as there hasn't been any improvement since May? @mikeparker

michaelbaranov commented 5 years ago

The same here: Windows 10 1903 Build 18362.329 Docker Desktop 2.1.0.2 (37877)

hcsshim::PrepareLayer - failed failed in Win32: Incorrect function. (0x1)

PhilLepanto commented 5 years ago

I'm running Docker Desktop 2.1.0.2 (37877) and Windows 10 1903 (18970.1005)

I get these hcsshim errors constantly.

Tam-FPT commented 5 years ago

Mine are:

C:>hcsshim::PrepareLayer - failed failed in Win32: Incorrect function. (0x1)

Hope there will be someone have a solution how to fix it.

jrad88 commented 5 years ago

It has been 4 months now. This issue is very common, if not 100% of users on 1903, and there has not been any meaningful updates from any party in weeks to say that the issue going to ever be addressed, or even a timeline for when we can expect a fix to come. As far as we know, Docker will no longer be supported by Microsoft going forward, and everyone should just pack up their containers and move on to a proper OS.

This is truly shameful in terms of transparency and support. To say that Docker for Windows isn't ready for "production" is an overstatement. It's not even ready as "proof of concept." It literally does not even begin to function correctly, and it barely even installs correctly. Updates don't even restart the daemon. This whole thing might as well be relegated to insider builds, which also don't work anymore, but at least those people sign up to be beta testers.

The mind boggles. I can't even believe this is the world we live in. Shameful.

rdissertori commented 5 years ago

3 different machines - all of them fail with hcsshim::PrepareLayer - failed failed in Win32: Incorrect function. (0x1) on docker copy and build operations on all of those 3 machines 100% reproducable

mikeparker commented 5 years ago

I can't reproduce this with the original instructions on a windows machine running 1903 (running visual studio asp.net core project with docker support on windows containers)

I wonder if this is only on nested virtualization environments? Can anyone confirm if they are seeing this when running docker desktop on bare metal (normal desktop PCs) or only seeing this on a virtual machine (e.g. mac parallels, vmware fusion, or on azure/AWS etc)?

If anyone could upload a manual diagnostic and link the ID here that would help too (Docker Desktop -> Troubleshoot)

jbolduan commented 5 years ago

I can't reproduce this with the original instructions on a windows machine running 1903 (running visual studio asp.net core project with docker support on windows containers)

I wonder if this is only on nested virtualization environments? Can anyone confirm if they are seeing this when running docker desktop on bare metal (normal desktop PCs) or only seeing this on a virtual machine (e.g. mac parallels, vmware fusion, or on azure/AWS etc)?

If anyone could upload a manual diagnostic and link the ID here that would help too (Docker Desktop -> Troubleshoot)

I get this on multiple bare metal machines (laptops) I've never tried running inside a VM. I've downgraded all my machines but I'll see if I can upgrade one to 1903 and pull the troubleshooting logs there.

I've tried multiple computers and every one of them when upgraded to 1903 has issues running anything more complicated than just building the OS in docker. It won't copy files or run commands in a dockerfile.

metrotyranno commented 5 years ago

I can't reproduce this with the original instructions on a windows machine running 1903 (running visual studio asp.net core project with docker support on windows containers)

I wonder if this is only on nested virtualization environments? Can anyone confirm if they are seeing this when running docker desktop on bare metal (normal desktop PCs) or only seeing this on a virtual machine (e.g. mac parallels, vmware fusion, or on azure/AWS etc)?

If anyone could upload a manual diagnostic and link the ID here that would help too (Docker Desktop -> Troubleshoot)

I got this on a clean install of 1903 (non nested), the issue presents itself when building containers (any commands other than FROM) using the Docker REST API

39DA8DF3-CB92-4B06-9781-39B6639AC37B/20190910163057

TheRichCarey commented 5 years ago

@mikeparker confirming as per @jbolduan. Bare metal laptop and desktop both behave the same.

Ran diagnostics: 786C451A-F17F-47F9-B78D-1A78A33B8DBB/20190910154930 System spec and versions above

jrad88 commented 5 years ago

Bare metal, desktop, just doing "hello docker." This machine has nothing out of the ordinary installed. Chrome, Visual Studio 2015, no personal stuff (it's only used for automation).

Sending build context to Docker daemon 2.048kB Step 1/2 : FROM mcr.microsoft.com/windows/nanoserver:1903 1903: Pulling from windows/nanoserver d29f8f3689f8: Pull complete Digest: sha256:de4e46be4ebc593c815ae6ad17a33eb89481c85276b46d96c000f31aedc8cb67 Status: Downloaded newer image for mcr.microsoft.com/windows/nanoserver:1903 ---> e2d2723b0704 Step 2/2 : SHELL ["powershell"] ---> Running in 1c7221fcb360 hcsshim::PrepareLayer - failed failed in Win32: Incorrect function. (0x1)

C5B34F0E-5C57-48BF-801C-6E335490A0DC/20190910181628

Tam-FPT commented 5 years ago

I can't reproduce this with the original instructions on a windows machine running 1903 (running visual studio asp.net core project with docker support on windows containers)

I wonder if this is only on nested virtualization environments? Can anyone confirm if they are seeing this when running docker desktop on bare metal (normal desktop PCs) or only seeing this on a virtual machine (e.g. mac parallels, vmware fusion, or on azure/AWS etc)?

If anyone could upload a manual diagnostic and link the ID here that would help too (Docker Desktop -> Troubleshoot)

I confirm the error occurs on my physical PC (laptop), the system spec was in my previous comment. Diagnose upload id: 58DF5DC3-7245-468F-8F8E-6AD6F1AAD7D2/20190910181226

moo-ecxio commented 5 years ago 
docker cp [container_id]:[container_path] [host_path]
Error response from daemon: hcsshim::PrepareLayer - failed failed in Win32: Incorrect function. (0x1)

Diagnostic id: BDA82EB8-C038-456F-B5DD-7D38429A99B0/20190911062723

hcsshim::PrepareLayer - failed failed in Win32: Incorrect function. (0x1)
Process 'docker.exe' exited with code 1.
> "C:\Program Files\Docker\Docker\Resources\bin\docker.exe" build --file base/sitecore/Dockerfile --isolation process --tag sitecore-base-sitecore:9.1.1 .
@ C:\Users\[USERNAME]\[ProjectFolder]
Error output:
hcsshim::PrepareLayer - failed failed in Win32: Incorrect function. (0x1)

Diagnostic id: BDA82EB8-C038-456F-B5DD-7D38429A99B0/20190911063620

Also on a physical Device (Laptop)

StefanScherer commented 5 years ago

Thanks @metrotyranno @Wabbbit @jrad88 @Tam-FPT @moo-ecxio for the diagnostic data.

I also had a look at this issue and tried to reproduce the problem described with the several simple Dockerfiles that all were mentioned above.

I tested four different Win 10 1903 machines (all baremetal) today both with Docker Desktop Enterprise and then with Docker Desktop Community Stable 2.1.0.2, but with none I could reproduce the problem. I even created a fresh Win 10 1903 machine with latest updates from yesterday 19362.356 and DD 2.1.0.2 Stable, but it also works and I even could build a bigger image with MSBuild command line tools inside. I haven't modified my daemon.json at all.

So, we're still looking how to reproduce it on our test machines, but we have some hints here.

metrotyranno commented 5 years ago

The peculiar thing for me is that building using the REST api causes the error, but using powershell it does not.

`[2019-09-11T20:49:01.049Z] INFO: host/13660 on DESKTOP-JUVS3BT: Bunyan initialized. [2019-09-11T20:49:01.087Z] INFO: host/13660 on DESKTOP-JUVS3BT: Docker connection: OK [2019-09-11T20:49:01.094Z] INFO: host/13660 on DESKTOP-JUVS3BT: Connected to core [2019-09-11T20:49:01.275Z] INFO: host/13660 on DESKTOP-JUVS3BT: Socket authenticated, machine ID: 1 [2019-09-11T20:49:01.423Z] DEBUG: host/13660 on DESKTOP-JUVS3BT: minecraft | {"stream":"Step 1/8 : FROM mcr.microsoft.com/windows/servercore:ltsc2019"}

[2019-09-11T20:49:01.424Z] DEBUG: host/13660 on DESKTOP-JUVS3BT: minecraft | {"stream":"\n"}

[2019-09-11T20:49:01.424Z] DEBUG: host/13660 on DESKTOP-JUVS3BT: minecraft | {"stream":" ---\u003e b05c49cadc10\n"}

[2019-09-11T20:49:01.424Z] DEBUG: host/13660 on DESKTOP-JUVS3BT: minecraft | {"stream":"Step 2/8 : LABEL maintainer=\"Brandon van der Loo \u003cbvanderloo@dbmhosting.com\u003e\""} {"stream":"\n"}

[2019-09-11T20:49:01.603Z] DEBUG: host/13660 on DESKTOP-JUVS3BT: minecraft | {"stream":" ---\u003e Running in 1c00531f50d9\n"}

[2019-09-11T20:49:01.643Z] DEBUG: host/13660 on DESKTOP-JUVS3BT: minecraft | {"errorDetail":{"message":"hcsshim::PrepareLayer - failed failed in Win32: The parameter is incorrect. (0x57)"},"error":"hcsshim::PrepareLayer - failed failed in Win32: The parameter is incorrect. (0x57)"}`

And powershell:

Step 1/8 : FROM mcr.microsoft.com/windows/servercore:ltsc2019 ---> b05c49cadc10 Step 2/8 : LABEL maintainer="Brandon van der Loo <bvanderloo@dbmhosting.com>" ---> Running in e52e85f27fa5 Removing intermediate container e52e85f27fa5 ---> 277d995edc32 Step 3/8 : RUN powershell (new-object System.Net.WebClient).Downloadfile('https://javadl.oracle.com/webapps/download/AutoDL?BundleId=239858_230deb18db3e4014bb8e3e8324f81b43', 'C:\jre-windows-x64.exe') ---> Running in 853e4b856eb1 Removing intermediate container 853e4b856eb1 ---> ad33631df250 ...Continues and finishes

TheRichCarey commented 5 years ago

@StefanScherer I can confirm that I have just pulled the latest path to update to .356 and still get this. Are you running WSL2 on that machine (as I believe some have had success doing this).

Can you confirm if you enabled any windows features or did anything else on the machine other than run DD install on a fresh OS?

StefanScherer commented 5 years ago

@Wabbit Just a fresh Win 10 1903 machine, only Containers and Hyper-V features activated, then installer Docker Desktop. Only a few dev tools like git and java installed. There iso WSL2 on 1903, you need Insider builds (I saw some with OSVersion 18970.1005 above).

@metrotyranno What do you mean with API and powershell? Do you run docker build or are you calling the Docker API with some other tool/language?

metrotyranno commented 5 years ago

Using docker build on the dockerfile seems to execute properly (had issues with this before though, same error) but now I only get the error using the api docker exposes. (Using Dockerode for NodeJS)

[2019-09-11T21:42:30.489Z] INFO: host/3248 on DESKTOP-JUVS3BT: Bunyan initialized. [2019-09-11T21:42:30.529Z] INFO: host/3248 on DESKTOP-JUVS3BT: Docker connection: OK [2019-09-11T21:42:30.537Z] INFO: host/3248 on DESKTOP-JUVS3BT: Connected to core [2019-09-11T21:42:30.708Z] INFO: host/3248 on DESKTOP-JUVS3BT: Socket authenticated, machine ID: 1 [2019-09-11T21:42:30.870Z] DEBUG: host/3248 on DESKTOP-JUVS3BT: minecraft | Step 1/7 : FROM mcr.microsoft.com/windows/servercore:ltsc2019 [2019-09-11T21:42:30.870Z] DEBUG: host/3248 on DESKTOP-JUVS3BT: minecraft | [2019-09-11T21:42:30.870Z] DEBUG: host/3248 on DESKTOP-JUVS3BT: minecraft | ---> 1ddfa8bee56a [2019-09-11T21:42:30.871Z] DEBUG: host/3248 on DESKTOP-JUVS3BT: minecraft | Step 2/7 : LABEL maintainer="Brandon van der Loo bvanderloo@dbmhosting.com" [2019-09-11T21:42:30.871Z] DEBUG: host/3248 on DESKTOP-JUVS3BT: minecraft | [2019-09-11T21:42:31.066Z] DEBUG: host/3248 on DESKTOP-JUVS3BT: minecraft | ---> Running in c8a939856c67 [2019-09-11T21:42:31.132Z] FATAL: host/3248 on DESKTOP-JUVS3BT: message: hcsshim::PrepareLayer - failed failed in Win32: The parameter is incorrect. (0x57)

jrad88 commented 5 years ago

There's nothing remarkable about our hardware or software setup. It's just consumer grade equipment with Windows 10 Pro on 1903. Visual Studio 2015 is installed as we're trying to use Docker to replace the need for such requirements.

In the interest of science I've created a hyper-v VM on this machine, and can build docker containers from within hyper-v on a fresh install of windows 1903, no other software besides docker installed. However, once I change storage-opts, I'm seeing below:

Sending build context to Docker daemon 2.048kB Step 1/2 : FROM mcr.microsoft.com/windows/nanoserver:1903 1903: Pulling from windows/nanoserver d29f8f3689f8: Pull complete Digest: sha256:de4e46be4ebc593c815ae6ad17a33eb89481c85276b46d96c000f31aedc8cb67 Status: Downloaded newer image for mcr.microsoft.com/windows/nanoserver:1903 ---> e2d2723b0704 Step 2/2 : SHELL ["powershell"] ---> Running in 2f2ce54f77ad hcsshim::PrepareLayer - failed failed in Win32: The parameter is incorrect. (0x57)

That said, I am able to build my images within the hyper-v VM, as long as storage-opts are default. I could see about getting a bare metal machine (or a fresh install of the current machine) if it would be helpful. Meanwhile, I'll try replicating my environment (Visual Studio and all of the required SDKs) within this VM to see if at any point it breaks.

TheRichCarey commented 5 years ago

There's nothing remarkable about our hardware or software setup. It's just consumer grade equipment with Windows 10 Pro on 1903. Visual Studio 2015 is installed as we're trying to use Docker to replace the need for such requirements.

In the interest of science I've created a hyper-v VM on this machine, and can build docker containers from within hyper-v on a fresh install of windows 1903, no other software besides docker installed. However, once I change storage-opts, I'm seeing below:

Sending build context to Docker daemon 2.048kB Step 1/2 : FROM mcr.microsoft.com/windows/nanoserver:1903 1903: Pulling from windows/nanoserver d29f8f3689f8: Pull complete Digest: sha256:de4e46be4ebc593c815ae6ad17a33eb89481c85276b46d96c000f31aedc8cb67 Status: Downloaded newer image for mcr.microsoft.com/windows/nanoserver:1903 ---> e2d2723b0704 Step 2/2 : SHELL ["powershell"] ---> Running in 2f2ce54f77ad hcsshim::PrepareLayer - failed failed in Win32: The parameter is incorrect. (0x57)

That said, I am able to build my images within the hyper-v VM, as long as storage-opts are default. I could see about getting a bare metal machine (or a fresh install of the current machine) if it would be helpful. Meanwhile, I'll try replicating my environment (Visual Studio and all of the required SDKs) within this VM to see if at any point it breaks.

This looks like a different issue from others who cannot build at all within 1903?

It looks like the only solution now is to basically wait for 19H2 which may resolve this with the ability to use WSL2, but isn't a guarantee.

jrad88 commented 5 years ago

hcsshim::PrepareLayer - failed failed in Win32: The parameter is incorrect. (0x57)

I'm not sure if that issue is related to this or not. The error codes are different, and it seems like having storage-opts defined should be something that is supported, but I don't know if that is an existing issue here or not. Again, this happens on a fresh install.

hcsshim::PrepareLayer - failed failed in Win32: Incorrect function. (0x1)

My issue turned out to be related to a file system driver installed with one of our required SDKs. I'll escalate that issue with that team, since it seems unrelated here and could be subject to NDA. I can also check newer versions of that SDK since we're a bit behind. Once I removed this driver, I can build again without errors.

olivier-haddad commented 5 years ago

@jrad88 You seem to be the only one that found a hint (and a fix) for the "Incorrect function" error. Could it be that the driver was called (by a hook) by the PrepareLayer function? As for the number of people affected by this issue, it would help to know a bit more. Is it an internal SDK or a publicly available one that you could disclose? In my case, I am working on a laptop clean of non-standard drivers: no esoteric hardware or stuff... I am reluctantly thinking of going the WinDbg way in order to find the culprit but this would be painstakingly long endeavor. I'd rather have MS do it.

Geogboe commented 5 years ago

@olivier-haddad I had windbg installed so I fired it up and attached to dockerd but I'm not really seeing anything super useful ( in my eyes ).

onecore\vm\compute\shared\storage\layerutilities.cpp(46)\vmcompute.dll!00007FF899CACD3B: (caller: 00007FF899C8594C) Exception(8) tid(55c) 80070001 Incorrect function.
(3e68.55c): C++ EH exception - code e06d7363 (first chance)
(3e68.55c): C++ EH exception - code e06d7363 (first chance)
onecore\vm\compute\dll\legacy\src\graphdriver.cpp(850)\vmcompute.dll!00007FF899C8121A: (caller: 00007FF899C8111E) LogHr(8) tid(55c) 80070001 Incorrect function.
    Msg:[onecore\vm\compute\shared\storage\layerutilities.cpp(46)\vmcompute.dll!00007FF899CACD3B: (caller: 00007FF899C8594C) Exception(8) tid(55c) 80070001 Incorrect function.

Granted I'm not a developer and I don't really know how to use windbg. If anyone has debugging suggestions I'm happy to try them out.

olivier-haddad commented 5 years ago

@Geogboe vmcompute.dll seems to belong to the HyperV host. On the other hand 0x80070001 can come from a corrupted file or a bad windows configuration (registry). I wonder if one of the windows updates broke the compatibility between docker and HyperV.

I tried to remove the containers feature and add it back but it didn't help. Hopefully, knowing what was the driver that broke @jrad88's docker will shed some new light.

moo-ecxio commented 5 years ago

Well it could be a driver related issue here, would make sense too because of the 1903 upgrade. I was now able to test it from another device at home (privately) - the very same tasks that failed at work seems to work there.

konkola commented 5 years ago

In our case this error seems to be related to /n software (https://www.nsoftware.com) CBFS driver (CallBack FileSystem) we are using. When I uninstalled the driver, the error didn't come any more.

Geogboe commented 5 years ago

@konkola Any idea how you discovered this driver or what clued you in to that specific one? I want to look on my system for maybe similar ones to remove.

ghost commented 5 years ago

@StefanScherer The common error seems to be hcsshim::PrepareLayer, and in our case it fails on hcsshim::ImportLayer. If you are not able to reproduce it, could you give us a way to send you enough information to understand where is the bug? I really don't know what to do except go back to the previous Windows version and wait until it is fixed. Is this the only way around?

imphasing commented 5 years ago

This comment has a link to a gist that works for my whole team, it’s a c program that patches the vmcompute.dll in dockerd: https://github.com/microsoft/hcsshim/issues/624#issuecomment-509526835

I posted this before but my comments were all deleted lol, conspiracy?

Pretty sure this can be fixed fairly simply by windows fixing vmcompute.dll, or maybe by dockerd not calling the function like that.

I had to make minor changes to that gist to make it work in visual studio vc++ on 64 bit, working on getting it approved for release as open source but this solution works fine and allows many people on my team to build

konkola commented 5 years ago

@konkola Any idea how you discovered this driver or what clued you in to that specific one? I want to look on my system for maybe similar ones to remove.

@Geogboe A posting by @jrad88 gave me a hint:

"My issue turned out to be related to a file system driver installed with one of our required SDKs."

RaymondKHessel commented 5 years ago

@StefanScherer I experienced the same issue (Windows 10 Pro on 1903 failing to build a Windows image with 'hcsshim::PrepareLayer - failed failed in Win32: Incorrect function. (0x1)').

With Docker for Windows 2.1.0.1 I was able to fix the issue in two different ways:

  1. Uninstalling Boxcryptor (Boxcryptor installs a file system driver, and I guess that is where the issue came from).
  2. Using the patch mentioned here: https://github.com/microsoft/hcsshim/issues/624#issuecomment-509526835

I hope that helps.

konkola commented 5 years ago

@RaymondKHessel If I remember right, Boxcryptor uses the same driver I mentioned before, /n Software CBFS driver. I think they call it "CBFS Connect".

TheRichCarey commented 5 years ago

@RaymondKHessel If I remember right, Boxcryptor uses the same driver I mentioned before, /n Software CBFS driver. I think they call it "CBFS Connect".

That may make sense as all my machines run BoxCryptor, and BC does use CBFS, it would also tie in with @konkola comment about that driver too with different software

@jrad88 are you able to confirm your issue was this driver?

moo-ecxio commented 5 years ago

either way - I'm waiting for a fix too. I just can't get comfortable with "workarounds" also I have bitlocker encryption - maybe that's an issue too.

michaelbaranov commented 5 years ago

Uninstall of cbfsconnect2 driver fixes the problem. In my setup it was installed with Box client

StefanScherer commented 5 years ago

Thanks @RaymondKHessel Yes, I've installed Boxcryptor on a test machine and could reproduce the problem. After uninstalling it the next docker build was fine again.

olivier-haddad commented 5 years ago

Does anyone know what other applications use this driver? I looked on the "CallbackTechnologies" web site but couldn't find any application I knowingly use. My dev machine include a fairly large number of "standard" frameworks and tools including Office, Avast, Visual Studio, Matlab, python, opencv, rabbitmq, WD Discovery, HyperV manager and Docker of course...

Using ProcessExplorer, I tried to look for a handle (dll, file or other) that includes "cbfs" in its name but couldn't find anything.

Of course it could be another similar driver that causes the same problem.

Geogboe commented 5 years ago

Along with what @olivier-haddad said, does anyone know of a driver query command that will specific list file system drivers or something?

Maybe this will help? driverquery.exe /v /fo csv | ConvertFrom-Csv | Where "Driver Type" -match "File System" | ft "Module Name", "Display Name", Description, "Start Mode", Path, Status -AutoSize"

Except for my AV, which I will try removing, everything else seems normal Microsoft

TheRichCarey commented 5 years ago

Along with what @olivier-haddad said, ~does anyone know of a driver query command that will specific list file system drivers or something?~

Maybe this will help? driverquery.exe /v /fo csv | ConvertFrom-Csv | Where "Driver Type" -match "File System" | ft "Module Name", "Display Name", Description, "Start Mode", Path, Status -AutoSize"

Except for my AV, which I will try removing, everything else seems normal Microsoft

If I remove the filter and pipe it out to a text file I can see "cbfsconnect2 (cbfsconnect2017)" which would be the incompatible driver.

If I uninstall BoxCryptor which utilises CBFS, it would then work. Post reinstall I can also rebuild the previously built images (as they are cached) If I then append a build step to the dockerfile though, it then reverts back to the failure

ancientmidi commented 5 years ago

Removing the filter on the driverquery worked for me too. I found two files with the same timestamp in my system32/drivers. cbfs6.sys and vpnpbus.sys. Renamed both files since I couldn't find what put them there, rebooted and I'm past the error.

Tam-FPT commented 5 years ago

I confirm it works now when I renamed 2 files in system32/drivers: cbfs6.sys, cbfsconnect2017.sys Reboot and now I can run the docker build without error.

Geogboe commented 5 years ago

So it sounds like the issue is related to cbfs6.sys even though it's not a file system driver but a kernel driver? I don't have cbfsconnect2017 or vpnpbus.sys on my system though so it must be something else for me. Anyone know of a way to find out what drivers an application might be utilizing? I tried process explorer and process monitor but didn't see anything.

olivier-haddad commented 5 years ago

@Geogboe cbfs6.sys or anything starting with cbfs neither are on my system. I still think it is related and we may have similar drivers installed by an update or another application that cause the same issue.

npross commented 5 years ago

Hi, I've just come across this thread and am experiencing exactly the same symptoms ie. hcsshim::PrepareLayer - failed failed in Win32: The parameter is incorrect. (0x57) when storage-opt is defined. This is a brand new laptop for me and I just got it upgraded to 1903. I just have vanilla windows drivers. I really need to build containers > 20GB. (I was hoping to use my new laptop to figure out why my docker builds on server 2019ltsc are failing at work.. oh well.. guess i'll go back to hyper-v isolation)

moo-ecxio commented 5 years ago

nice - just received a firmware update for my workstations. it definitly seems like some driver related issue, because now it works

Mezzenine commented 5 years ago

@StefanScherer I experienced the same issue (Windows 10 Pro on 1903 failing to build a Windows image with 'hcsshim::PrepareLayer - failed failed in Win32: Incorrect function. (0x1)').

With Docker for Windows 2.1.0.1 I was able to fix the issue in two different ways:

  1. Uninstalling Boxcryptor (Boxcryptor installs a file system driver, and I guess that is where the issue came from).
  2. Using the patch mentioned here: microsoft/hcsshim#624 (comment)

I hope that helps.

I can confirm, uninstalling boxcryptor solved this issue "hcsshim::PrepareLayer - failed failed in Win32: Incorrect function. (0x1)" for me.

mitchcapper commented 5 years ago

@npross there are two separate issues here. 0x57 is related to the fact any storage driver size option greater than the default 20G will prevent docker from running any containers. 0x1 error is a different error that seems to be patch in the latest build. Sadly containers > 20G seem broken for 1903 and onward.