Skip to content

Python Install Manager 26.4.240.0 fails to launch on Windows 10 22H2 #433

Open

Description

@AmirHosein8304

Python Install Manager 26.4.240.0 fails to launch on Windows 10 22H2

Description

I installed Python Install Manager version 26.4.240.0 on Windows 10, but its command-line launchers (py.exe and pymanager.exe) consistently fail to execute.

The package appears to be installed and registered successfully, but neither py nor pymanager works. I can run my existing Python installation directly using C:\Python314\python.exe.

Environment

  • OS: Windows 10, version 22H2
  • OS build: 19045.7725
  • Architecture: x64
  • Python Install Manager: 26.4.240.0
  • Package family: PythonSoftwareFoundation.PythonManager_3847v3x7pw1km
  • Package full name: PythonSoftwareFoundation.PythonManager_26.4.240.0_x64__3847v3x7pw1km
  • Install location: C:\Program Files\WindowsApps\PythonSoftwareFoundation.PythonManager_26.4.240.0_x64__3847v3x7pw1km
  • PowerShell: Windows PowerShell 5.1
  • Existing Python installation: Python 3.14.0 at C:\Python314\python.exe

Steps to reproduce

  1. Install Python Install Manager 26.4.240.0 using the official MSIX package.

  2. Confirm that Python Install Manager aliases are enabled under Manage app execution aliases.

  3. Open Windows PowerShell 5.1.

  4. Run:

    pymanager --version
    py list

Actual behavior

The commands fail with errors such as:

Program 'pymanager.exe' failed to run:
The specified executable is not a valid application for this OS platform.

Other attempts have produced:

Program 'py.exe' failed to run:
The file cannot be accessed by the system.

and:

Program 'pymanager.exe' failed to run:
The system cannot find the file specified.

Running pymanager.exe directly from the package installation directory has also failed with Access is denied.

Diagnostics already performed

  • Get-AppxPackage -Name PythonSoftwareFoundation.PythonManager reports Status: Ok.
  • Get-AppxPackage -AllUsers -Name PythonSoftwareFoundation.PythonManager confirms that the package is installed for the current user.
  • Microsoft.DesktopAppInstaller and Microsoft.WindowsStore also report Status: Ok.
  • The package's pymanager.exe exists in the installation directory and has a reported size of 313,856 bytes.
  • The user-level aliases in %LOCALAPPDATA%\Microsoft\WindowsApps exist as zero-byte reparse points.
  • The Python Install Manager aliases are enabled.
  • Toggling the relevant app execution alias off and on did not resolve the problem.
  • Running winget repair --id Python.PythonInstallManager --exact did not resolve the problem.
  • Installing the official MSIX package directly did not resolve the problem.
  • Python 3.14.0 continues to run when invoked directly.

Relevant Windows event log errors

The Microsoft-Windows-AppXDeploymentServer/Operational log contains these failures for the Python Install Manager package:

  • Event ID 404, error 0x8007042B: Deployment operation failed.
  • Event ID 404, error 0x80073CF8: Deployment Add operation ... failed.

Other events show successful package registration (Event ID 400) and package state Ok, so the underlying cause remains unclear.

Expected behavior

The py and pymanager commands should launch normally and allow me to manage Python installations.

Questions

  1. Is Python Install Manager 26.4.240.0 fully supported on Windows 10 22H2, build 19045?
  2. Could this be a known issue involving MSIX package registration, app execution aliases, or Windows AppX deployment?
  3. What additional diagnostic steps or logs would help identify the root cause without uninstalling my existing Python installations?

Thank you.

Activity

  1. zooba commented on Oct 21, 2026

    @zooba
    Member
    1. Is Python Install Manager 26.4.240.0 fully supported on Windows 10 22H2, build 19045?

    Firstly, no. You can see the non-end of life versions of Windows here, and that version is considered end of life by Microsoft, which means we don't fully support it.

    That said, we'd like it to work if possible.

    1. Could this be a known issue involving MSIX package registration, app execution aliases, or Windows AppX deployment?

    If it is, the fix is to update Windows, not for us to change anything on our side. All the bugs that were found in the last 4 years will have been fixed in a more recent release of the OS, so I'm afraid the way to get the fix is to update.

    1. What additional diagnostic steps or logs would help identify the root cause

    Everything you've described sounds normal. The errors in the event log shouldn't be a problem if they aren't the most recent attempt to install.

    Have you tried launching the "Python install manager" entry in the Start menu? And have you tried navigating to the folder with the app exec aliases and double-clicking them? Sometimes a GUI launch will get a more detailed error message than a console launch.

    The only time I've seen error like these with aliases has been a corrupt database, which disabling/re-enabling the aliases should fix, or corrupt permissions on either the aliases directory or the install directory (normally caused by my own messing about with them). You haven't mentioned that you've done anything here, but normally people who know where the folder is have at least granted themselves read access to the WindowsApps directory in Program Files, which has the potential to cause issues. There's no way to reset the ACL (please ignore the online "advice" - it's all wrong) other than an OS reset (os possibly an update) and reinstalling all packages, but that's the most likely problem I can think of that you would be able to fix.

  2. AmirHosein8304 commented on Oct 22, 2026

    @AmirHosein8304
    Author

    Thanks for the suggestions. I tried both launching the application from the Start menu and running the app execution alias directly.

    Here are the results:

    • Launching Python install manager from the Start menu produces no visible response.
    • Double-clicking py.exe in the package-specific app execution aliases directory produces:
      The file cannot be accessed by the system
    • Running py-manager.exe directly from the package installation directory fails with Access is denied.
    • Running pymanager.exe --version directly from the package installation directory also fails with Access is denied.

    The package is registered and reports Status: Ok. Both py-manager.exe and pymanager.exe exist in the package directory and have a size of 313,856 bytes.

    I also checked the Microsoft-Windows-AppModel-Runtime/Admin event log. Each recent launch attempt produces Event ID 202 with this message:

    0x790050: Cannot create the process for package because an error was encountered.

    The event identifies the application as:

    PythonSoftwareFoundation.PythonManager_3847v3x7pw1km!Pymanager.Exe

    The Microsoft-Windows-TWinUI/Operational log contains no matching events.

    I have not intentionally changed the ACLs on the WindowsApps directories. The permissions currently reported by icacls show Full Control for my user on the user-level WindowsApps and Python alias directories. I have not attempted to reset or modify the WindowsApps permissions.

    Given these results, is updating Windows the only recommended next step? If so, could you clarify the minimum supported Windows version for Python Install Manager 26.4.240.0? I would prefer to avoid an OS reset or reinstall unless there is strong evidence that it is necessary.

  3. zooba commented on Oct 22, 2026

    @zooba
    Member

    Our only reasonable recommendation would be to be on the latest update of the OS. We won't do anything to intentionally break on any non-EOL version (and sometimes we do extra things to try and work with older OS versions even if they are end-of-life), but for things that are clearly OS errors we have no way to debug them unless you're on the latest version.

    If you're able to figure out what Python or PyManager is doing to cause it, we're happy to consider fixing it. We just don't have any way to figure it out.

    The link I posted in my last comment has the EOL dates for various Windows updates. That's our "rule", but as I say, the practicalities are that we can't do much for anything but the latest version.

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

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions