I am running Sitecore 10.2 XM in Docker Desktop. It has no issues loading the site in a browser on my laptop but throws a bad gateway error in a VM that has nested virtualization. It used to run fine in the VM until a Docker Desktop upgrade I believe. I do not see any errors on docker compose up as all the Containers create. When I try to access my site at cm.mysite.localhost it gives an all blank page with "Bad Gateway" in text. Of note:

  • Windows Firewall is not enabled
  • I am using WSL2 with Docker Compose V2 and tested with a Hyper-V backend and receive the same error
  • The VM has 4 Cores and 16GB of RAM with a 24GB Swap file
  • Host file entries added by Docker Desktop are as follows: host.docker.internal gateway.docker.internal
# To allow the same kube context to work on the host and the container: kubernetes.docker.internal
  • 1
    I would suggest checking if the System.Security.Cryptography.Xml.dll is deployed to CM. Jun 7, 2023 at 8:15
  • 1
    It can be a Memory issue as well, we faced this type of issue once. Jun 9, 2023 at 4:53
  • 1
    Were you able to confirm the DLL is available in the bin directory? That seems the most likely issue. It could be reading that file from GAC on your local machine, but not have it available on the VM. Jun 11, 2023 at 19:14
  • 1
    Is the correct version of the DLL deployed? It should be File Version: If any other version is deployed it will give the exact error thatyou have described. Jun 13, 2023 at 9:52
  • 1
    An image is immutable, so if you are using same image as others you would have exact same files. Given you have different version, I'm guessing you are using different image or tag of same image. What image are you using? Have you customised it? If so look at the build process. What version is showing in your solution? Could multiple versions be referenced in project? Jun 13, 2023 at 21:14

1 Answer 1


Based on the discussions in the comments, it seems the reason for the bad gateway error is an incorrect version of System.Security.Cryptography.Xml.

Sitecore versions 9.3-10.3 all ship with File Version: 4.6.26515.6

If you take a healthy sitecore instance and copy in the latest version of the System.Security.Cryptography.Xml DLL into the bin folder, you will get the following error:

26112 07:53:47 ERROR Unhandled exception detected. The ASP.NET worker process will be terminated. 
Exception: System.IO.FileNotFoundException
Message: Could not load file or assembly 'System.Security.Cryptography.Xml, Version=, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
Source: Sitecore.Nexus.Licensing

This is stipulating that the assembly has been found, but is not the correct version. Note: Version: relates to File Version: 4.6.26515.6

You will also see the error is showing "The ASP.NET worker process will be terminated". Which explains why there is nothing to map through to in Docker Desktop.

You mention in your comments that there are:

No customizations as these are the default Sitecore images

Yet, you also say:

Our solution layers on top of it

By layering your solution over the top of the Sitecore images, you are in turn creating a custom image. Due to the fact that Sitecore ships with version 4.6.26515.6 and you have identified version in the deployed code, therefore your solution must be layering the new DLL over the top.

Please review your solutions nuget packages and make sure that all references point to the same version 4.6.26515.6.

  • What is odd is that we all get from the same repo and no one else has this issue. I am the only one to pull fresh images so wondering if the latest Sitecore images have a file issue
    – Kode
    Jun 14, 2023 at 13:18
  • 1
    That should be straight forward to check - set cm image in docker-compose file to use the latest sitecore version. Comment/remove any volume mounts. Spin up the environment and exec in via docker desktop and review file. Or use "docker cp" command to copy out the file to check the version. Jun 14, 2023 at 13:26
  • 1
    Thanks Dan and to all. We had different versions of the dll that likely came over from a nuget package. Once resolved, it loads as expected.
    – Kode
    Jun 14, 2023 at 16:47
  • No problem - glad you got it working Jun 14, 2023 at 18:43
  • I experienced the issue by using a generic docker image version (10.2-ltsc2019). I updated to 10.2.0-ltsc2019 instead of dealing with the web.config. Jan 18 at 19:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.