Failed to initialize CoreCLR, HRESULT: 0x80131500

[murali2020kris]

Steps to reproduce

1. Download https://dotnetcli.blob.core.windows.net/dotnet/beta/Binaries/Latest/dotnet-dev-centos-x64.latest.tar.gz
2. Unpack tar file
3. Set DOTNET_HOME as unzipped folder. [usr/share/dotnet]
4. Change permission settings for unzipped folder dotnet
5. run dotnet -version

   Expected behavior

Should give version number

Actual behavior

Gives error message Failed to initialize Failed to initialize CoreCLR, HRESULT: 0x80131500

Environment data

dotnet --version output: Failed to initialize CoreCLR, HRESULT: 0x80131500

[ellismg]

Have you installed dependent packages like icu and libunwind?

[murali2020kris]

@ellismg Thank you so much. icu was missing. It works now.

[ellismg]

Glad to hear it!

[Bundas]

Hey, I have the same error. I have icu and libundwind installed. What else could be the problem?

I am running Ubuntu 16.04 @ellismg @murali2020kris

[decompiled]

@Bundas I am also having the same issue with 16.04 with icu and libundwind.

[ellismg]

Support for 16.04 will come at RTM.

[vstoykov]

I also has the same problem. I'm trying it on Fedora 23 (downloaded Centos binaries).

I know that Fedora is not listed in supported distributions but I just wanted to try. Probably the reason for error is the same as for Ubuntu 16.04 (version of the icu is newer in Fedora 23 and Ubuntu 16.04, compared to Debian 8, CentOS 7 and Ubuntu 14.04)

[robert-sandor]

For Ubuntu 16.04, installing libicu52 from trusty-security seems to fix the problem.

[ghost]

For Fedora you can copy necessary libs from: ftp://195.220.108.108/linux/centos/7.2.1511/os/x86_64/Packages/libicu-50.1.2-15.el7.x86_64.rpm package to your /lib/lib64

[SoftHippo]

Any ideas for this in OpenSUSE Leap? I've installed the package icu and libicu52_1 and get this same issue.

[icebreaker]

You can find out what is missing by running:

find /opt/dotnet -name '*.so' -type f -print | xargs ldd | grep 'not found'

Replace /opt/dotnet with the directory you "un-tarred" the tar ball to.

[SoftHippo]

Thanks @icebreaker

It appears I'm still missing libicu53 (seems unavailable for Leap, though I have libicu52) and liblldb.so.3.5.0 (I have 3.7.0 installed)

Are these particular versions required?

[kamathba]

Same problem on Fedora 24, with the following library versions: libunwind-1.1-11.fc24.x86_64 libicu-56.1-4.fc24.x86_64

[capric8416]

openSUSE Tumbleweed: sudo find /opt/dotnet -name '*.so' -type f -print | xargs ldd | grep 'not found' liblldb.so.3.5.0 => not found # liblldb.so.3.8 found libicuuc.so.53.1 => not found # libicuuc.so.57.1 found libicui18n.so.53.1 => not found # libicui18n.so.57.1 found liblttng-ust.so.0 => not found # not found

[ghost]

kamathba, on fedora 24 you need libicu from fedora 23. Try that package: mirror.yandex.ru/fedora/linux/releases/23/Workstation/x86_64/os/Packages/l/libicu-54.1-5.fc23.x86_64.rpm

[3rdey3]

Arch Linux

$ sudo find /opt/dotnet -name '*.so' -type f -print | xargs ldd | grep 'not found'
/opt/dotnet/shared/Microsoft.NETCore.App/1.0.0/System.Net.Http.Native.so: /usr/lib/libcurl.so.4: version `CURL_OPENSSL_3' not found (required by /opt/dotnet/shared/Microsoft.NETCore.App/1.0.0/System.Net.Http.Native.so)
    libicuuc.so.52 => not found
    libicui18n.so.52 => not found
    liblldb-3.6.so => not found
    liblttng-ust.so.0 => not found

$ pacman -Q icu libunwind curl 
icu 57.1-1
libunwind 1.1-3
curl 7.49.1-1

[SoftHippo]

Okay, I don't think it's so productive if we all just post our missing dependencies here. We need to find out if they require those particular versions for every distribution, or if a specific version per distribution is needed, or if it simply doesn't work on some distributions (I don't think I've seen a successful OpenSUSE or Arch install yet). Any ideas?

[watzon]

Had the same problem running Kali linux. Turned out that I had a newer version of libicu and libicu-dev installed (v55 I believe) and dotnet wanted version 52. All I had to do was go to the debian repos and find libicu52 and libicu52-dev and install them

[vanthome]

Gentoo User here. I have 57.1 of libicu installed. @iDev0urer did downgrading to 55.x help in your case?

[heavendragon]

Opensuse 42.1 finally success after install libicu from this https://software.opensuse.org/package/libicu53_1 but still failed to initialize code, error "Segmentation fault" during dotnet new, dotnet restore(Opensuse 42.1, kernel 4.6.x) No problem on kernel 4.1.21-14-default

[SoftHippo]

@heavendragon Interesting; I installed the rpm from that link (and its one dependency for which it asked) and it runs fine for me. dotnet new, restore, and run all worked as expected. Getting into this some more tomorrow.

(also on Opensuse 42.1, much earlier kernel though)

[watzon]

@vanthome I downgraded to v52 and now it works. At the very least I'm not getting that error when typing dotnet --help and dotnet --version anymore. I haven't tried doing anything else with it yet

[tgoncuoglu]

here are some specifics: OS is Fedora 24 with libunwind/libicu installed (f24 has icu at version 56.1 and libunwind at version 1.11). I'm getting above mentioned error. Downgrading to f23 libicu is not an option because of dependencies involved: qt5-qtbase, among others. No can do. So in the end, it seems dotnet requires a specific icu version, ie v52.

[kamathba]

I was able to get it working on Fedora 24 by building/installing libicu v52 from source and installing liblldb /libunwind using yum

[sphildreth]

On Fedora 24 I installed ftp://195.220.108.108/linux/fedora/linux/releases/23/Everything/x86_64/os/Packages/l/libicu-54.1-5.fc23.x86_64.rpm and "dotnet -version" worked.

[mickaelistria]

Another way to get it running on Fedora 24 and other distros using too recent ICU (provided to me by @scela)

1. download libicu-54.1-5.fc23.x86_64.rpm from wherver ( eg http://mirror.yandex.ru/fedora/linux/releases/23/Workstation/x86_64/os/Packages/l/libicu-54.1-5.fc23.x86_64.rpm )
2. open it with archive manager, go to ./usr/lib64 and extract all the .so files to ~/oldicu
3. now execute: LD_LIBRARY_PATH=~/oldicu/:$LD_LIBRARY_PATH dotnet instead of invoking directly dotnet.

This has the advantage of not forcing installation of older icu (which can lead to other issues for package requiring newer icu). Also I imagine this would work with any Linux distribution facing this issue. You can also tweak your .bashrc to define alias dotnet=LD_LIBRARY_PATH=~/oldicu/:$LD_LIBRARY_PATH dotnet, but since alias aren't inherited, it's not working when running scripts, so one had to use source script.sh instead of ./script.sh if they want to take advantage of their alias.

[mrmeek]

I was able to dotnet new, restore, and run on OpenSUSE 42.1 by downloading and installing the dependency for libicu53_1: https://software.opensuse.org/package/libicu53_1-ledata (this just copies libicudt531.dat to/usr/share/icu/53.1), and using the technique mickaelistria described such that I can leave the default 52_1 install alone. Thanks mickaelistria!

BTW, Kernel v4.1.20-11-default

[molaie]

for debian stretch users, there is more than just libicu52. I added this line to sources.list (/etc/apt/sources.list) deb http://ftp.de.debian.org/debian/ jessie main then : apt-get update finally: apt-get -t jessie install libicu52 apt-get install libssl1.0.0 in this point, the command by @icebreaker gives this output:

    root@yspdebian:~# find /opt/dotnet -name '*.so' -type f -print | xargs ldd | grep 'not found'`

    liblldb-3.6.so => not found

    liblttng-ust.so.0 => not found

finally, work is done by : apt-get install liblttng-ust0 and apt-get install liblldb-3.6

and now, i have this error:

ahmad@yspdebian:~/oldicu$ dotnet new

Welcome to .NET Core!
---------------------
Learn more about .NET Core @ https://aka.ms/dotnet-docs. Use dotnet --help to see available commands or go to https://aka.ms/dotnet-cli-docs.
Telemetry
--------------
The .NET Core tools collect usage data in order to improve your experience. The data is anonymous and does not include commandline arguments. The data is collected by Microsoft and shared with the community.
You can opt out of telemetry by setting a DOTNET_CLI_TELEMETRY_OPTOUT environment variable to 1 using your favorite shell.
You can read more about .NET Core tools telemetry @ https://aka.ms/dotnet-cli-telemetry.
Configuring...
-------------------
A command is running to initially populate your local package cache, to improve restore speed and enable offline access. This command will take up to a minute to complete and will only happen once.
Decompressing 100% 4369 ms
Expanding 0%Segmentation fault

version is:

ahmad@yspdebian:~/oldicu$ dotnet --version
1.0.0-preview2-003121

and

ahmad@yspdebian:~/oldicu$ dotnet --info
.NET Command Line Tools (1.0.0-preview2-003121)

Product Information:
 Version:            1.0.0-preview2-003121
 Commit SHA-1 hash:  1e9d529bc5

Runtime Environment:
 OS Name:     debian
 OS Version:  
 OS Platform: Linux
 RID:         debian.-x64

[ellismg]

There was a bug in 1.0.0 that manifested itself in this way on newer kernels (IIRC it was 4.6.0+) . We fixed the bug see (https://github.com/dotnet/coreclr/pull/6027) but I don't think the fix has flowed to any of the binary packages.

We will release this fix as part of a 1.0.1 release, but we don't know the exact date of that release yet. If you want to try the following, it should probably address your issue.

1) Download https://dotnet.myget.org/F/dotnet-core/api/v2/package/runtime.debian.8-x64.Microsoft.NETCore.Runtime.CoreCLR/1.0.4 2) Unzip it to some folder (otherwise it will litter files over whatever folder you extract it in). 3) copy all the files in runtimes/debian.8-x64/native/ to /opt/dotnet/shared/Microsoft.NETCore.App/1.0.0/ (replacing the versions that already exist there).

Give it another whirl after this.

[molaie]

dotnet new is done, but this time, i have error in dotnet restore. for the first time it does the job, but then in dotnet run, i have segfault. and now, both of them ( restore and run ) gave segfault.

[cgountanis]

Followed instructions for openSUSE (although looks like leap is newer than instuctions) and I get the same error Failed to initialize CoreCLR, HRESULT: 0x80131500 even when doing --version. Can the instructions be updated, not really going to spend time trying a million different options.

[jamasu]

mrmeek could you explain how you followed the instructions in detail? I downloaded and installed libicu53 but still getting the errors. I am using openSuse Leap 42.1

[cgountanis]

Personally I just gave up ain't nobody got time for that.

[jamasu]

we just have to wait for a new release with the bugfix i suppose?

[jamasu]

aah, i actually made it work now, just runned sudo zypper remove icu, which removes 52.1 then sudo zypper install icu which installs 53.1 and just like that it works :)

[cgountanis]

Great news! Thanks for sharing.

[mleu]

@cgountanis based on all the valuable info in this issue I managed to get dotnet running on openSUSE Tumbleweed 20160831 like so:

Install a old libicu 53.1 to $HOME/.icu53

wget http://download.opensuse.org/repositories/devel:/languages:/R:/released/openSUSE_Factory/x86_64/libicu53_1-53.1-70.1.x86_64.rpm
rpm2cpio libicu53_1-53.1-70.1.x86_64.rpm | cpio -idmv # unpack
mv usr/lib64 $HOME/.icu53

Install the data for the old libicu 53.1 to $HOME/.icu53-data

wget http://download.opensuse.org/repositories/devel:/languages:/R:/released/openSUSE_Factory/noarch/libicu53_1-ledata-53.1-70.1.noarch.rpm
rpm2cpio libicu53_1-ledata-53.1-70.1.noarch.rpm | cpio -idmv
mv usr/share/icu/53.1 $HOME/.icu53-data

Grab the updated CoreCLR packages mentioned above required for newer Linux kernels

wget  https://dotnet.myget.org/F/dotnet-core/api/v2/package/runtime.opensuse.13.2-x64.Microsoft.NETCore.Runtime.CoreCLR/1.0.4
unzip 1.0.4.zip
chmod u+r runtimes/opensuse.13.2-x64/native/*
cp runtimes/opensuse.13.2-x64/native/* $(dirname $(command -v dotnet))/shared/Microsoft.NETCore.App/1.0.0/

Call dotnet with the old icu plus its data and it should (hopefully) work

LD_LIBRARY_PATH="$HOME/.icu53" ICU_DATA="$HOME/.icu53-data" dotnet --version

[cgountanis]

Issue with steps:

mv usr/share/icu/53.1 $HOME/.icu53-data mv: cannot stat ‘usr/share/icu/53.1’: No such file or directory

I am just not that interested to figure it all out. I can wait for them to update the runtime to work on current versions of Linux.

[cgountanis]

Scott has some nice instructions over and beyond although it is for Ubuntu 14.04, I can live with that.

http://www.hanselman.com/blog/PublishingAnASPNETCoreWebsiteToACheapLinuxVMHost.aspx

Same error, more information: https://github.com/dotnet/core/blob/master/release-notes/1.0/manual-shared-update.md

[lnu]

@mleu Followed your advice and it works(OpenSuse Tumbleweed 092016 snapshot)

[robertmsale]

@mleu Thanks to you I am now able to use .NET Core. What I did differently was had all of the library files extracted to $HOME/dotfix instead of my home folder, then created a shell script that launches the library path fix taking arguments and placed it in my /usr/local/bin folder so all I have to do is use

dotfix

Instead of dotnet. Thank you!

[mmisztal1980]

Experiencing a similar issue on Ubuntu 16.04:

mmisztal@ubuntu:/agent$ sudo apt-get install libunwind8
Reading package lists... Done
Building dependency tree       
Reading state information... Done
libunwind8 is already the newest version (1.1-4.1).
libunwind8 set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 191 not upgraded.
mmisztal@ubuntu:/agent$ sudo apt-get install icu
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package icu
mmisztal@ubuntu:/agent$ sudo apt-get install libicu55
Reading package lists... Done
Building dependency tree       
Reading state information... Done
libicu55 is already the newest version (55.1-7).
libicu55 set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 191 not upgraded.
mmisztal@ubuntu:/agent$ ./config.sh
Failed to initialize CoreCLR, HRESULT: 0x80131500

Can anyone advise on how to proceed to get this working? (I'm trying to configure a VSTS build agent on linux)

[mmisztal1980]

This seems to have solved my issue :/

wget http://security.ubuntu.com/ubuntu/pool/main/i/icu/libicu52_52.1-8ubuntu0.2_amd64.deb
sudo dpkg -i libicu52_52.1-8ubuntu0.2_amd64.deb

[EtienneBruines]

Same goes for Ubuntu 16.10 with libicu52 installed :-(

[TuntematonSotilas]

I am on Fedora 24 : I use a script(SH) wich force LD_LIBRARY_PATH, works good for dotnet run. Now I am lost in Visual Studio Code : where do I configure the path of .NET CLI ?

[nibbles-]

Just upgraded to Fedora25 (libicu 57.1) and now it is broken again

[TheRealPiotrP]

@DustinCampbell can you comment on

I am on Fedora 24 : I use a script(SH) wich force LD_LIBRARY_PATH, works good for dotnet run. Now I am lost in Visual Studio Code : where do I configure the path of .NET CLI ?

@ellismg any updates on this issue? Seems like it's still affecting a bunch of folks...

[ellismg]

any updates on this issue? Seems like it's still affecting a bunch of folks...

We took fixes for vNext (they didn't make it in for 1.1) that should help here. Basically we added a mode where we can compile in a way such that we'll "roll forward" to newer ICUs. I believe the plan is to cut over to that mode as the default before vNext for the binaries that we build and distribute.

In the mean time, you can install an older version of libicu or if it's possible to override the version of the CLI that VSCode uses to use a local copy of .NET Core, we have scripts that will let you rebuild the relevant native components.

When I last looked, it was unclear if VSCode was deploying their stuff as shared framework apps or standalone. Either way, we can do the rebuilds. If VS Code is just using the shared framework, we have scripts now that can automate the rebuilding. If they publish their tools standalone, then folks will have to rebuild "by hand".

There may also be problems with some other native components (specifically Crypto and HTTP) but you hit the ICU issues first, since globalization is used early in app startup.

[DustinCampbell]

@GBatault: If I understand, you have a script that sets LD_LIBRARY_PATH and launches 'dotnet'? If so, putting this script on your path and naming it 'dotnet' should get various commnads in VS Code that depend on the .NET CLI working.

[TuntematonSotilas]

@DustinCampbell Tanks for the trick : So what I did today : I use my .bashrc to add an alias : dotnet='LD_LIBRARY_PATH=~/oldicu/:$LD_LIBRARY_PATH dotnet'

But still the error on launching VS Code : The .NET CLI tools cannot be located. .NET Core debugging will not be enabled. Make sure .NET CLI tools are installed and are on the path.