Styjun

This issues has taken me one day, really I just thought it's simple at first.

I have a host machine (Windows 10) with Docker desktop for Windows installed.
From the host machine, I would like to use docker run to start a container which contains some simple code to run.

Here is the code (which is built in the container), this is a .NET core Console app (suppose its built name is console.dll):

static void Main(string[] args)

 Console.WriteLine("Running...");
 _execTest();
 Console.WriteLine("Finished!");
 Console.ReadLine();

static void _execTest()

 var sharedFilePath = Path.Combine(Environment.CurrentDirectory, "Temp", "test.exe");
 var si = new ProcessStartInfo(sharedFilePath);

 si.RedirectStandardOutput = false;
 si.RedirectStandardError = false;
 si.RedirectStandardInput = false;

 Console.WriteLine("Starting ..." + sharedFilePath);
 var p = Process.Start(si);
 p.WaitForExit();

The main code is just to start another program named test.exe. This program is put in the shared folder Temp (which is established at the time calling docker run by mounting the folders between the host machine and the container).

Here is the code for the test.exe (which is just a .NET console app):

static void Main(string[] args)
 
 Console.WriteLine("Something went wrong!");
 Console.Write("Welldone!"); 

So I expect that all the messages written in test.exe using Console should be directed back to the parent context (which should use one same STDOUT).

I've tested the code by running the code for container directly using dotnet console.dll and I can see the messages (from test.exe) printed expectedly.

However after deploying the console.dll to an image (console) and try the following command to run the container:

docker run --rm -v D:SourceFolder:C:appTemp console

Then the messages (from test.exe) are not printed. Only the messages written directly in the parent context are printed (Running..., Starting... and Finished!).

You can see that the command above uses -v to mount the folder C:appTemp in container to the source folder D:SourceFolder in the host machine.
And the test.exe is put in D:SourceFolder.
I'm sure that the container's code can access this file via the shared folder.

This is so weird and hard to diagnose.
Without sharing messages back and forth between the container and the host, running docker like this is just useless.

I hope someone here could give me some some suggestion so that I can try and sort this out. Thanks!

UPDATE:
If I use cmd.exe (which is already existed in the docker image) with argument of /?, then I can see the output of it. So looks like this is some problem of executing an EXE shared via folder.

However I've tried copying the shared file to the some local folder of the container first and run that file instead but still the same issue. So looks like it may be the problem of the test.exe file itself? so ridiculous.

UPDATE: thanks to @jazzdelightsme for his helpful suggestion about checking the ExitCode, so actually the environment in the container has something missing that cannot start the test.exe correctly. I've tried compiling the test.exe targeting the lowest .NET Framework version 2.0 but still that same error. Here is Dockerfile's content which should provide some info about the container's environment:

FROM microsoft/dotnet:2.1-runtime-nanoserver-1709 AS base
WORKDIR /app

FROM microsoft/dotnet:2.1-sdk-nanoserver-1709 AS build
WORKDIR /src
COPY ConsoleApp/ConsoleApp.csproj ConsoleApp/
RUN dotnet restore ConsoleApp/ConsoleApp.csproj
COPY . .
WORKDIR /src/ConsoleApp
RUN dotnet build ConsoleApp.csproj -c Release -o /app

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

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

A general troubleshooting thing to check is the exit code of the process. This will often give a clue what the problem is.

In this case, the exit code was STATUS_DLL_NOT_FOUND. This alone may be enough of a clue if you understand your app's dependencies, because you can just manually examine the container and figure out what is missing.

If you don't know what is missing, a direct way to debug is by using the Windows Debuggers and turning on "Show Loader Snaps". Info about getting Windows Debuggers here. You can xcopy them into the container. You would use a command line like C:Debuggerscdb.exe -xe "ld ntdll" test.exe, which launches test.exe under the debugger, stopping as soon as ntdll.dll is loaded (which is earlier than normal). Once it stops, you run !gflag +sls to turn on loader snaps, then run g to continue execution. Examining the spew should tell you what is missing or failing to load.

In this particular case, STATUS_DLL_NOT_FOUND is likely because test.exe is a .NET Framework app, but the full .NET Framework is not present in the nanoserver image.