Repository navigation
test_cmd_line: test_python_legacy_windows_stdio() fails with STATUS_DLL_INIT_FAILED (hex: c0000142, dec: 3221225794) #150436
Description
Activity
A variant of the issue: test_msvcrt.test_getwche() fails with exit status 3221225794.
Windows (free-threading) / Build and test (x64, switch-case): https://github.com/python/cpython/actions/runs/26425887065/job/77789325591?pr=150440
ERROR: test_getwche (test.test_msvcrt.TestConsoleIO.test_getwche) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\a\cpython\cpython\Lib\test\test_msvcrt.py", line 102, in test_getwche self.check_getwch('getwche') ~~~~~~~~~~~~~~~~~^^^^^^^^^^^ File "D:\a\cpython\cpython\Lib\test\test_msvcrt.py", line 92, in check_getwch self.run_in_separated_process(code) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^ File "D:\a\cpython\cpython\Lib\test\test_msvcrt.py", line 70, in run_in_separated_process subprocess.run(cmd, check=True, capture_output=True, ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ creationflags=subprocess.CREATE_NEW_CONSOLE) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "D:\a\cpython\cpython\Lib\subprocess.py", line 692, in run raise CalledProcessError(retcode, process.args, output=stdout, stderr=stderr) subprocess.CalledProcessError: Command '['D:\\a\\cpython\\cpython\\PCbuild\\amd64t\\python_d.exe', '-c', '\nimport msvcrt\nfrom _testconsole import write_input\nwith open("CONIN$", "rb", buffering=0) as stdin:\n write_input(stdin, b\'W[\')\n assert msvcrt.getwche() == "å—"\n']' returned non-zero exit status 3221225794.Hmm... I wonder if we're copying
vcruntime140*.dllaround poorly in the new build arrangement?That error code means the DLL initialization failed, which usually only happens if you're doing weird mixing of C runtimes or if you've copied/symlinked files around and tried to launch them (which I guess is what we're doing here, since we do that in a number of tests)
The Python test suite spawns tons of subprocesses. I'm curious why only test_python_legacy_windows_stdio() and test_getwche() fail!? For example, test_msvcrt also spawns subprocesses in test_kbhit() and test_getwch(). By the way, the 3 test_msvcrt tests using subprocesss use
creationflags=subprocess.CREATE_NEW_CONSOLE.test_getwche() and test_python_legacy_windows_stdio() tests have one thing in common: the usage of
creationflags=subprocess.CREATE_NEW_CONSOLEflag.But the test suite has other tests using
creationflags=subprocess.CREATE_NEW_CONSOLEwhich don't seem to fail with " exit status 3221225794":- test_msvcrt: test_kbhit() and test_getwch()
- test_subprocess: test_creationflags()
It's really hard to find fresh information about STATUS_DLL_INIT_FAILED (hex: c0000142, dec: 3221225794) error.
I found an article from 2012 (very old!) about "Non-interactive desktop heap size" and user32.dll initialization failure: https://community.progress.com/s/article/18726 It suggests modifying the 3rd number in
SharedSectionofHKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windowsregistry key. I'm not sure if it's relevant here.Another article mentioning heap memory: https://docs.azure.cn/en-us/service-fabric/service-fabric-diagnostics-code-package-errors
STATUS_DLL_INIT_FAILED
This error sometimes means that the machine has run out of desktop heap space. This cause is especially likely if you have numerous processes that belong to your application running on the node.Windows (free-threading) / Build and test (x64, switch-case): https://github.com/python/cpython/actions/runs/26421370296/job/77776609299?pr=150432
test_python_legacy_windows_stdio() failed when running tests (test_cmd_line) in parallel, and it failed again when 2 tests were re-run in parallel:
0:00:00 mem: 46.2 MiB Run 505 tests in parallel using 6 worker processes (timeout: 10 min, worker timeout: 15 min) ... 0:05:08 load avg: 3.57 mem: 478.2 MiB [258/505/1] test_cmd_line failed (1 failure) (36.4 sec) -- running (2): test_tkinter (30.7 sec), test_tarfile (44.9 sec) ... 0:12:34 load avg: 2.80 mem: 32.2 MiB Run 2 tests in parallel using 2 worker processes (timeout: 10 min, worker timeout: 15 min) ... 0:12:36 load avg: 2.78 mem: 71.5 MiB [1/2/1] test_profiling failed (1 failure) ... 0:12:39 load avg: 2.64 mem: 29.5 MiB [2/2/2] test_cmd_line failed (1 failure)Windows (free-threading) / Build and test (x64, switch-case): https://github.com/python/cpython/actions/runs/26425887065/job/77789325591?pr=150440
test_getwche() failed when tests (test_msvcrt) were run in parallel, but it passes when 2 tests (test_msvcrt, test_profiling) were re-run in verbose mode in parallel.
The problem is that it's a generic error code that could come from any of the DLLs being loaded when a new console window is created. Without actually knowing which one is causing it, there's not much we can do, and even then I'd guess it's more likely we'd need to slow down the tests or fix the host machine, or maybe even skip these tests in a CI setup.
Just recently I've faced the same error at $WORK. In our case it was indeed related to running out of desktop heap space, because we've created a lot of processes with an attached console in a service. The non-interactive system service uses a much lower default heap space, see https://learn.microsoft.com/en-us/troubleshoot/windows-server/performance/desktop-heap-limitation-out-of-memory, where
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystemsSharedSection=1024, 20480,768
The third SharedSection value is the size of the desktop heap for each desktop that is associated with a non-interactive window station. The value is in kilobytes (KB).
Increasing the value in the registry from
768to20480fixed the issue for us.Maybe github action workflows suffer the same limit? Can / should we increase the registry setting in CI?
Or just lower the number of spawned processes?
Can / should we increase the registry setting in CI?
There are users running the test suite on their own Windows machine who can face the same issue. I would prefer to either fix subprocess (increase the heap memory, if it's possible?), or fix the test (skip the test once if we detect that the memory is low, or that the test failed because of low memory).
A simple fix is to skip test_getwche() and test_python_legacy_windows_stdio() if the process fails with 3221225794 with a comment explaining the issue.
I wrote PR gh-150704 to skip the few tests creating processes using CREATE_NEW_CONSOLE creation flag if the process fails with STATUS_DLL_INIT_FAILED.
Reacted by Chris Eibl- added 4 commits that reference this issue
on Jun 1, 2026
Bug report
Windows (free-threading) / Build and test (x64, switch-case): https://github.com/python/cpython/actions/runs/26421370296/job/77776609299?pr=150432
Linked PRs