Failed to create CoreCLR, HRESULT: 0x80004005 when using VS Core Python in remote

[MikhailArkhipov]

@phx-srankin
microsoft/python-language-server#1595

Steps to reproduce

• VsCode + Python extension with remote
• Set python.jediEnabled = false in settings to switch to Microsoft Python Language Server
  Open Python project from code opened out of a Debian terminal running in WSL.

Notes:

Microsoft Python Language Server is .NET Core 3.0 https://github.com/microsoft/python-language-server, built self-contained.
Python extension unzips it into languageServer* folder under the extension.

Expected behavior

Work normally

Actual behavior

Failed to create CoreCLR, HRESULT: 0x80004005

Environment data

dotnet --info output:

.NET Core SDK (reflecting any global.json):
Version: 3.0.100
Commit: 04339c3a26

Runtime Environment:
OS Name: Mac OS X
OS Version: 10.14
OS Platform: Darwin
RID: osx.10.14-x64
Base Path: /usr/local/share/dotnet/sdk/3.0.100/

Host (useful for support):
Version: 3.0.0
Commit: 7d57652f33

.NET Core SDKs installed:
3.0.100 [/usr/local/share/dotnet/sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.App 3.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.13 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

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

Python:
Extension version: 2019.9.34911
VS Code version: Code 1.38.1 (b37e54c98e1a74ba89e03073e5a3761284e3ffb0, 2019-09-11T13:35:15.005Z)
OS version: Windows_NT x64 10.0.18362
Remote OS version: Linux x64 4.4.0-18362-Microsoft

[livarcocc]

This is not the right repo to file this issue. This repo covers the command line development tools for .NET Core, not the runtime itself.

I am going to go ahead and move this issue to core-setup for the next layer of investigation.

[vitek-karas]

I'm a bit lost in all the various OSes mentioned in this issue (and the parent one).
The repro is running VS Code on Mac remoting into a WSL Linux - so is that on a different machine then, or what is the actual setup?

Does it repro on normal Linux install (non-WSL)?
Does it repro consistently?

As mentioned in the parent bug, please try to run the dotnet process on the target machine with COREHOST_TRACE=1. You can also add COREHOST_TRACEFILE=f.txt to redirect the output to a file (if it's problematic to capture stderr of the process). Having that trace would help us a lot.

[MikhailArkhipov]

I believe @cloudhello tried it but claimed they didn't get more info. Here microsoft/python-language-server#1595 (comment).

@cloudhello - could you try it again?

[vitek-karas]

It's hard to say how the output redirection works. So hopefully using the COREHOST_TRACEFILE=t.txt will make this much easier.

[xPaw]

We had the same issue (0x80004005) report: SteamDatabase/steamdb.info-issues#660
It's a standalone build for linux-x64

There's strace log, maybe its of use: https://github.com/SteamDatabase/steamdb.info/files/4568659/log_SteamTokenDumper.txt

EDIT: After some experimenting:
I had <RuntimeIdentifier>win-x64</RuntimeIdentifier> in csproj and published with --runtime win-x64 and that produces a broken binary (I think it doesn't copy some libraries?)

Removing RuntimeIdentifier from csproj appears to fix it.

[mthalman]

Ran into this same error when attempting to build this Dockerfile on a Windows Server Core, version 1903 machine. So this is a Windows build, not Linux. This is the first time I've seen the error show up in our CI builds. It usually runs fine so it's an intermittent issue apparently.

Build output:

2020-06-26T14:21:39.8696456Z  Executing: docker build -t mcr.microsoft.com/dotnet/core/samples:complexapp-local-app -f samples/complexapp/Dockerfile samples/complexapp
2020-06-26T14:21:39.8697220Z  Sending build context to Docker daemon  20.48kB
2020-06-26T14:21:39.8697691Z  
2020-06-26T14:21:39.8698171Z  Step 1/21 : FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
2020-06-26T14:21:39.8698731Z   ---> 9d363405df98
2020-06-26T14:21:39.8699165Z  Step 2/21 : WORKDIR /source
2020-06-26T14:21:39.8699591Z   ---> Using cache
2020-06-26T14:21:39.8700060Z   ---> b6e910b6ea4e
2020-06-26T14:21:39.8700609Z  Step 3/21 : COPY complexapp/*.csproj complexapp/
2020-06-26T14:21:39.8701131Z   ---> 8f41852f8df6
2020-06-26T14:21:39.8701591Z  Step 4/21 : COPY libfoo/*.csproj libfoo/
2020-06-26T14:21:39.8702258Z   ---> 72a3fdd90d44
2020-06-26T14:21:39.8702766Z  Step 5/21 : COPY libbar/*.csproj libbar/
2020-06-26T14:21:39.8703234Z   ---> 962102267b07
2020-06-26T14:21:39.8703781Z  Step 6/21 : RUN dotnet restore complexapp/complexapp.csproj
2020-06-26T14:21:39.8704289Z   ---> Running in d5a3e38d36d0
2020-06-26T14:21:39.8704813Z    Determining projects to restore...
2020-06-26T14:21:39.8705371Z    Restored C:\source\complexapp\complexapp.csproj (in 190 ms).
2020-06-26T14:21:39.8705978Z    Restored C:\source\libbar\libbar.csproj (in 3.07 sec).
2020-06-26T14:21:39.8706622Z    Restored C:\source\libfoo\libfoo.csproj (in 3.07 sec).
2020-06-26T14:21:39.8707181Z  Removing intermediate container d5a3e38d36d0
2020-06-26T14:21:39.8707678Z   ---> ce77d5339a9a
2020-06-26T14:21:39.8708133Z  Step 7/21 : COPY complexapp/ complexapp/
2020-06-26T14:21:39.8708633Z   ---> 06314ff43533
2020-06-26T14:21:39.8709067Z  Step 8/21 : COPY libfoo/ libfoo/
2020-06-26T14:21:39.8709500Z   ---> 9b1ca013fe5a
2020-06-26T14:21:39.8710043Z  Step 9/21 : COPY libbar/ libbar/
2020-06-26T14:21:39.8710475Z   ---> 49bc03183287
2020-06-26T14:21:39.8710973Z  Step 10/21 : WORKDIR /source/complexapp
2020-06-26T14:21:39.8711481Z   ---> Running in caa6ae3254a0
2020-06-26T14:21:39.8712007Z  Removing intermediate container caa6ae3254a0
2020-06-26T14:21:39.8712461Z   ---> e8845cf14895
2020-06-26T14:21:39.8712940Z  Step 11/21 : RUN dotnet build -c release --no-restore
2020-06-26T14:21:39.8713481Z   ---> Running in e52c06061dfd
2020-06-26T14:21:39.8714017Z  Microsoft (R) Build Engine version 16.6.0+5ff7b0c9e for .NET Core
2020-06-26T14:21:39.8714666Z  Copyright (C) Microsoft Corporation. All rights reserved.
2020-06-26T14:21:39.8715128Z  
2020-06-26T14:21:39.8715975Z  C:\Program Files\dotnet\sdk\3.1.301\Roslyn\Microsoft.CSharp.Core.targets(59,5): error : Failed to create CoreCLR, HRESULT: 0x80004005 [C:\source\libbar\libbar.csproj]
2020-06-26T14:21:39.8717253Z  C:\Program Files\dotnet\sdk\3.1.301\Roslyn\Microsoft.CSharp.Core.targets(59,5): error : Failed to create CoreCLR, HRESULT: 0x80004005 [C:\source\libfoo\libfoo.csproj]
2020-06-26T14:21:39.8718122Z  
2020-06-26T14:21:39.8718478Z  Build FAILED.
2020-06-26T14:21:39.8718813Z  
2020-06-26T14:21:39.8719652Z  C:\Program Files\dotnet\sdk\3.1.301\Roslyn\Microsoft.CSharp.Core.targets(59,5): error : Failed to create CoreCLR, HRESULT: 0x80004005 [C:\source\libbar\libbar.csproj]
2020-06-26T14:21:39.8720938Z  C:\Program Files\dotnet\sdk\3.1.301\Roslyn\Microsoft.CSharp.Core.targets(59,5): error : Failed to create CoreCLR, HRESULT: 0x80004005 [C:\source\libfoo\libfoo.csproj]
2020-06-26T14:21:39.8721808Z      0 Warning(s)
2020-06-26T14:21:39.8722189Z      2 Error(s)
2020-06-26T14:21:39.8722593Z  
2020-06-26T14:21:39.8722979Z  Time Elapsed 00:00:23.48
2020-06-26T14:21:39.8723661Z  The command 'cmd /S /C dotnet build -c release --no-restore' returned a non-zero code: 1

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

[dotnet-policy-service]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.