Windows + cx_Freeze GUI build: create_subprocess_exec() fails with OSError [Errno 9] bad file descriptor unless stdin=DEVNULL

[XiaoYouChR]

Summary

On Windows, winloop subprocess creation appears to fail inside a cx_Freeze GUI-frozen executable (base="gui" / no console), even for a minimal repro.

The failure happens when calling asyncio.create_subprocess_exec(...) with the usual defaults for stdin and with redirected stdout/stderr.

A reliable workaround on the application side is to explicitly pass:

stdin=asyncio.subprocess.DEVNULL

Once I do that, the frozen executable works.

This suggests winloop may be assuming that inherited/default stdio handles are valid in a no-console frozen process, while cx_Freeze GUI executables do not always provide valid default stdin/stdio state.

---

Environment

• OS: Windows x64
• Python: 3.11.15 (MSC v.1944 64 bit (AMD64))
• winloop: 0.5.0
• cx_Freeze: 8.6.1

---

Real-world trigger

This first showed up in my application when I was doing:

process = await asyncio.create_subprocess_exec(
    ffmpegPath,
    "-version",
    stdout=asyncio.subprocess.PIPE,
    stderr=asyncio.subprocess.DEVNULL,
)

Inside a cx_Freeze GUI-frozen executable, that crashes with:

OSError: [Errno 9] bad file descriptor

---

Minimal reproduction

smoke.py

import asyncio
import os
import winloop


async def main():
    cmd = os.environ.get("ComSpec") or r"C:\Windows\System32\cmd.exe"

    proc = await asyncio.create_subprocess_exec(
        cmd,
        "/c",
        "echo",
        "123",
        stdout=asyncio.subprocess.PIPE,
        stderr=asyncio.subprocess.DEVNULL,
    )

    stdout, _ = await proc.communicate()
    print(proc.returncode, stdout)


if __name__ == "__main__":
    winloop.install()
    asyncio.run(main())

setup_cxfreeze.py

from cx_Freeze import Executable, setup

setup(
    name="winloop-cxfreeze-smoke",
    version="0",
    options={
        "build_exe": {
            "packages": ["winloop"],
        }
    },
    executables=[
        Executable(
            script="smoke.py",
            base="gui",
            target_name="winloop-cxfreeze-smoke.exe",
        )
    ],
)

Build and run

python setup_cxfreeze.py build_exe
.\build\exe.win-amd64-3.11\winloop-cxfreeze-smoke.exe

---

Actual result

The frozen executable crashes with:

Traceback (most recent call last):
  File "_tmp_cxfreeze_minimal.py", line 34, in <module>
  File "_tmp_cxfreeze_minimal.py", line 29, in run
  File "C:\Develop Tools\Python311\Lib\asyncio\runners.py", line 190, in run
    return runner.run(main)
  File "C:\Develop Tools\Python311\Lib\asyncio\runners.py", line 118, in run
    return self._loop.run_until_complete(task)
  File "winloop/loop.pyx", line 1615, in winloop.loop.Loop.run_until_complete
  File "_tmp_cxfreeze_minimal.py", line 14, in main
  File "C:\Develop Tools\Python311\Lib\asyncio\subprocess.py", line 223, in create_subprocess_exec
    transport, protocol = await loop.subprocess_exec(
  File "winloop/loop.pyx", line 2979, in subprocess_exec
  File "winloop/loop.pyx", line 2910, in __subprocess_run
  File "winloop/handles/process.pyx", line 673, in winloop.loop.UVProcessTransport.new
  File "winloop/handles/process.pyx", line 151, in winloop.loop.UVProcess._init
OSError: [Errno 9] bad file descriptor

The important part is that the failure is happening inside winloop subprocess setup / spawn on Windows in the frozen GUI process.

---

Expected result

The frozen GUI executable should be able to start subprocesses successfully, even when the parent process does not have a normal console/stdin handle.

At minimum, I would expect behavior similar to “invalid default stdio is ignored or replaced with NUL/DEVNULL” rather than surfacing EBADF from process creation.

---

Workaround

If I change the subprocess call to explicitly set stdin to DEVNULL, the same frozen executable works:

proc = await asyncio.create_subprocess_exec(
    cmd,
    "/c",
    "echo",
    "123",
    stdin=asyncio.subprocess.DEVNULL,
    stdout=asyncio.subprocess.PIPE,
    stderr=asyncio.subprocess.DEVNULL,
)

This succeeds in the frozen cx_Freeze GUI executable.

I applied the same workaround in my real app for ffmpeg, ffprobe, and N_m3u8DL-RE, and that avoided the crash.

---

Additional investigation

I also reproduced a related Windows issue outside of cx_Freeze by manually closing parent fd 0 before calling create_subprocess_exec(). That made subprocess setup fail with EBADF too, which makes me suspect the same family of problem:

• invalid/default stdio inheritance on Windows
• especially in no-console / GUI / frozen parent processes

So this may be in the winloop Windows subprocess stdio handling path rather than in cx_Freeze itself.

The traceback points at UVProcess._init() where uv_spawn() errors are converted, which makes me think one of the inherited/default stdio descriptors/handles is invalid in the frozen GUI process.

[XiaoYouChR]

When running Nuitka to compile the Python program with the --windows-console-mode=disable parameter, the issue still exists. To rule out the possibility that Nuitka might have broken the original logic of Winloop, I used cx_Freeze for testing.

[Vizonex]

@XiaoYouChR Currently there is work being dome to merge uvloop and winloop together to make maintenance less costly so my hands are currently tied, but if you have the time to fix it feel free to send me a pull request.

[XiaoYouChR]

I dug into this further and can confirm the current failure is not just “fd 0 is invalid”.

I can still reliably reproduce this in a cx_Freeze base="gui" frozen executable on Windows, including on a separate environment (Python 3.13.11 + cx_Freeze 8.6.2), so it does not look specific to the original Python 3.11.15 setup from this report.

The most useful findings so far are:

• In the frozen GUI process, there is no normal stdio:
  • _winapi.GetStdHandle(STD_INPUT_HANDLE) -> None
  • _winapi.GetStdHandle(STD_OUTPUT_HANDLE) -> None
  • _winapi.GetStdHandle(STD_ERROR_HANDLE) -> None
  • msvcrt.get_osfhandle(0/1/2) -> -2
• In that same process:
  • subprocess.run(..., stdin=None) succeeds
  • subprocess.run(..., stdin=0) also succeeds
  • asyncio.create_subprocess_exec(..., stdin=DEVNULL) under winloop succeeds
  • asyncio.create_subprocess_exec(..., stdin=None) under winloop fails with OSError: [Errno 9] bad file descriptor
  • asyncio.create_subprocess_exec(..., stdin=0) under winloop also fails with OSError: [Errno 9] bad file descriptor

A probe run from the frozen GUI process looked like this:

GetStdHandle(stdin)=None
GetStdHandle(stdout)=None
GetStdHandle(stderr)=None
msvcrt.get_osfhandle(0)=-2
msvcrt.get_osfhandle(1)=-2
msvcrt.get_osfhandle(2)=-2
winloop-first(stdin=None)=ERROR OSError: [Errno 9] bad file descriptor
winloop-first(stdin=0)=ERROR OSError: [Errno 9] bad file descriptor
winloop-first(stdin=DEVNULL)=(0, b'123\r\n')
subprocess.run(stdin=None)=(0, b'123\r\n')
subprocess.run(stdin=0)=(0, b'123\r\n')

[XiaoYouChR]

So this now looks much more like a winloop Windows subprocess stdio handling problem than a cx_Freeze problem.

The important detail is that a thin “ignore EBADF from os.dup(0)” style fix is not sufficient here. In this GUI/no-console case, os.dup(0) can still succeed, so the invalid state is not detected at dup-time and only shows up later when uv_spawn() returns UV_EBADF (which winloop converts to OSError: [Errno 9] bad file descriptor).

That suggests the Windows subprocess stdio path in winloop probably needs to move closer to CPython’s subprocess.Popen._get_handles() logic instead of treating stdio 0/1/2 as ordinary CRT fds:

• use GetStdHandle() for default stdio on Windows
• if the GUI/no-console parent has no real stdio handle, replace it with a real fallback handle instead of inheriting fd 0/1/2
• likely special-case stdio ints 0/1/2 on Windows as well, since stdin=0 currently fails in winloop but not in CPython in the same frozen process

This seems to be the same family of Windows GUI subprocess problem discussed in CPython issue #48155.

References:

• CPython issue: subprocess failing in GUI applications on Windows python/cpython#48155
• CPython Windows subprocess implementation: https://github.com/python/cpython/blob/v3.13.11/Lib/subprocess.py#L1351-L1426