New subject: [Bug 59923] .NET console child process fails/hangs when parent is launched with stdin redirected from /dev/null

June 27, 2026

      http://bugs.winehq.org/show_bug.cgi?id=59923

            Bug ID: 59923
           Summary: .NET console child process fails/hangs when parent is
                    launched with stdin redirected from /dev/null (no real
                    pty), despite working correctly with an interactive
                    terminal attached
           Product: Wine
           Version: 11.11
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: kernel32
          Assignee: wine-bugs@list.winehq.org
          Reporter: blacklens.323@proton.me
      Distribution: ---

Note: I used AI to assist writing this report and for testing the
reproducibility. I hope this will be useful regardless.

Description:
A 32-bit Windows application spawns a separate 64-bit .NET (CoreCLR / .NET Core
3.1) console application as a child process to handle file I/O over a named
pipe. This works correctly every time when the parent is launched from an
interactive terminal with a real pty attached to stdin/stdout. It fails
reliably — same exact crash signature every time — when the parent is launched
with stdin redirected from /dev/null, which is how most game launchers (Lutris,
Steam, etc.) invoke processes. This is fully reproducible and isolated purely
to the presence/absence of a real pty: identical Wine build, identical Wine
prefix, identical environment variables and working directory in both cases.
Real-world application: AA2Unlimited (github.com/aa2g/AA2Unlimited), an
open-source mod loader for the game "Artificial Academy 2." The crashing
component is PPeXM64.exe, part of the open-source PPeX project
(github.com/aa2g/PPeX), a 64-bit named-pipe file-archive server that the
(32-bit) game process spawns and communicates with.
Steps to reproduce (real application):

WINEPREFIX=/path/to/prefix wine /path/to/AA2Play.exe from an interactive
terminal — works correctly, game launches fully.
WINEPREFIX=/path/to/prefix wine /path/to/AA2Play.exe < /dev/null — reproduces
the crash every time, with no other changes.

Expected result: The child .NET console process starts and runs identically
regardless of whether the parent process has a real pty attached to stdin.
Actual result: The child process (PPeXM64.exe) throws an unhandled
System.NullReferenceException shortly after completing its startup work and
connecting to its named pipe, immediately followed by a native page fault
inside kernelbase/coreclr:

Unhandled exception. Connected to pipe
System.NullReferenceException: Object reference not set to an instance of an
object.
   at PPeXM64.Program.Main(String[] args) in
D:\Sourcecode\GitHub-Bepis\PPeX\PPeXM64\Program.cs:line 138
wine: Unhandled page fault on read access to 0000000000000000 at address
00006FFF9C5B58BC (thread 0178), starting debugger...
...
Backtrace:
=>0 0x... in kernelbase (+0xd8c7)
  1 0x... in coreclr (+0x146619)
  2 0x... in coreclr (+0x14664b)
  3 0x... in coreclr (+0x146655)

This is followed by the parent process (AA2Play.exe) hanging indefinitely,
since it's left waiting on a pipe connection from a process that has already
died — confirming the parent successfully spawned the child and began the
handshake, and the failure happens specifically after that point.
Things ruled out as contributing factors (each tested directly, none made any
difference):

System locale (tested both default and forced ja_JP.UTF-8)
Stray/leftover processes from previous runs (wineserver -k before each attempt)
Open file descriptor limit (ulimit -n) — confirmed identical between working
and failing contexts; artificially lowering it produces a different, much
louder failure mode (Wine itself refusing to start), not this one
Process/thread limit (ulimit -u) — confirmed identical
Sandboxing — Lutris installed natively via the distro package manager, not
Flatpak
Choice of Wine binary — confirmed byte-identical binary used in both working
and failing cases
Graphics/DXVK configuration — unrelated; this crash occurs before any rendering
takes place

Minimal reproduction attempts (unsuccessful so far):
(*A)I attempted to build a minimal synthetic reproduction using .NET 8,
self-contained published win-x86/win-x64 executables, tested individually and
in combination:

A 32-bit parent spawning a 64-bit .NET console child (cross-bitness WOW64
spawn) — no failure
Adding real named-pipe IPC between parent and child (server in child, client in
parent) — no failure
Adding 16 concurrent worker threads in the child during startup — no failure
Spawning the child explicitly with CREATE_NEW_CONSOLE via raw CreateProcess
(P/Invoke) rather than relying on inherited console handles — no failure
(handshake still succeeded in both pty and no-pty conditions; only difference
was losing visibility into the child's own console output, since it now goes to
an unseen separate console)

None of these individually or in combination reproduce the fault — only the
real PPeXM64.exe binary does, with 100% reliability tied purely to pty
presence. The remaining untested variable is the sheer scale of real concurrent
file I/O during PPeXM64's startup (tens of thousands of real file reads across
many threads, rather than simulated work), which I didn't have an easy way to
isolate without the full game/mod data.
Possibly related existing report: bugs.winehq.org/show_bug.cgi?id=32791 ("Fail
to receive stdout from .NET application") may describe a related underlying
issue — worth checking its current status before treating this as a duplicate.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 59923] New: .NET console child process fails/hangs when parent is launched with stdin redirected from /dev/null (no real pty), despite working correctly with an interactive terminal attached

WineHQ Bugzilla

WineHQ Bugzilla

tags

participants (1)