TL;DR - the System.Diagnostics.Process.MainModule returns other module than the main one in some cases.

When trying to build CoreCLR in Alpine docker container, I have bumped into a strange issue when msbuild would fail with internal error when forking another copy of itself. strace revealed that it was calling "access" syscall with "Tools/dotnetcli/shared/Microsoft.NETCore.App/2.0.0-preview1-002111-00/System.Private.CoreLib.ni.dll" file as a parameter. Looking at where that syscall came from, it turned out it was SystemNative_ForkAndExecProcess in System.Native.so, which was called from a call chain stemming from Microsoft.Build.BackEnd.NodeProviderOutOfProcBase.LaunchNode. This function was passing in a result of the System.Diagnostics.Process.MainModule and it was returning that dll instead of the actual main module.
It turns out that the System.Diagnostics.Process.MainModule relies on the main module being the first module listed in the /proc/self/maps. But in the Alpine container, it was not the case.

I can see two ways to fix that. Either ensure that the modules ProcessManager.GetModules always returns the main module as the first one or change the System.Diagnostics.Process.MainModule to search for the main exe by looping through all the modules and comparing their FileName to the Process.GetExePath(). And probably caching the result.

I've verified that the second approach works.