Problem writing to createdump parent_write_pipe: %s (%d)\n

Error message

Problem writing to createdump parent_write_pipe: %s (%d)\n

What it means

Emitted by the CoreCLR parent process in PROCLaunchCreateDump (process.cpp:1585). After prctl(PR_SET_PTRACER, childpid) the parent writes one 'S' byte to parent_write_pipe (retried on EINTR only); if the written count is not 1 the parent prints this, clears errorMessageBuffer, closes parent_read_pipe and returns false, aborting dump capture. As with error 241 the typical cause is EPIPE: the child already closed its read end (e.g. it hit error 243 and exit(-1)) before the parent wrote.

Source

Thrown at src/coreclr/pal/src/thread/process.cpp:1585

        close(child_read_pipe);
        close(child_write_pipe);
#if HAVE_PRCTL_H && HAVE_PR_SET_PTRACER
        // Gives the child process permission to use /proc/<pid>/mem and ptrace
        if (prctl(PR_SET_PTRACER, childpid, 0, 0, 0) == -1)
        {
            // Ignore any error because on some CentOS and OpenSUSE distros, it isn't
            // supported but createdump works just fine.
            ERROR("PROCCreateCrashDump: prctl() FAILED %s (%d)\n", strerror(errno), errno);
        }
#endif // HAVE_PRCTL_H && HAVE_PR_SET_PTRACER
        // Signal child that prctl(PR_SET_PTRACER, childpid) is done
        int bytesWritten;
        while((bytesWritten = write(parent_write_pipe, "S", 1)) < 0 && errno == EINTR);
        close(parent_write_pipe);

        if (bytesWritten != 1)
        {
            fprintf(stderr, "Problem writing to createdump parent_write_pipe: %s (%d)\n", strerror(errno), errno);
            close(parent_read_pipe);
            if (errorMessageBuffer != nullptr)
            {
                errorMessageBuffer[0] = 0;
            }
            return false;
        }

        // Read createdump's stderr messages (if any)
        if (errorMessageBuffer != nullptr)
        {
            // Read createdump's stderr
            int bytesRead = 0;
            int count = 0;
            while ((count = read(parent_read_pipe, errorMessageBuffer + bytesRead, cbErrorMessageBuffer - bytesRead)) > 0)
            {
                bytesRead += count;
            }

View on GitHub (pinned to 290d5ab72c)

Solutions

Turn on verbose createdump logging (DOTNET_CreateDumpDiagnostics=1 DOTNET_CreateDumpVerboseDiagnostics=1) and look for the child's preceding 'Problem reading ... child_read_pipe' message — that is the real cause.
Rule out external termination of the parent during the handshake (OOM killer, container reaper): check `dmesg -T` and the container runtime events.
Raise fd and memory limits on the crash path (ulimit -n, cgroup memory).
Verify kernel ptrace policy is not blocking the parent's prctl step: read /proc/sys/kernel/yama/ptrace_scope and relax if needed.
If dumps remain unreliable, switch to kernel core_pattern-based capture so no parent/child pipe handshake is required.

Example fix

# before
$ DOTNET_DbgEnableMiniDump=1 ./app
# Problem writing to createdump parent_write_pipe: Broken pipe (32)

# after: surface the root cause and relax constraints
$ DOTNET_DbgEnableMiniDump=1 \
  DOTNET_CreateDumpDiagnostics=1 DOTNET_CreateDumpVerboseDiagnostics=1 \
  ./app
$ cat /proc/sys/kernel/yama/ptrace_scope   # if 2/3, set to 0/1

Defensive patterns

Strategy: validation

Validate before calling

# Same preconditions as the child-read failure: ensure parent survives to the signal write.
cat /proc/sys/kernel/yama/ptrace_scope 2>/dev/null | grep -Eq '^[01]$' || echo "WARN: relax ptrace_scope so parent completes prctl"
[ "$(ulimit -n)" -ge 1024 ] || ulimit -n 65536
# Smoke-test the dump path verbosely once:
DOTNET_DbgEnableMiniDump=1 DOTNET_CreateDumpVerboseDiagnostics=1 "$@"

Prevention

Enable verbose createdump diagnostics to reveal the upstream child_read_pipe failure that causes the broken-pipe write.
Prevent external kills (OOM, reapers) during crash handling via adequate cgroup memory and no PID-1 reaper.
Relax ptrace_scope so the parent's PR_SET_PTRACER step succeeds before the write.
Raise fd limits; the handshake needs four pipe fds.
Treat kernel core_pattern as the production dump mechanism.

When it happens

Trigger: Full CoreCLR runtime crash-dump path: the forked child died or closed child_read_pipe before the parent's write(parent_write_pipe,'S',1) at line 1580 completed, so write() returns -1/EPIPE (or 0). The subsequent bytesWritten != 1 check at line 1583 trips this message.

Common situations: Child exited first via the 'Problem reading from createdump child_read_pipe' branch (parent died in prctl, was OOM-killed, or pipe broken); signal storm interrupting the parent before the write; fd exhaustion; a SIGCHLD reaper racing the handshake; PR_SET_PTRACER failure cascading into the child giving up.

Related errors

AI-assisted analysis of dotnet/runtime@290d5ab72c (2026-08-06). Data as JSON: /api/errors/9259436de4fab075. Report an issue: GitHub.