diagnostics: dotnet-dump collect error: Writing dump failed (HRESULT: 0x80004005)

I’m trying to create a dump on Debian 10.4 of a dotnet core 3.1.301 x64 bit app running under a service controlled by systemd. The service is running as a different user (less powerful one). Executing the dotnet-dump tool fails when ran as root. I can’t run the tool as the user running the service since the tool was installed as root and uninstall fails with “Cannot find a manifest file.”. Regardless of the install issue, what am I doing wrong? FWIW, dotnet-counters monitor attaches to the same pid and works fine.

`
root@debian:~/.dotnet/tools# ./dotnet-trace ps
    12618 TheProgram /directorypath/TheProgram

root@debian:~/.dotnet/tools# ./dotnet-dump collect -p 12618
Writing full to /root/.dotnet/tools/core_20200712_153334
Writing dump failed (HRESULT: 0x80004005)
root@debian:~/.dotnet/tools# ls
total 288K
drwxr-xr-x 3 root root 4.0K Jul 12 09:21 .
drwxr-xr-x 6 root root 4.0K Jul  9 12:32 ..
-rwxr-xr-x 1 root root  89K Jul  9 12:32 dotnet-counters
-rwxr-xr-x 1 root root  89K Jul 12 09:21 dotnet-dump
-rwxr-xr-x 1 root root  89K Jul 12 09:20 dotnet-trace
drwxr-xr-x 6 root root 4.0K Jul 12 09:21 .store
root@debian:~/.dotnet/tools#`

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 37 (14 by maintainers)

Most upvoted comments

Okay, I wasn’t able to reproduce this. However, you being able to use the pipe and . I think I know what happened there. The process that writes the dump is your app, not dotnet-dump. Therefore, it is written under the user (and group access) of your systemd-run aspnet app. That one probably doesn’t have access to /root/.dotnet/tools/ (probably root owned). A quick way to test this is using the -o flag, by giving it an output path where AUser can write to:

  -o, --output <output_dump_path>    The path where collected dumps should be written. Defaults to '.\dump_YYYYMMDD_HHMMSS.dmp' on Windows and './core_YYYYMMDD_HHMMSS' on Linux where YYYYMMDD is Year/Month/Day and HHMMSS is Hour/Minute/Second. Otherwise, it is the full path and file name of the dump.

hoyosjs on Jul 14, 2020

If you have self-contained app check the permissions on createdump tool in your artefacts. Seems like dotnet-dump uses createdump. If there is no executable flag for createdump then you will get Writing dump failed (HRESULT: 0x80004005)

daleksandrov-qontigo on Sep 8, 2021

@hoyosjs Version 5.0.5 has been released to Linux App Service plans (in AU) - we can now take memory dumps 😃

quinten-miller on Jun 3, 2021

@Pilchie @bradygaster Do y’all know dates for 5.0.6 on App Service?

shirhatti on May 21, 2021

@shirhatti do you know any contact in App Services we can ask about this? Otherwise, the only way I know of getting the update is doing a self-contained deployment sort of like this: https://azure.github.io/AppService/2021/04/15/Running-dotnet-6-Preview-on-App-Service.html, except targeting 5.0 instead of 6.0.

hoyosjs on May 21, 2021

@quinten-miller This is likely an issue that was fixed with https://github.com/dotnet/runtime/pull/50478. Can you please upgrade to 5.0.6 (a security update released yesterday) and try again?

hoyosjs on May 13, 2021