Cannot run container with more than 3GB memory

[apetres]

Expected behavior

docker run -m 5GB microsoft/windowsservercore creates a container with 5GB memory (the amount can be 4GB or greater)

Actual behavior

An error message is displayed:

C:\Program Files\Docker\Docker\Resources\bin\docker.exe: Error response from daemon: container f6d27506ece6b1135a8d92b142f0e81802046dc3a8c05c2e99c8dfde54679a0e encountered an error during CreateContainer: failure in a Windows system call: The handle is invalid. (0x6).

Information

• Diagnostic ID: A19C16A5-CD97-47EF-9F8C-56D98C885C03/2017-09-14_14-30-32
• Docker version: 17.06.0-ce-rc4
• OS: Windows 10 Version 1607 Build 14393.1593
• Memory: 16GB from which at least 10GB was free at the time of reproduction

If the memory specified is less or equal then 3GB, the container runs successfully, so I don't think this is a network-related issue. I tried to reproduce the issue on another machine with the same version of Docker, without success (meaning that I could create a container with more than 3GB memory).

Could you recommend a way of debugging this issue? (Side question: could you recommend a way to obtain more detailed error message from docker? In this case it would help if I know what kind of handle is invalid)

Steps to reproduce the behavior

1. run docker run -m 5GB microsoft/windowsservercore

[friism]

cc @darrenstahlmsft

[darstahl]

What is the output of docker info?

This failure is in the Windows platform, not Docker, which is why Docker is not able to provide a better error message.

As a first step, run Debug-ContainerHost.ps1 from here

Hopefully the real error is in the event logs (The invalid handle is just a red herring) and that script will pick it up, otherwise I can provide more detailed logging instructions.

[apetres]

Checked the HyperV event logs, unfortunately they were not helpful: Hyper-V-Worker:

d3a8b277e07cf442a5a56f50c9d9881443ce6d8c8db1081c75921c878fe08d5f' has encountered a fatal error.  The guest operating system reported that it failed with the following error codes: ErrorCode0: 0x1A, ErrorCode1: 0x61941, ErrorCode2: 0xFFFFB7FFC0000000, ErrorCode3: 0xB, ErrorCode4: 0xFFFFA80109DEA6E0.  If the problem persists, contact Product Support for the guest operating system.  (Virtual machine ID 3F20FB44-3E6D-45C1-A4B7-EF27ECA11900)

Hyper-V-Compute:

The description for Event ID 12000 from source Microsoft-Windows-Hyper-V-Compute cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

I ran Debug-ContainerHost.ps1, all tests passed. The ouput (includes docker info):

PS C:\> .\Debug-ContainerHost.ps1
Describing Windows Version and Prerequisites
 [+] Is Windows 10 Anniversary Update or Windows Server 2016 540ms
 [+] Has KB3192366, KB3194496, or later installed if running Windows build 14393 117ms
 [+] Is not a build with blocking issues 22ms
Describing Docker is installed
 [+] A Docker service is installed - 'Docker' or 'com.Docker.Service'  72ms
 [+] Service is running 23ms
 [+] Docker.exe is in path 2.07s
Describing User has permissions to use Docker daemon
 [+] docker.exe should not return access denied 40ms
Describing Windows container settings are correct
 [+] Do not have DisableVSmbOplock set to 1 36ms
 [+] Do not have zz values set 30ms
Describing The right container base images are installed
 [+] At least one of 'microsoft/windowsservercore' or 'microsoft/nanoserver' should be installed 173ms
Describing Container network is created
 [+] At least one local container network is available 1.87s
 [+] No more than one NAT network 22ms
 [+] NAT Network's internal prefix does not overlap with external IP' 46ms
Showing output from: docker info
Containers: 2
 Running: 1
 Paused: 0
 Stopped: 1
Images: 153
Server Version: 17.06.0-ce-rc4
Storage Driver: windowsfilter
 Windows:
Logging Driver: json-file
Plugins:
 Volume: local
 Network: l2bridge l2tunnel nat null overlay transparent
 Log: awslogs etwlogs fluentd json-file logentries splunk syslog
Swarm: inactive
Default Isolation: hyperv
Kernel Version: 10.0 14393 (14393.1715.amd64fre.rs1_release_inmarket.170906-1810)
Operating System: Windows 10 Pro
OSType: windows
Architecture: x86_64
CPUs: 8
Total Memory: 15.89GiB
Name: machineName
ID: machineID
Docker Root Dir: C:\ProgramData\Docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: -1
 Goroutines: 33
 System Time: 2017-09-19T08:29:55.2363201+02:00
 EventsListeners: 0
Http Proxy: http://proxy.xyz:1234
Https Proxy: http://proxy.xyz:1234
No Proxy: noproxylist
Registry: https://index.docker.io/v1/
Experimental: true
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Showing output from: docker version
Client:
 Version:      17.06.0-ce-rc4
 API version:  1.30
 Go version:   go1.8.3
 Git commit:   29fcd5d
 Built:        Thu Jun 15 17:27:29 2017
 OS/Arch:      windows/amd64

Server:
 Version:      17.06.0-ce-rc4
 API version:  1.30 (minimum version 1.24)
 Go version:   go1.8.3
 Git commit:   29fcd5d
 Built:        Thu Jun 15 17:39:44 2017
 OS/Arch:      windows/amd64
 Experimental: true

Showing output from: docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
d4283fd142cc        nat                 nat                 local
f66f30c0b923        none                null                local

Warnings & errors from the last 24 hours

   ProviderName: Microsoft-Windows-Hyper-V-Compute

TimeCreated                     Id LevelDisplayName Message
-----------                     -- ---------------- -------
9/19/2017 8:25:48 AM         12000 Error
9/18/2017 5:07:33 PM         12000 Error
9/18/2017 12:12:17 PM        12000 Error
9/18/2017 10:55:55 AM        12000 Error

[darstahl]

Sorry for the delay, lots going on. Fortunately I work on the Hyper-V team, so these error codes are useful to me 😄

The utility VM is crashing during first boot due to a memory access violation. I'm working on getting debug steps for this from some internal folks, but it's failing in a place that's tough to get useful logs from without a debugger attached.

First, I have a hunch this may be due to processor address widths. Could you reply with the output of the following Powershell command on both the working machine, as well as the failing machine:

Get-WmiObject win32_Processor | fl *

I'll get back with more complete debugging instructions soon. I'm very busy at the moment, so it might be a bit before I have full debug instructions.

[apetres]

The output of the command above on both machines: https://www.diffchecker.com/xf7hUTVq (left: working machine, right: not working machine)

[darstahl]

Nothing obvious from those. I'll provide more detailed debugging instructions as soon as I have time to test them myself.

[apetres]

@darrenstahlmsft thank you for looking into this issue! I'm looking forward for the debug instructions.

[apetres]

I ran into the memory limit on another machine, but in this case it was 2GB (it fails when creating a container with 3GB+ memory). Also the error message is different: error during CreateContainer: failure in a Windows system call: This operation returned because the timeout period expired.

On what does the amount of memory that can be allocated depend? Aslo @darrenstahlmsft could you be so kind to provide more detailed debugging instructions?

[darstahl]

The timeout due to memory limits is new to me. Is this a different Windows build? What is the output from docker info on that machine?

I don't have full details on what the memory limit depends on right now, but I'll get those. I'll see if I can find some docs.

I have some steps to get a crash dump from a teammate here at Microsoft, but neither of us are able to cause a crash in the UtilityVM (We've tried a number of ways, no dice) in order to confirm that the crash dump is correctly written, so it might take a few attempts to get this to work.

1. First, we need to preserve the utility VM sandbox on unexpected exit. Run the following in cmd:

   Reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Virtualization\Containers\Debug"   /v PreserveVmOnErrorDestruct  /t REG_DWORD  /d 1

2. Next we need to ensure the VM actually writes a crash dump when it crashes. This is the part I'm not 100% sure about, as I don't have a way to test it. Download the Dockerfile located at https://gist.github.com/darrenstahlmsft/3be9ebf0cc3a3ed236adcc7d10c9ba16, and build an image such as docker build -t crash <path to dockerfile>. I think this should contain the correct reg keys, but might need some tweaks here.
3. Repro the issue: docker run -m 5G crash
4. Collect the UVM sandbox and parent VHD. Find the Virtual Machine ID. This is easiest found in the event logs as per above, In the Hyper-V-Worker log, the log ends with (Virtual machine ID {GUID}) The sandbox will be under “C:\ProgramData\Microsoft\Windows\Hyper-V\Container Utility VM\{GUID}.vhdx” To find the parent utility VM template, run docker inspect microsoft/windowsservercore (crash is based of this image) and there will be a node in the json similar to:

   "GraphDriver": {
   "Data": {
       "dir": "C:\\ProgramData\\docker\\windowsfilter\\a3f4d6a1be94a4ecb29a928caf0924ad8dd62c57cd3bc83d6db045a1e90d8e61"
   },
   "Name": "windowsfilter"
   },

   The parent template is located at : C:\ProgramData\docker\windowsfilter\a3f4d6a1be94a4ecb29a928caf0924ad8dd62c57cd3bc83d6db045a1e90d8e61\UtilityVm\SystemTemplateBase.vhdx

Send both of those vhdx files to me at darst@microsoft.com and I can see if the crash produced a memory dump.

Don't forget to undo the registry change to enable preserving crashed VMs or your disk might fill up fast if they keep crashing

Reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Virtualization\Containers\Debug"   /v PreserveVmOnErrorDestruct  /t REG_DWORD  /d 0

Let me know if you have any issues with these steps.

[apetres]

Thanks for the instructions!

You are right, Windows version is the key. After upgrading the first machine to version 16299 (it had 14393 before) I got the same error message. More exactly, now I have two machines with the same hardware and the same Windows version. When I try run a container with 5GB memory I get the timeout issue mentioned above.

I had no issues following your steps, although note that the PreserveVmOnErrorDestruct registry setting did not work on build 14393 (VHDX files were not kept).

I sent the two VHDX files to the address provided by you.

[darstahl]

Got them. I'll let you know what we find.

Ah, yes, I understand what the new error is from. The new error is the real error, as the failure is that the VM fails to start, so we timeout while waiting for it to connect. The Handle is invalid error was caused by a second bug that caused some errors to be incorrectly labeled.

[darstahl]

@apetres I sent updated instructions via email, just updating here in case you missed them 😄

[SergeBerwert]

Hi, I have the same problem, my machine has 23gb of memory as soon as I try to start a container with 3 gb or more I got the timeout message.

[darstahl]

@SergeBerwert Can you post the output of Powershell command Get-WmiObject win32_Processor | fl * on the failing machine as well please? We've got the crash dump from above, and are investigating it, but more info on the details of the failing processor never hurts 😄

[SergeBerwert]

PSComputerName                          : WS01
Availability                            : 3
CpuStatus                               : 1
CurrentVoltage                          :
DeviceID                                : CPU0
ErrorCleared                            :
ErrorDescription                        :
LastErrorCode                           :
LoadPercentage                          : 21
Status                                  : OK
StatusInfo                              : 3
AddressWidth                            : 64
DataWidth                               : 64
ExtClock                                : 100
L2CacheSize                             : 1024
L2CacheSpeed                            :
MaxClockSpeed                           : 3301
PowerManagementSupported                : False
ProcessorType                           : 3
Revision                                : 10759
SocketDesignation                       : SOCKET 0
Version                                 :
VoltageCaps                             : 5
__GENUS                                 : 2
__CLASS                                 : Win32_Processor
__SUPERCLASS                            : CIM_Processor
__DYNASTY                               : CIM_ManagedSystemElement
__RELPATH                               : Win32_Processor.DeviceID="CPU0"
__PROPERTY_COUNT                        : 57
__DERIVATION                            : {CIM_Processor, CIM_LogicalDevice, CIM_LogicalElement, CIM_ManagedSystemElement}
__SERVER                                : WS01
__NAMESPACE                             : root\cimv2
__PATH                                  : \\WS01\root\cimv2:Win32_Processor.DeviceID="CPU0"
Architecture                            : 9
AssetTag                                : Fill By OEM
Caption                                 : Intel64 Family 6 Model 42 Stepping 7
Characteristics                         : 4
ConfigManagerErrorCode                  :
ConfigManagerUserConfig                 :
CreationClassName                       : Win32_Processor
CurrentClockSpeed                       : 3301
Description                             : Intel64 Family 6 Model 42 Stepping 7
Family                                  : 179
InstallDate                             :
L3CacheSize                             : 8192
L3CacheSpeed                            : 0
Level                                   : 6
Manufacturer                            : GenuineIntel
Name                                    : Intel(R) Xeon(R) CPU E31245 @ 3.30GHz
NumberOfCores                           : 4
NumberOfEnabledCore                     : 4
NumberOfLogicalProcessors               : 8
OtherFamilyDescription                  :
PartNumber                              : Fill By OEM
PNPDeviceID                             :
PowerManagementCapabilities             :
ProcessorId                             : BFEBFBFF000206A7
Role                                    : CPU
SecondLevelAddressTranslationExtensions : False
SerialNumber                            :
Stepping                                :
SystemCreationClassName                 : Win32_ComputerSystem
SystemName                              : WS01
ThreadCount                             : 8
UniqueId                                :
UpgradeMethod                           : 36
VirtualizationFirmwareEnabled           : False
VMMonitorModeExtensions                 : False
Scope                                   : System.Management.ManagementScope
Path                                    : \\WS01\root\cimv2:Win32_Processor.DeviceID="CPU0"
Options                                 : System.Management.ObjectGetOptions
ClassPath                               : \\WS01\root\cimv2:Win32_Processor
Properties                              : {AddressWidth, Architecture, AssetTag, Availability...}
SystemProperties                        : {__GENUS, __CLASS, __SUPERCLASS, __DYNASTY...}
Qualifiers                              : {dynamic, Locale, provider, UUID}
Site                                    :
Container                               :

[darstahl]

@apetres @SergeBerwert Just to confirm, the machines that this is failing on is a physical machine, not a VM or similar, correct?

Also, if you could post your current output of docker info, that would be great, as this could be affected by the host OS versions.

[apetres]

Yes, in my case both machines are physical machines. Output of docker info:

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 13
Server Version: 17.09.0-ce (17.06.0-ce-rc4 on the other machine)
Storage Driver: windowsfilter
 Windows:
Logging Driver: json-file
Plugins:
 Volume: local
 Network: ics l2bridge l2tunnel nat null overlay transparent
 Log: awslogs etwlogs fluentd json-file logentries splunk syslog
Swarm: inactive
Default Isolation: hyperv
Kernel Version: 10.0 16299 (16299.15.amd64fre.rs3_release.170928-1534)
Operating System: Windows 10 Pro
OSType: windows
Architecture: x86_64
CPUs: 8
Total Memory: 15.89GiB
Name: hostname
ID: id
Docker Root Dir: C:\ProgramData\Docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: -1
 Goroutines: 24
 System Time: 2017-12-04T09:31:01.977481+01:00
 EventsListeners: 0
Http Proxy: proxy
Https Proxy: proxy
No Proxy: noproxy
Registry: https://index.docker.io/v1/
Experimental: true
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

[SergeBerwert]

Yes this war the date from the Host Computer not the container. My Docker Info is:

Containers: 1
 Running: 0
 Paused: 0
 Stopped: 1
Images: 65
Server Version: 17.09.1-ce
Storage Driver: windowsfilter
 Windows:
Logging Driver: json-file
Plugins:
 Volume: local
 Network: ics l2bridge l2tunnel nat null overlay transparent
 Log: awslogs etwlogs fluentd json-file logentries splunk syslog
Swarm: active
 NodeID: co09nhhol9l76mhnru1h2e5yv
 Is Manager: true
 ClusterID: nvb1ltitevkdc9e87rvb9b8fe
 Managers: 1
 Nodes: 1
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Number of Old Snapshots to Retain: 0
  Heartbeat Tick: 1
  Election Tick: 3
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
  Force Rotate: 0
 Autolock Managers: false
 Root Rotation In Progress: false
 Node Address: 192.168.46.100
 Manager Addresses:
  192.168.46.100:2377
Default Isolation: hyperv
Kernel Version: 10.0 16299 (16299.15.amd64fre.rs3_release.170928-1534)
Operating System: Windows 10 Enterprise
OSType: windows
Architecture: x86_64
CPUs: 8
Total Memory: 23.93GiB
Name: WS01
ID: Y3D3:R5H6:MQHW:ASFQ:WGVI:QOFI:74PP:QRTX:RNGL:VMRP:MAZA:QWM6
Docker Root Dir: C:\ProgramData\docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: -1
 Goroutines: 137
 System Time: 2017-12-13T23:40:55.9493646+01:00
 EventsListeners: 0
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

[darstahl]

Just a small update. We're tracking this issue internally. This occurs on certain processors that don't support 1GB pages. We are not aware of any mitigations (other than using a different processor), and I don't have an ETA on a fix yet. I'll update as I know more.

[kine]

Having same problem (max 2GB usable, more fail). Physical machine with 16GB RAM. Procesor info:

PSComputerName : KSACEK Availability : 3 CpuStatus : 1 CurrentVoltage : 11 DeviceID : CPU0 ErrorCleared : ErrorDescription : LastErrorCode : LoadPercentage : 1 Status : OK StatusInfo : 3 AddressWidth : 64 DataWidth : 64 ExtClock : 100 L2CacheSize : 1024 L2CacheSpeed : MaxClockSpeed : 3901 PowerManagementSupported : False ProcessorType : 3 Revision : 14857 SocketDesignation : Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz Version : VoltageCaps : GENUS : 2 CLASS : Win32_Processor SUPERCLASS : CIM_Processor __DYNASTY : CIM_ManagedSystemElement RELPATH : Win32_Processor.DeviceID="CPU0" PROPERTY_COUNT : 57 DERIVATION : {CIM_Processor, CIM_LogicalDevice, CIM_LogicalElement, CIM_ManagedSystemElement} SERVER : KSACEK NAMESPACE : root\cimv2 PATH : \KSACEK\root\cimv2:Win32_Processor.DeviceID="CPU0" Architecture : 9 AssetTag : Fill By OEM Caption : Intel64 Family 6 Model 58 Stepping 9 Characteristics : 4 ConfigManagerErrorCode : ConfigManagerUserConfig : CreationClassName : Win32_Processor CurrentClockSpeed : 3901 Description : Intel64 Family 6 Model 58 Stepping 9 Family : 198 InstallDate : L3CacheSize : 8192 L3CacheSpeed : 0 Level : 6 Manufacturer : GenuineIntel Name : Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz NumberOfCores : 4 NumberOfEnabledCore : 1 NumberOfLogicalProcessors : 8 OtherFamilyDescription : PartNumber : Fill By OEM PNPDeviceID : PowerManagementCapabilities : ProcessorId : BFEBFBFF000306A9 Role : CPU SecondLevelAddressTranslationExtensions : False SerialNumber : Stepping : SystemCreationClassName : Win32_ComputerSystem SystemName : KSACEK ThreadCount : 2 UniqueId : UpgradeMethod : 1 VirtualizationFirmwareEnabled : False VMMonitorModeExtensions : False Scope : System.Management.ManagementScope Path : \KSACEK\root\cimv2:Win32_Processor.DeviceID="CPU0" Options : System.Management.ObjectGetOptions ClassPath : \KSACEK\root\cimv2:Win32_Processor Properties : {AddressWidth, Architecture, AssetTag, Availability...} SystemProperties : {GENUS, CLASS, SUPERCLASS, __DYNASTY...} Qualifiers : {dynamic, Locale, provider, UUID} Site : Container :

[NReilingh]

I'm also experiencing this issue with a Windows 10 host running inside VMware Fusion for macOS on an iMac (21.5-inch, Mid 2011) Intel(R) Core(TM) i5-2400S CPU @ 2.50GHz.

I was getting the same error message as OP for values > 3GB, but between 1.5 and 3 I got a different error:

C:\Program Files\Docker\Docker\Resources\bin\docker.exe:
  Error response from daemon: container ... encountered an error during CreateContainer:
    hcsshim: timeout waiting for notification

It ended up working with 1.5 gb, which is marginally better than the default 1GB, but the next largest I tried was 2.5, so maybe there's a higher limit for me that I can get to.

As far as mitigation is concerned, if it ultimately is a hardware restriction, it would be nice if docker could recognize this and throw a helpful error message (or warn and fallback to the highest possible supported memory size) when it catches itself being sent a -m that is beyond what the host can support. Of course fixing it in Hyper-V would be better.

[DominikGebhart]

Thank you @darrenstahlmsft for the update, this is important information to me.

I feared this issue is a general instability, which would kill my use-case. Now theres at least a way to work around it by choosing the right Host system.

I ran into the same issue on a Windows 10 physical machine when trying to set --memory 3g. I tested up to 2.25g worked fine, then i hit the timeout on docker run errorcode 0x5b4. Hyper-V Worker also returns errorcodes0 0x1A, errorcode: 0x61941.

Name : Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz ProcessorId : BFEBFBFF000306A9

I assume it doesn't support those hugepages.

Edit: Indeed, with the help of Coreinfo and the -f flag it shows to not support PAGE1GB

[MikhailTymchukDX]

Would you please provide more technical info on this? Why page size affects docker? Why this does not affect VMs running under Hyper-VMs?

[Fuchur-Flensburg]

Hi! We are having the same problem on different Machines. All are Windows 10 Machines (Version 1803) We would like to use Docker for Development for about 60 devleopers but this is a perfekt showkiller. Every machine has the support of 1GB page sizes.

We have a sopport-contract with MS. But MS does not support Docker. Is it possible to create the same Error only with the generated vhdx files (described in the Message from "darstahl" on 15 Nov 2017)

We were not able to figure out, how we could start the Hyper-V with these VHDX Files. This would help us a lot, because in that case MS would help us to solve this problem.

Thanks Thorben

[MikhailTymchukDX]

MS does not support Docker.

But it does support Windows Docker implementation. This bug looks like specific to implementation.

[Walwode]

same for me. Interesting part, it worked end of last year for a presentation, but after reinstallation of Windows 10 this year, i wasn't able to run any docker image with +3gb, anymore. Disadvantage: Dynamics NAV Docker Images require 3gb. Therefore i can't run any of those on my machine.

Get-WmiObject win32_Processor | fl Availability : 3 CpuStatus : 1 CurrentVoltage : 9 DeviceID : CPU0 ErrorCleared : ErrorDescription : LastErrorCode : LoadPercentage : 12 Status : OK StatusInfo : 3 AddressWidth : 64 DataWidth : 64 ExtClock : 100 L2CacheSize : 256 L2CacheSpeed : MaxClockSpeed : 2401 PowerManagementSupported : False ProcessorType : 3 Revision : 14857 SocketDesignation : CPU Socket - U3E1 Version : VoltageCaps : GENUS : 2 CLASS : Win32_Processor SUPERCLASS : CIM_Processor __DYNASTY : CIM_ManagedSystemElement RELPATH : Win32_Processor.DeviceID="CPU0" PROPERTY_COUNT : 57 DERIVATION : {CIM_Processor, CIM_LogicalDevice, CIM_LogicalElement, CIM_ManagedSystemElement} SERVER : DEDRS-WH2021NB2 NAMESPACE : root\cimv2 PATH : \DEDRS-WH2021NB2\root\cimv2:Win32_Processor.DeviceID="CPU0" Architecture : 9 AssetTag : None Caption : Intel64 Family 6 Model 58 Stepping 9 Characteristics : 4 ConfigManagerErrorCode : ConfigManagerUserConfig : CreationClassName : Win32_Processor CurrentClockSpeed : 2401 Description : Intel64 Family 6 Model 58 Stepping 9 Family : 198 InstallDate : L3CacheSize : 6144 L3CacheSpeed : 0 Level : 6 Manufacturer : GenuineIntel Name : Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz NumberOfCores : 4 NumberOfEnabledCore : 4 NumberOfLogicalProcessors : 8 OtherFamilyDescription : PartNumber : None PNPDeviceID : PowerManagementCapabilities : ProcessorId : BFEBFBFF000306A9 Role : CPU SecondLevelAddressTranslationExtensions : False SerialNumber : None Stepping : SystemCreationClassName : Win32_ComputerSystem SystemName : DEDRS-WH2021NB2 ThreadCount : 8 UniqueId : UpgradeMethod : 33 VirtualizationFirmwareEnabled : False VMMonitorModeExtensions : False Scope : System.Management.ManagementScope Path : \DEDRS-WH2021NB2\root\cimv2:Win32_Processor.DeviceID="CPU0" Options : System.Management.ObjectGetOptions ClassPath : \DEDRS-WH2021NB2\root\cimv2:Win32_Processor Properties : {AddressWidth, Architecture, AssetTag, Availability...} SystemProperties : {GENUS, CLASS, SUPERCLASS, __DYNASTY...} Qualifiers : {dynamic, Locale, provider, UUID} Site : Container :

Coreinfo -f Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz Intel64 Family 6 Model 58 Stepping 9, GenuineIntel Microcode signature: 0000001C HTT Hyperthreading enabled HYPERVISOR Hypervisor is present VMX - Supports Intel hardware-assisted virtualization SVM - Supports AMD hardware-assisted virtualization X64 * Supports 64-bit mode

SMX - Supports Intel trusted execution SKINIT - Supports AMD SKINIT

NX Supports no-execute page protection SMEP Supports Supervisor Mode Execution Prevention SMAP - Supports Supervisor Mode Access Prevention PAGE1GB - Supports 1 GB large pages PAE Supports > 32-bit physical addresses PAT Supports Page Attribute Table PSE Supports 4 MB pages PSE36 Supports > 32-bit address 4 MB pages PGE Supports global bit in page tables SS Supports bus snooping for cache operations VME Supports Virtual-8086 mode RDWRFSGSBASE Supports direct GS/FS base access

docker info Containers: 3 Running: 0 Paused: 0 Stopped: 3 Images: 5 Server Version: 18.06.0-ce Storage Driver: windowsfilter Windows: Logging Driver: json-file Plugins: Volume: local Network: ics l2bridge l2tunnel nat null overlay transparent Log: awslogs etwlogs fluentd gelf json-file logentries splunk syslog Swarm: inactive Default Isolation: hyperv Kernel Version: 10.0 17134 (17134.1.amd64fre.rs4_release.180410-1804) Operating System: Windows 10 Enterprise Version 1803 (OS Build 17134.165) OSType: windows Architecture: x86_64 CPUs: 8 Total Memory: 15.82GiB Name: DEDRS-WH2021NB2 ID: 5UAT:2WWY:5B2Q:KBA6:N4OH:LO73:SAWY:HC45:3GOT:PIEG:QODZ:X4SI Docker Root Dir: D:\DockerImages Debug Mode (client): false Debug Mode (server): true File Descriptors: -1 Goroutines: 30 System Time: 2018-08-03T15:08:05.2402163+02:00 EventsListeners: 1 Registry: https://index.docker.io/v1/ Labels: Experimental: false Insecure Registries: 127.0.0.0/8 Live Restore Enabled: false

[ghost]

I have related to docker memory limit issue and I would like to know if any Intel cpu model/generation requirements such as supported cpu flags(Ex: "PAGE1GB - Supports 1 GB large pages") is required to run this nav container? Older Intel cpu(2009) models/generation are supported?

I am running docker on Microsoft Windows 10 Enterprise edition Microsoft Windows [Version 10.0.17134.228] Coreinfo v3.31 - Dump information on system CPU and memory topology Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz Intel64 Family 6 Model 42 Stepping 7, GenuineIntel ... PAGE1GB - Supports 1 GB large pages(means not supported) ... Error:(docker output) container 3e96235ae4a80d403.... encountered an error during CreateContainer: failure in a Windows system call: The locale specific resource for the desired message is not present.(0x3ab9)extra info: { ... "MemoryMaximumInMB": 4096, (used option "-m 4G" , physical memory 12Gb , available 8Gb)

Windows Event Application log: The guest operating system reported that it failed with the following error codes: ErrorCode0: 0x1A,ErrorCode1: 0x61941, ErrorCode2: 0xFFFFA6FE40000000, ErrorCode3: 0xB, ErrorCode4: 0xFFFF970154F286E0.

According my understanding and reading this link these are memory issues: ErrorCode0: 0x1A, The MEMORY_MANAGEMENT bug check has a value of 0x0000001A. This indicates that a severe memory management error occurred. https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x1a--memory-management ErrorCode1: 0x61941, The paging hierarchy is corrupt. Parameter 2 is a pointer to the virtual address which caused the fault.

[ghost]

Just used another PC with more modern cpu(2015) architecture and now docker ce(windows) can create and run nav/bc container without any issue. My conclusion that somehow docker may not support (or that is image cpu architecture base) all hardware ,specially with older cpu.

[docker-robott]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale comment. Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle stale

[timotei]

@darstahl @friism Can we please not close this issue? It's still an issue and prevents us from using Docker containers for Windows in usecases where we need more than 3 GiB (e.g., some integration tests)

[NReilingh]

/remove-lifecycle stale

[MikhailTymchukDX]

@timotei Not a workaround, but just FYI: with this change the current issue might go away.

[apetres]

It seems that this issue has been fixed in the latest Windows 10 release. The combination that worked for me:

• Windows 10 1809 (build 17763.107)
• Docker 18.09.0
• Image: mcr.microsoft.com/windows:1809

[docker-robott]

Closed issues are locked after 30 days of inactivity. This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle locked