dotnet-dump : "Can not load or initialize libmscordaccore.so"

[colinsusie]

dotnet sdk version: 8.0.2 dotnet-dump version: 8.0.5

My program is running inside a container and has crashed, generating a coredump file:

-rw------- 1 root root  48G Apr 22 01:21  core-SingleThreadEve-11-0-0-1-1713720038

I attempted to analyze the dump file directly within the container using dotnet-dump, when i entering clrstack, I encountered the following error:

Type 'quit' or 'exit' to exit the session.
> clrstack
Failed to load data access module, 0x80004002
Can not load or initialize libmscordaccore.so. The target runtime may not be initialized.

For more information see https://go.microsoft.com/fwlink/?linkid=2135652

Despite following the guidance provided by the link, I was unable to resolve the issue.

Subsequently, I manually collected a dump of the running program within the same pod using dotnet-dump. I didnt encounter any problem by using the dump file I collected manaully.

Could you help me understand the reason behind this discrepancy? Thank you.

The system environment for both compiling and running the program is identical.

[mikem8361]

This is usually the SDK is a source built and not an SDK installed from our feeds. The debugging modules needed are not on the Microsoft symbol server. Since .NET 8.0 most distros like Ubuntu install .NET from their own feeds a source-built SDK. And it looks and has a version like the official Microsoft builds.

If you want to analyze the dump on a different machine, copy the libcordaccore.so and libcordbi.so from the pod the dump was generated in and use the setclrpath to tell SOS where they are.

[mikem8361]

System dumps do not have all the managed state needed for SOS/debugging. They can be made to work by setting the coredump_filter file to 0x3f (see FAQ.)

[colinsusie]

I found that the dump file generated by dotnet defaults to/tmp/coredump< PID> The dump file generated by ubuntu is specified by/proc/sys/kernel/core-pattern When the dotnet program crashes, both dump files are generated. The dump file generated by dotnet can be analyzed by dotnet_dump, while the system generated file cannot

[mikem8361]

Dump files created by the system do not have enough managed state for dotnet-dump/sos to work. If you want to use a system dump the coredump_filter file needs to be set to at least 0x3F. See this for more info.

[colinsusie]

Thank you. After setting 0x3f, dotnet-dump can analyze the dump files generated by the system normally