Is python.exe real on Windows 11

Nice to know
1

On a clean installation of Windows 11, Python is not installed by default. However, running:

> where python.exe
C:\Users\Groot\AppData\Local\Microsoft\WindowsApps\python.exe

may still return a result.

This can be misleading.

Why This Happens

Windows 10 and Windows 11 include App Execution Aliases for certain applications, including Python. These aliases create stub executables in:

%LOCALAPPDATA%\Microsoft\WindowsApps

The WindowsApps directory is included in the PATH environment variable by default for user accounts.

image
image522Ă—499 5.12 KB

Microsoft documentation:

On a modern Windows installation, a python.exe that appears under %LOCALAPPDATA%\Microsoft\WindowsApps is typically an App Execution Alias (implemented as a Windows-managed reparse-point link), not a “normal” python.exe binary. (ref)

When a machine does not have a real Python runtime installed, Windows includes a Python “shortcut executable” intended to route users to install Python via the Microsoft Store; Microsoft explicitly describes this as a Windows shortcut added to help users get Python. (ref)

image
image357Ă—205 14.9 KB

After installing Python from the Store, the python /python3 commands become “real” from the user’s perspective (they launch an actual interpreter), but the WindowsApps\python.exe entry may still be an alias/link rather than the interpreter binary itself. Microsoft describes the Store install as replacing the default python /python3 commands with “real ones,” while the alias mechanism remains how Windows exposes packaged executables on PATH.

Practical Impact

This behavior can interfere with build systems or tooling that expect:

  • python.exe to be a real interpreter
  • where python.exe to return only valid installations

If the user runs python with arguments (the common case for tools)

This is the most important nuance for build systems.

Microsoft states: running the shortcut executable with any command-line arguments returns an error code indicating that Python is not installed, and the purpose is to prevent batch files/scripts from opening the Store unexpectedly.

Practically, that means:

  • python --version
  • python -c "print(1)"
  • python some_script.py

…will not launch a working interpreter on a machine with only the alias present; instead they fail fast with a non-zero exit and typically emit an error message.

The widely observed console message looks like: “Python was not found; run without arguments to install from the Microsoft Store, or disable this shortcut…” (seen across tooling and support threads).

C:\Users\Groot>python -version
Python was not found; run without arguments to install from the Microsoft Store, or disable this shortcut from Settings > Apps > Advanced app settings > App execution aliases

In this case, the issue surfaced while attempting to set up Janus and needing a completely clean Python environment. To verify behavior from a true baseline:

  • A new Hyper-V virtual machine was created
  • Windows 11 was installed from an ISO image
  • The behavior was confirmed on a fresh OS instance

Microsoft documentation on Hyper-V:

This distinction is subtle but important when working with clean environments, reproducible builds, or automated configuration scripts.

The details in the topic were checked using ChatGPT Deep Research an then manually verified as accurate.

2

(post deleted by author)

3

Where does the problem appear specifically? During cmake or while you load janus? Do you notice it on msys2?

When I invoke test_installation under msys2, I usually have to prepend PYTHONHOME=/ucrt64 before I invoke swipl. That may be related to the behavior you describe

1 Like
4

At this stage, I am not analyzing the issue from a single failure point.

My primary objective is broader: to determine how to reliably and reproducibly build SWI-Prolog with MSVC on Windows, including:

  • Required files and their locations
  • Necessary PATH updates
  • Any required registry settings
  • Environment variables (e.g., PYTHONHOME)

While working toward that goal, I encountered several issues:

  • CMake configuration failures when python.exe was not found.
  • Discovery that Janus depends on python3.dll, which on Windows is not necessarily located in the same directory as python.exe.
  • A locale-related issue (if I recall correctly) that was resolved by correcting PATH.
  • Indications that PYTHONHOME may also be required in certain scenarios.

The deeper I investigated, the more complex the environment interactions became. Instead of fully dissecting each failure immediately, I am first focusing on establishing a configuration that works end-to-end. Once I have a fully reproducible process, I plan to systematically remove variables and identify precisely which components are required and which are incidental.

I have observed failures at multiple stages:

  • CMake configuration
  • CMake build
  • check_installation in SWI-Prolog

So the issues does not appear isolated to a single phase.

I have not tested MSYS2 recently. For the past few weeks, my focus has been exclusively on MSVC-based builds.

I am seeing similar signs that PYTHONHOME may be required, but it is not yet clear:

  • Which component requires it
  • At what stage it becomes necessary
  • Whether it is strictly required or compensating for another configuration issue

My plan is to:

  1. Get the full process working reliably through to cpack -C Release.
  2. Once that is stable, remove environment variables and adjustments one at a time.
  3. Identify exactly what breaks and at which stage.

One useful finding so far: when building with MSVC and using vcpkg, the Python3 vcpkg package contains all required files. In that setup:

  • Adding two directories to PATH
  • Setting PYTHONHOME

appears sufficient.

No additional CMake options were required in that configuration.