Improve the dotnet-dump error message: Core dump generation FAILED 0x80004005

[mikem8361]

The failures from createdump are pretty much pass/fail so the error code in the message doesn't give any useful information.

The simplest solution (and it is still some work) is to stream over the diagnostics output sent to stderr in the createdump process to the dotnet-dump process.

[andreesteve]

@mikem8361 - not sure if related with this issue or not, but it seems that whenever I get 0x80004005 because of missing execute permissions for 'createdump', it also creates a fork of the original process that is being dumped, and the forks are not killed after the dump fails.

[mikem8361]

Basically 0x80004005 (E_FAIL) is returned to dotnet-dump by the runtime for every error which I hope to improve when I get to this issue but it will take runtime work/coordination.

If the runtime or SDK is installed with our installers or even from a downloaded zip, createdump should have the execute permission. What is the exact install scenario are you using to end up without execute perms?

And yes, it does look like we don't clean up the fork with the execve. Could you create an issue in the runtime repo? Thanks.

[andreesteve]

I wanted to analyze the memory consumption of a large powershell script, this meant dumping the pwsh process that was running the script. Pwsh is installed through my distro's package manager and it came without execute permissions on powershell's createdump binary.

I wonder if it the pwsh package for my distro should have been shipped with exec permissions on createdump.

Is createdump specific per binary? i.e. should each donet core binary ship with its own?

I can see pwsh seems to be installed with its own:

[andre@scout ~]$ ll /opt/microsoft/powershell/7/createdump 
-rwxr-xr-x 1 root root 109656 Oct  2 19:44 /opt/microsoft/powershell/7/createdump

and the dotnet runtime with its own as well:

[andre@scout ~]$ find /usr/share/dotnet | grep createdump
/usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.15/createdump
/usr/share/dotnet/shared/Microsoft.NETCore.App/2.2.7/createdump
/usr/share/dotnet/shared/Microsoft.NETCore.App/3.1.8/createdump

It worked for me after I gave execute permissions to the pwsh's createdump binary. I wonder if the right approach is to just give the dotnet one the execute permissions instead. Do you have a recommendation? Thank you.

[mikem8361]

It looks like pwsh is a self-contained .NET app which includes all the runtime binaries (including createdump). It looks like in this self-contained app case, createdump doesn't get execute perms when the app is expanded/installed. That looks like an issue in the self-contained app support.

I assume the ones installed under /usr/share/dotnet had execute permission.

[ghost]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

---

The failures from createdump are pretty much pass/fail so the error code in the message doesn't give any useful information.

The simplest solution (and it is still some work) is to stream over the diagnostics output sent to stderr in the createdump process to the dotnet-dump process.

Author:	mikem8361
Assignees:	mikem8361
Labels:	area-Diagnostics-coreclr, untriaged
Milestone:	-

[mikem8361]

Related issue: #64069

[mikem8361]

We should also fix the error when dotnet-dump collect on a single-file app:

WriteDump failed - HRESULT: 0x00000000

[mikem8361]

On MacOS, improve this error message:

[createdump] task_for_pid(2485) FAILED 5 (os/kern) failure