dotnet-dump fails with "Core dump generation FAILED 0x80004005" on WSL

[mjrousos]

In WSL environment running Ubuntu 18.04:

1. dotnet new console
2. Update Program.cs to have a Console.ReadLine() so that the process doesn't immediately exit.
3. dotnet run
4. In a separate WSL window: dotnet dump collect --diag -p [PID for the console app]
   1. Using sudo does not change the behavior. With or without gives the same results.

Expectation: A dump should successfully be collected.
Actual: The dotnet dump command fails and prints:

Writing minidump with heap to /mnt/d/scratch/tmp/core_20191008_151903
Core dump generation FAILED 0x80004005

In the console app's output, the following message appears:

open(/proc/201/mem) FAILED 2 (No such file or directory)

Additional information

mikerou@MikeRou-SB:/mnt/d/scratch/tmp$ dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.0.100
 Commit:    04339c3a26

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  18.04
 OS Platform: Linux
 RID:         ubuntu.18.04-x64
 Base Path:   /home/mikerou/dotnet/sdk/3.0.100/

Host (useful for support):
  Version: 3.0.0
  Commit:  7d57652f33

.NET Core SDKs installed:
  2.2.300 [/home/mikerou/dotnet/sdk]
  3.0.100-preview5-011568 [/home/mikerou/dotnet/sdk]
  3.0.100-preview9-014004 [/home/mikerou/dotnet/sdk]
  3.0.100 [/home/mikerou/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.2.5 [/home/mikerou/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.2.5 [/home/mikerou/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0-preview5-19227-01 [/home/mikerou/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0-preview9.19424.4 [/home/mikerou/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0 [/home/mikerou/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.2.5 [/home/mikerou/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0-preview5-27626-15 [/home/mikerou/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0-preview9-19423-09 [/home/mikerou/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0 [/home/mikerou/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download
mikerou@MikeRou-SB:/mnt/d/scratch/tmp$ dotnet dump --version
3.0.47001+9c4970b824f14fd69d553e83035050c2d634cabe
mikerou@MikeRou-SB:/mnt/d/scratch/tmp$ uname -r
4.4.0-17763-Microsoft

[mikem8361]

dotnet-dump collect (and createdump) is currently not supported on WSL. This is an limitation in WSL (no /proc//mem support) that may be fixed in WSL 2. Issue microsoft/WSL#2028 is related but more about lldb not working.

[0xd4d]

process_vm_readv() is supported on WSL 1 though: http://man7.org/linux/man-pages/man2/process_vm_readv.2.html

Available since Linux 3.2 so it (coreclr code?) should try /proc/<pid>/mem first then if it fails, try process_vm_readv()

[phillijw]

I also receive this error while running in a docker container using the official microsoft core 3.0 sdk docker image

# /root/.dotnet/tools/dotnet-dump collect -p 1
Writing minidump with heap to /app/core_20191119_141925
Core dump generation FAILED 0x80004005

[SidShetye]

Same issue as @phillijw but for .net core 3.1 runtime docker images running on Azure.

[mikem8361]

@phillijw, @SidShetye, this issue is about the problems with WSL that cause creating a core dump to fail. dotnet-dump collect displays the same error message (the one in this issue's title) for many different problems (I have another issue on that).

Your docker problems are probably because you don't have the SYS_TRACE capability. You can enable that with the --cap-add=SYS_PTRACE or --privileged docker options. See FAQ for more information.

[SidShetye]

@mikem8361 I suspect the same. But the docker containers are spawned by Azure App Service - Containers and customers have no control over that, even if you're fully owning the instance/vm hosting the containers.

Any other diagnostics to debug the working set for an asp.net core 3.1 service in such a situation? We're investigating a Stoping site<site> because it exceeded swap usage limits. issue that recycles some of our idle (!) containers despite the working set being 10x smaller than free physical memory on the VM.

[mikem8361]

We are looking into ways for dotnet-dump to take coredumps without using ptrace but we are stilling in the planning stages. I'll let you know when we come up with something to help debug your problem.

[mikem8361]

In the end, dotnet-dump collect isn't supported on WSL 1.0 (but it will probably work on WSL 2.0) so i'm going to close this issue.

[SidShetye]

We are looking into ways for dotnet-dump to take coredumps without using ptrace but we are stilling in the planning stages.

@mikem8361 Is there a github issue tracking the above? My issue wasn't WSL but SYS_PTRACE missing on azure app service linux containers preventing dotnet-dump collect. So while you close this (appropriately), I'd like to monitor the alternative to SYS_PTRACE approach.

[mikem8361]

Created issue #896 to track this.