When dotnet fails to run, it doesn't provide good debugging info

[omajid]

When a dotnet application fails to run, it mostly exits with an undecipherable message:

Failed to initialize CoreCLR, HRESULT: 0xDEADBEEF

Is there a way to make the error more verbose? Can we print out what went wrong? For example, did a native library lookup fail? Did we fail to allocate memory? Are we out of handles? Sometimes even a fairly obscure error message provides pretty good insight for what is wrong. But a hex code doesn't :(

As it is, users end up getting completely lost and have no way to help themselves even if the fix otherwise would have been a simple yum/apt install foo...

Perhaps we can use something like perror (on linux) to provide more information about what the underlying platform tells us about what failed? Perhaps we can provide a stack trace (managed and/or unmanaged)?

For example, see

• https://github.com/dotnet/core-setup/issues/2808
• https://github.com/dotnet/core-setup/issues/636
• https://github.com/dotnet/cli/issues/1488
• https://github.com/dotnet/cli/issues/4865
• https://github.com/dotnet/coreclr/issues/11417
• https://nmilosev.svbtle.com/running-net-core-rc2-on-fedora-23

[annerajb]

Agree maybe the HRESULT can be translated to a string?

[steveharter]

@jkotas any thoughts on getting a better error message from the clr?

[jkotas]

I do not think that converting HRESULT to string is going to help much. If you look at the linked issues, they have a very generic HRESULTs like 0x80131500 or 0x80004005 that tell you nothing.

The common way to diagnose these failures is to run under strace today. The last failing system call is usually a pretty good indicator of what went wrong.

If we wanted something better, we would need to go through the above reports, try to guess what might have gone wrong; and add a better error message for those particular situation.

A non-trivial fraction of these error is likely result of missing or bad native dependencies. We have number of issues about this problem, e.g. https://github.com/dotnet/corefx/issues/25157 .

[steveharter]

Closing. Here's some of the options:

• The corefx issue mentioned above is tracking the common cases of bad native dependencies.
• If we have specific case such as getting a better description for a given missing dependency we could add an issue for those - likely that would be an issue in the corefx repo.
• Use strace.
• Set COREHOST_TRACE=1 to help identify dependencies and other issues.
• As a last report, it is also possible to use a debugger and break on line number or exception. A custom built clr can also be built.