GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Windows: python.exe fails to start from a long path because of DLL manifests · Issue #160624 · python/cpython

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

New issue
Copy link
New issue
Copy link
Open
Open
Windows: python.exe fails to start from a long path because of DLL manifests#160624
Copy link
Labels
OS-windowsbuildThe build process and cross-buildThe build process and cross-buildtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

Description

@mkanat
mkanat
opened on Oct 24, 2026
Issue body actions

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-160624: Stop embedding a manifest in Windows DLLs and extension modules #160626

Activity

  1. NekoAsakura
    added
    type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
    OS-windows
    buildThe build process and cross-buildThe build process and cross-build
    on Oct 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    OS-windowsbuildThe build process and cross-buildThe build process and cross-buildtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.