This article answers commonly asked questions about collecting dumps in .NET.
Why do I only get dumps on Linux if [dotnet-dump](dotnet-dump.md) or my [crashing process](dumps.md#collect-dumps-on-crash) is running elevated?
On Linux-based systems, /proc/sys/kernel/ptrace_scope controls who can call ptrace and what processes they can trace. We recommend it being set to 1 - meaning only processes in the same ancestry chain can use traced. Any value higher than this requires elevation or might disable ptrace altogether.
Why can't I collect dumps when running inside a container?
For applications running under any Open Container Initiative technology, the seccomp profile must allow for calls to ptrace. For example, Docker uses containerd under the hood as a container runtime. When initializing the runtime, it specifies a default seccomp profile that allows ptrace only if the container host has a kernel version higher than 4.8 or if the CAP_SYS_PTRACE capability was specified.
Why can't I collect dumps on macOS?
On macOS the use of ptrace requires the host of the target process to be properly entitled. For information about the minimum required entitlements, see Default entitlements.
Where can I learn more about how I can leverage dumps to help diagnose problems in my .NET application?
Here are some additional resources:
How can I solve "It was not possible to find any compatible framework version"
On Linux, the DOTNET_ROOT environment variable must point to the correct folder when set. When it points to another .NET version, dotnet-dump always produces this error. When the DOTNET_ROOT environment variable isn't set, a different error is produced ("You must install .NET to run this application").
