Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failed to create CoreCLR, HRESULT: 0x80004005 #13166

Closed
mskadu opened this issue Jul 13, 2020 · 15 comments
Closed

Failed to create CoreCLR, HRESULT: 0x80004005 #13166

mskadu opened this issue Jul 13, 2020 · 15 comments
Labels
Issue-Question ideally support can be provided via other mechanisms, but sometimes folks do open an issue to get a Resolution-Answered The question is answered.

Comments

@mskadu
Copy link

mskadu commented Jul 13, 2020

Hello!

I am running pwsh v7.0.2 on RHEL 7.6 (maipo). I have a script that examines and manipulates a large number of XML files. Until recently the same script on a windows 10 machine without issues. But recently we moved to a beefier linux machine for compliance reasons.

And since then I am seeing the following error message interspersed with normal messages:

Failed to create CoreCLR, HRESULT: 0x8000405

I can't seem to find anything useful anywhere else that tells me why this is happening?

Steps to reproduce

nohup find /data/input/lot001/ -name '*.xml' -exec pwsh -File ./MyScript.ps1 {} \; 2>&1 > /data/logs/lot001.log &

Expected behavior

  • regular output messages
  • script completes execution

Actual behavior

  • regular output messages interspersed with the error message - Failed to create CoreCLR, HRESULT: 0x8000405

Environment data

Name                                      Value
-----                                        -------
PSVersion                               7.0.2
PSEdition                                Core
GitCommitId                           7.0.2
OS                                           Linux 3.10.0-957.1.3.el7.x86_64 #1 SMP Thu Nov 15 17:36:42 UTC 2018
Platform                                  Unix
PSCompatibleVersions            {1.0, 2,0, 3.0, 4.0...}
PSRemotingProtocolVersion   2.3
SerializationVersion                1.1.0.1
WSManStackVersion               3.0
@mskadu mskadu added the Issue-Question ideally support can be provided via other mechanisms, but sometimes folks do open an issue to get a label Jul 13, 2020
@daxian-dbw
Copy link
Member

daxian-dbw commented Jul 13, 2020

@mskadu Can you please collect the CoreCLR start-up traces and share with us?
You need to set the environment variables COREHOST_TRACE=1 and COREHOST_TRACEFILE=<path>, see https://docs.microsoft.com/en-us/dotnet/core/dependency-loading/default-probing#how-do-i-debug-the-probing-properties-construction.

I suggest to reduce the number of xml files when collecting the traces, so that there won't be a large number of pwsh spun up which may result in to much traces.

Overview of .NET Core's System.Runtime.Loader.AssemblyLoadContext.Default probing logic to locate dependencies.

@mskadu
Copy link
Author

mskadu commented Jul 14, 2020

Am in the process of doing this .. should be back shortly. In the meanwhile, I am seeing the following message in the trace file

-- Begin breadcrumb write
Directory core breadcrumbs [] was not specified or found
Fallback directory core breadcrumbs at [opt/breadcrumbs] was not found
Breadcrumb store was not obtained... skipping write.

Is this safe to ignore? Or am i doing something wrong?

@daxian-dbw
Copy link
Member

daxian-dbw commented Jul 14, 2020

I'm not very sure about what the breadcrumb thread is supposed to log, but it looks benign. We can ignore this for now.

@mskadu
Copy link
Author

mskadu commented Jul 17, 2020

Here you go:

13166_coretrace.log

Please let me know if you have further questions or need more information

@daxian-dbw
Copy link
Member

daxian-dbw commented Jul 17, 2020

@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?

@iSazonov iSazonov added the Resolution-Answered The question is answered. label Jul 20, 2020
@mskadu
Copy link
Author

mskadu commented Jul 20, 2020

Thanks. I am checking this and will confirm back shortly.

@daxian-dbw
Copy link
Member

daxian-dbw commented Jul 21, 2020

@mskadu Any luck?

@mskadu
Copy link
Author

mskadu commented Jul 21, 2020

Not yet, I am afraid. Got side-lined by another unrelated issue.

Please bear with me. I hope to get back to you soon.

@msftbot
Copy link

msftbot bot commented Jul 23, 2020

This issue has been marked as answered and has not had any activity for 1 day. It has been closed for housekeeping purposes.

@msftbot msftbot bot closed this as completed Jul 23, 2020
@mskadu
Copy link
Author

mskadu commented Jul 23, 2020

I know this is closed. But thought I'd let you know this suggestion worked. For people who find this after. Thank you!

@daxian-dbw
Copy link
Member

daxian-dbw commented Jul 23, 2020

@mskadu Good to know that! Thanks for getting back to us.

@jcoutch
Copy link

jcoutch commented Oct 20, 2020

I just ran into this with a Alpine container on WSL2. Adding COMPlus_EnableDiagnostics=0 worked for me as well. I happened to search for that environment variable, and ran across this issue:
dotnet/docs#10217

My container is read-only, so it makes sense that disabling diagnostics would fix the issue (if it's writing diagnostics to a read-only folder).

@alexei-matveev
Copy link

alexei-matveev commented Apr 23, 2021

I bet inodes ran out because of many pwsh-invokations, see comments in dotnet/runtime#46462

@daxian-dbw
Copy link
Member

daxian-dbw commented Nov 15, 2021

@mazhar10 Please move your comment to the issue that you opened. This issue is already resolved.

@mazhar10
Copy link

mazhar10 commented Nov 16, 2021

@mazhar10 Please move your comment to the issue that you opened. This issue is already resolved.

Thanks - I need to pay more attention to the links in notification emails!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Question ideally support can be provided via other mechanisms, but sometimes folks do open an issue to get a Resolution-Answered The question is answered.
Projects
None yet
Development

No branches or pull requests

6 participants