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.