Issues after implicitly restarting docker on changing VM settings

Expected behavior

After restarting docker due to changing VM settings previously running containers shall be running again, at least after restarting explicitly.

Actual behavior

After restarting docker containers didn’t run. Restarting explicitly succeeded at first glance, only.

Information

Docker container was created using this command:

docker run --name mysql -v c:/Users/Public/Documents/docker-data/mysql:/var/lib/mysql -p 3306:3306 -d mysql:latest

PS C:\Users\soletan> DockerDebugInfo.ps1
DockerDebugInfo.ps1 : Die Benennung “DockerDebugInfo.ps1” wurde nicht als Name eines Cmdlet, einer Funktion, einer
Skriptdatei oder eines ausführbaren Programms erkannt. Überprüfen Sie die Schreibweise des Namens, oder ob der Pfad
korrekt ist (sofern enthalten), und wiederholen Sie den Vorgang.
In Zeile:1 Zeichen:1

  • DockerDebugInfo.ps1
  • CategoryInfo : ObjectNotFound: (DockerDebugInfo.ps1:String) , CommandNotFoundException
  • FullyQualifiedErrorId : CommandNotFoundException

That’s an error in German stating:

The name “DockerDebugInfo.ps1” was not found as name of a Cmdlet, a function, some script file or executable. Check the name and pathname for typos and repeat.

My OS is Windows 10 Version 1511 (Build 10586.318)

Steps to reproduce the behavior

With a running container pulled from image “mysql” I was trying to reduce number of CPU cores and memory using “Change VM settings” popup. After that docker was claimed to restart. Back in settings dialog the links were disabled for a few seconds, but as soon as they got re-enabled I tried this at shell prompt:

docker ps
docker start mysql
docker ps

Issuing first command I was expecting to get list of mysql container running again. But list was empty. Thus I issued second command which succeeded without error, but prompting the running containers name as expected. However, issuing third command still resulted in empty list.

After exiting Docker using context menu in systray and restarting DfW again with reduced # of CPU cores and RAM, the same procedure resulted in an empty list, then again a successfully starting container and finally in a list displaying that running container.