Interop-ed native C++ code that uses OR Tools in a Windows Container

Question

Our company has a native x64 .DLL that links now to the OR Tools .LIB files. We're using this .DLL through C# interop in a FROM mcr.microsoft.com/windows/servercore:ltsc2019 Windows container. I did clear the hurdle that the .DLL could not load the dependencies in the list below:

• msvcp140.dll
• vcruntime140.dll
• vcruntime140_1.dll

What I experience now is that the program freezes after calling into the OR libraries. What else do I need in order to be able to use the OR Tools in this scenario? Watching ProcMon observing a non-containerized instance of the application running, I notice quite a bit of TCP communication going on; do I need to open the 58656 port on the container? Any other hurdle that people may have encountered?

Answer 1

There are zero communications in the or-tools code. So it comes from something else.

Answer 2

The solution should anyone need to run the OR Tools within a Windows Container.

Adding the 3 .DLLs listed above is enough to get the OR Tools running on a brand new instance of Windows. It was not exactly a hang that I were experiencing but extremely slow processing. That became obvious when I ran the program on a Windows Server VM configured to the same low counts of vCPUs and memory as a Container: Task Manager showed a 100% CPU utilization on all cores, yet nothing was happening.

My esteemed colleague who's using the OR Tools figured out the issue, here is his response:

I manually set the number of "workers" in the OR-Tools config to 16. Normally it defaults the number of workers to the number of vCPUs. The problem is that OR-Tools select the variety of algorithms it uses based on the number of workers available, and 4 is just not enough to get the necessary algorithms for these problems, apparently.