Failed to create CoreCLR, HRESULT: 0x80004005 on Linux

[Steve0x43]

Using Amazon Linux 2, with the Linux tarball:

$ wget https://github.com/microsoft/Git-Credential-Manager-Core/releases/download/v2.0.318-beta/gcmcore-linux_amd64.2.0.318.44100.tar.gz
$ sudo tar -xvf gcmcore-linux_amd64.2.0.318.44100.tar.gz -C /usr/local/bin

$ which git-credential-manager-core
/usr/local/bin/git-credential-manager-core

$ git-credential-manager-core configure
Failed to create CoreCLR, HRESULT: 0x80004005

Output related to .NET (installed and working correctly for other development activities):

$ dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.103
 Commit:  9effbc8ad5

Runtime Environment:
 OS Name:     amzn
 OS Version:  2
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /usr/share/dotnet/sdk/5.0.103/

Host (useful for support):
  Version: 5.0.3
  Commit:  eae88cc11b

.NET SDKs installed:
  3.1.406 [/usr/share/dotnet/sdk]
  5.0.103 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.12 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.3 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.12 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.3 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

I also tried installing GCM to my home directory:

$ tar -xvf gcmcore-linux_amd64.2.0.318.44100.tar.gz -C ~/.local/bin
$ which git-credential-manager-core 
~/.local/bin/git-credential-manager-core
$ git-credential-manager-core configure
Failed to create CoreCLR, HRESULT: 0x80004005

And with no parameters:

$ git-credential-manager-core
Failed to create CoreCLR, HRESULT: 0x80004005

I obtained the following trace (using COREHOST_TRACE=1):

git-credential-manager-core.log

[mjcheetham]

On Linux, we're using the "single file" publishing method for GCM Core. Specifically, in .NET Core 3.1 (the version GCM is currently released targeting) the "single file" is really a self-extracting archive. The archive is extracted to /tmp on run and execution is redirected to that extracted set of binaries.

From reading this issue it seems that if there's a problem creating a pipe in the temporary directory, the CLR fails to load..

PowerShell/PowerShell#13166 (comment)

@mskadu At startup, CoreCLR tries to create named pipes for debugging and profiling of the process in /tmp/. It could be that the pipe creation fails intermittently when pwsh gets started so frequently.
Can you please try disabling CoreCLR diagnostics by setting the environment variable export COMPlus_EnableDiagnostics=0 (as instructed here), and then try running your repro step again to see if that helps?

Can you try the COMPlus_EnableDiagnostics=0 environment variable workaround to see if that works for you?

We plan to move to .NET 5 and it's improved single file publishing (an actual single file, and no self-extracting nonsense) in an upcoming release, so hopefully if this is the problem that will be resolved.

[Steve0x43]

Thanks @mjcheetham. COMPlus_EnableDiagnostics=0 did not work, but I did manage to get GCM Core working using sudo - so believe it was related to the extraction mechanizm as you mentioned.

I've now tested the latest version (GCM 2.0.374-beta, targetting .NET 5 on Linux), and this is working as expected.

[kargajopep]

Exporting COMPlus_EnableDiagnostics=0 environment variable did work for me.