Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Windows: python.exe fails to start from a long path because of DLL manifests

Offen
#160,624 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
28/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
python
Bereich
build-system

Rechercherichtung

Read PC/python_nt.rc and PC/sqlite3.rc, then inspect the executable resource scripts to compare how manifests are embedded. The proposed change removes the ID 2 manifest resource and its fallback define from the two DLL resource scripts; keep the executable manifests at ID 1. Done means DLLs no longer embed that manifest while the executables retain theirs, and long-path startup and extension imports work on Windows.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

build OS-windows type-bug
Bug report
Problem

python.exe fails to start with STATUS_NAME_TOO_LONG once its path is 247 characters or longer, even with LongPathsEnabled=1. It turns out this is actually from loading the DLL, not from python.exe itself.

Extension modules like _ctypes and _ssl also fail to import when the install is at a long path.

Cause

The build is creating DLLs with a manifest, and as noted in #126929, Windows can't load a DLL with an embedded manifest from a path near MAX_PATH.

Since about 2010, the manifest doesn't do anything in a DLL. Windows takes the supported OS versions and the Common Controls dependency from the EXE's manifest, not a DLL's.

History

DLLs used to need a manifest. With Visual C++ 2008, which Python 2.6 through 3.2 were built with, a DLL had to declare its dependency on the C runtime in an embedded manifest to find it. However, Visual C++ 2010 stopped using manifests to find the C runtime, so DLLs haven't needed one since.

#67207 (bpo-23018) added the manifest to python_nt.rc in 2015, at the same time as the one for python[w].exe, to declare supportedOS so that GetVersion would stop reporting Windows 8 on newer versions.

In 2016, #71496 (bpo-27309) added the Common Controls dependency so that tkinter's native dialogs would get the right styles. From that change: "Windows needs to load a different version of a particular DLL for the entire process." However, that's only information that the process needs, not the DLLs.

#71918 (bpo-27731) added longPathAware later that year.

Where the manifest comes from now

PC/python_nt.rc embeds PC/python.manifest as resource ID 2, and pythoncore, python3dll, and every extension module project in PCbuild use that resource script. PC/sqlite3.rc does the same for sqlite3.dll.

Possible Solution

Remove the 2 RT_MANIFEST "python.manifest" line, and the RT_MANIFEST fallback define above it, from PC/python_nt.rc and PC/sqlite3.rc. python_exe.rc and pythonw_exe.rc keep embedding the manifest as ID 1.

Note: #156759 doesn't help here, because Windows loads python3XY.dll as a static import of python.exe, before any Python code runs.

CPython versions tested on:

3.14

Operating systems tested on:

Windows

Linked PRs
  • gh-160626
Vorherrschende Sprache
Python
Sterne
77.7k
Forks
38.3k
Ø Merge
13 Std. 30 Min.
Gemergte PRs (30 T.)
708

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus python/cpython

Alle Issues in python/cpython

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.