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

[Vizonex]

@XiaoYouChR I'm gonna get to work on this now I'll make a fix for both winloop & uvloop soon.

[Vizonex]

@XiaoYouChR After some investigation I figured out something. here's a side by side comparison of with and without cx_freeze

import asyncio
import os
import winloop
import subprocess 
import msvcrt
import _winapi


async def main():
    with open("debug.txt", "w") as w:
        w.write("msvcrt.get_osfhandle\n")
        w.write(f"STDIN {msvcrt.get_osfhandle(0)}\n")
        w.write(f"STDOUT {msvcrt.get_osfhandle(1)}\n")
        w.write(f"STDERR {msvcrt.get_osfhandle(2)}\n")
        w.write("\n\n")
        w.write("_winapi.GetStdHandle\n")
        w.write(f"STDIN {_winapi.GetStdHandle(_winapi.STD_INPUT_HANDLE)}\n")
        w.write(f"STDOUT {_winapi.GetStdHandle(_winapi.STD_OUTPUT_HANDLE)}\n")
        w.write(f"STDERR {_winapi.GetStdHandle(_winapi.STD_ERROR_HANDLE)}\n")

# Ignore the fact that this will work without being async.
if __name__ == "__main__":
    winloop.run(main())

Without CX_Freeze

msvcrt.get_osfhandle
STDIN 168
STDOUT 172
STDERR 176


_winapi.GetStdHandle
STDIN 168
STDOUT 172
STDERR 176

With CX_Freeze

msvcrt.get_osfhandle
STDIN 18446744073709551614
STDOUT 18446744073709551614
STDERR 18446744073709551614


_winapi.GetStdHandle
STDIN None
STDOUT None
STDERR None

So I'm wondering if we just need to implement something small for winloop like this as an alternative to using _file_redirect_stdio(0) if the system.PLATFORM_IS_WINDOWS is set to 1?

p2cread = _winapi.GetStdHandle(_winapi.STD_INPUT_HANDLE)
if p2cread is None: # in the final version we could use NULL instead to get the same result from the C Version of the windows api.
   p2cread, _ = _winapi.CreatePipe(None, 0)
   # p2cread = Handle(p2cread) # maybe exclude Handle it's just an int subclass and it serves zero purpose to us.
   # err_close_fds.append(p2cread) # ignoreable
   _winapi.CloseHandle(_)

[XiaoYouChR]

Thanks for the detailed repro and investigation.

From a quick look at the Windows subprocess path, this seems likely to be a winloop edge case rather than something specific to cx_Freeze alone.

cx_Freeze with base="gui" produces a windowed/no-console executable, and in that kind of Windows process the default std handles may legitimately be missing. Python’s docs also mention that sys.stdin / sys.stdout / sys.stderr (and the original __stdin__ / __stdout__ / __stderr__) can be None for Windows GUI apps / pythonw.

CPython’s Windows subprocess code appears to account for that: when default std handles are missing, it does not just assume fd 0/1/2 are valid.

By comparison, winloop’s current Windows subprocess path seems to fall back to _file_redirect_stdio(0/1/2) when stdin / stdout / stderr are left as None, and _file_redirect_stdio() does a plain os_dup(fd). If that reading is correct, it would explain both:

• this cx_Freeze GUI repro, and
• the separate repro where closing parent fd 0 also causes EBADF.

So my guess is that cx_Freeze is probably just exposing a more general Windows stdio-inheritance issue in winloop.

My workaround with:

stdin=asyncio.subprocess.DEVNULL

also fits that theory pretty well, since it avoids the default stdin inheritance path.

If that is the right direction, maybe the Windows default-stdio path in winloop could validate the inherited/default std handles first, and fall back to something like DEVNULL (or equivalent ignore/null handling) when they are missing/invalid, instead of always duplicating the parent fd.

A small regression test based on either:

• a no-console/windowed parent process, or
• explicitly closing parent fd 0/1/2 before spawn

Thanks again for the effort you have put into this issue.

[Vizonex]

Thanks for the detailed repro and investigation.

If that is the right direction, maybe the Windows default-stdio path in winloop could validate the inherited/default std handles first, and fall back to something like DEVNULL (or equivalent ignore/null handling) when they are missing/invalid, instead of always duplicating the parent fd.

@XiaoYouChR My Theory on part of it may be windows going out of their way to preventing malware and not having standard inputs and outputs in gui mode, but besides that I really don't know. For now my plan in compat.h is the following. My uvloop fork will be getting same treatment/cure.

In C my plan will be this. I'm putting this into compat.h if you're curious

/* There is a bug with CX-Freeze on windows when compiled
 * to an exe this tries to fix it by seeing if alternate 
 * workarounds like DEVNULL need to be provided. 
 * SEE: https://github.com/Vizonex/Winloop/issues/126 */

#ifdef _WIN32
/* CPython version might be slower so will use our own functions, audits can be a costly thing to keep track of. */

static int _get_std_handle(DWORD std_handle){
    HANDLE handle = GetStdHandle(std_handle);
    if (handle == INVALID_HANDLE_VALUE){
        goto error;
    }
    /* We don't need this handle open we just want to know 
    if windows wants to play nice or not. executable vs not executable. */
    int windows_misbehaved = (handle == NULL) ? 1: 0;
    (void)CloseHandle(handle);
    /* if handle == 0 use DEVNULL as backup instead otherwise use the default method. */
    return windows_misbehaved;
error:
    /* if handle == -1 throw an error */
    PyErr_SetFromWindowsErr(GetLastError());
    return -1;
}

/* Because these are macros it's very easy to make a workaround for unix. */
#define __GET_INPUT_HANDLE() _get_std_handle(STD_INPUT_HANDLE)
#define __GET_OUTPUT_HANDLE() _get_std_handle(STD_OUTPUT_HANDLE)
#define __GET_ERROR_HANDLE() _get_std_handle(STD_ERROR_HANDLE)

#else
/* On Unix these are not needed, but we define it anyways so the 
compiler doesn't wind up throwing a fit about it */

#define __GET_INPUT_HANDLE() -1
#define __GET_OUTPUT_HANDLE() -1
#define __GET_ERROR_HANDLE() -1
#endif

Thanks again for the effort you have put into this issue.

You're welcome ^^ I spent about 6 hours figuring this out and investigating this.