I have Python 3.9 installed from the Windows Store and use it in CMake scripts.

After the recent update to 3.92288.0 Python executions suddenly started failing with "Access is denied". I assumed I was using a wrong or cached path but that didn't turn out to be the case.

It did find the executable in the (apparently) correct folder "C:/Program Files/WindowsApps/PythonSoftwareFoundation.Python.3.9_3.9.2288.0_x64__qbz5n2kfra8p0/python3.9.exe".

I tried running that via the command-line and it failed with "Access is denied." as well. It appears to be related to "C:/Program Files/WindowsApps" requiring Administrator permissions.

Also just running "python3.9.exe" (which exists in the PATH) no longer works. It fails with "The system cannot find the file C:\Users\<username>\AppData\Local\Microsoft\WindowsApps\python3.9.exe."

So it seems the update messed something up.

I had Python 3.9 installed and working fine for some version now. I ran into something similar in the past and had to uninstall and install it again to fix the problem.

I am using Windows 10 Version 21H1 (OS Build 19043.1348).

If you open "Manage app execution aliases", do you see the entries for Python? I've heard that they sometimes switch themselves off during updates, but nobody seems to know why. Even if not, disabling and re-enabling them may help.

The executable in Program Files cannot be launched except in a few oddly specific circumstances. I've spoken to the team responsible and they consider this part of the feature, so the execution aliases mentioned above are the way to go (these live in your own AppData folder - check sys.executable once you get it going again).

I checked them and they look fine. I have Python 3.10 installed as well so the non-suffix and "3" suffix-only executable refer to that. All the "3.9" suffix ones point to the "Python 3.9" entries and are enabled.

Can you look in your %LocalAppData%\Microsoft\WindowsApps folder and see 
if the python*.exe files are there? You should be able to double-click 
them to launch them.

That folder should be on your PATH so that they work everywhere, and it 
should reflect what you see in Manage App Execution Aliases. If it 
doesn't, that's a Windows bug, and I'll need as much detail as we can 
get to reproduce and report it to them.

>  It fails with "The system cannot find the file 
>  C:\Users\<username>\AppData\Local\Microsoft\WindowsApps\python3.9.exe."

The shell's CreateProcessW() call failed with ERROR_FILE_NOT_FOUND (2). The file exists, but it's probably a broken appexec link. I'm attaching a script that displays the contents of an appexec link. For example, here's the working "python3.9.exe" link:

    C:\>read_appexec.py "%LocalAppData%\Microsoft\WindowsApps\python3.9.exe"
    Version: 3
    Package ID: PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0
    Entry Point: PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0!Python
    App Type: 0
    Target Path:
    C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.9_3.9.2288.0_x64__qbz5n2kfra8p0\python3.9.exe

---

> The executable in Program Files cannot be launched except in a few
> oddly specific circumstances.

The SYSTEM, LOCAL SERVICE, and NETWORK SERVICE accounts can directly execute the real executable. For standard users, however, a conditional access control entry is set in the file's permissions that allows execute access only if the accessing security context has the app's WIN://SYSAPPID, such as "PYTHONSOFTWAREFOUNDATION.PYTHON.3.9_QBZ5N2KFRA8P0". When CreateProcessW() spawns an app from an appexec link, it adds the required WIN://SYSAPPID to a new token that gets created for the process. The app itself can thus directly load and execute binary images (EXEs, DLLs) from its installation directory under "%ProgramFiles%\WindowsApps".