(uv internal error) Failed to spawn the python child process: entity not found. (os error 2)

[NicoCaldo]

Summary

I'm using an IDE that builds and compiles C and C++ projects using Make (IAR Workbench)

I have a post-build command that should launch a Python script that must read a .bin file and generate a .crc file

The post-build command line is

python3.11 <folder of the python script>\generate_crc_stm32.py <folder of the bin file>\firmware.bin

But I'm getting

	cmd /C cd C:\<fodler of IAR project>\EWARM\Appli && python3.11 python3.11 <folder of the python script>\generate_crc_stm32.py <folder of the bin file>\firmware.bin		
	(uv internal error) Failed to spawn the python child process: entity not found. (os error 2)	

If I try to open the cmd and run the exact same script as above, it works correctly. Path are correct

My Python script is just a simple .py with inside a

import sys
import os

..

def main():

..

if __name__ == '__main__':
    main()

Using uv run instead works

Platform

Windows 10 Pro 64bit 22H2

Version

uv 0.10.2 (a788db7 2026-02-10)

Python version

Python 3.11.11

[konstin]

In your snippet it says python3.11 python3.11, is that the problem?

[konstin]

Can you provide a complete example of how you get that error? I can't reproduce it on my machine.

[NicoCaldo]

In your snippet it says python3.11 python3.11, is that the problem?

You were right, for some reason, the Python command was pasted twice
Thanks

[konstin]

FWIW, I'd still be interested in a reproduction for this, we should actually never show that error, and where we do, we should show something better than (uv internal error) Failed to spawn the python child process: entity not found. (os error 2)

[NicoCaldo]

To reproduce it, you'll need an IAR Embedded Workbench (I'm using 9.20.4). Create a project in it.
Then, in project settings, Options, build action, post build action, and add the execution of a Python script using python3.11 (making sure Python 3.11 is installed using uv).

Then you can build your project and, at the end, if the build succeeds, the command python3.11 will be executed

It's a bit convoluted because it's a very specific use case. I think the Python script itself is not an issue, as it won't even be executed when the error occure

[ShadowLNC]

I was also able to trigger this through a Windows Container on Windows (WCoW), building as follows:

FROM mcr.microsoft.com/windows/servercore:ltsc2025

RUN powershell -ExecutionPolicy ByPass -c `
    "irm -ErrorAction Stop https://astral.sh/uv/install.ps1 | iex -ErrorAction Stop"
RUN uv python install 3.14
RUN python3.14

this fails to build at the last RUN step:

error: uv trampoline failed to spawn Python child process
   Caused by: entity not found (os error 2)

I can file a separate issue if you like, since this is a repeatable issue but I recognise it may be considered unsupported.

Junction link investigation details

It seems like there's some problem with the junction link, when I run dir /al it shows the target as 02/17/2026 02:51 PM <JUNCTION> cpython-3.14-windows-x86_64-none [\??\C:\opt\uv\python\cpython-3.14.3-windows-x86_64-none] which then becomes 02/17/2026 02:51 PM <JUNCTION> cpython-3.14-windows-x86_64-none [] (empty target) in the next RUN dir /al step.

Conversely, if I perform RUN cd C:\ && mkdir abc && mklink /d sym abc && mklink /j jun abc && dir then the junction link is just shown with a target of [C:\abc] (note no \??\) and persists in the next RUN dir step.

Using powershell -c "Get-ChildItem -Path 'C:\opt\uv' -Recurse | Where-Object { $_.LinkType } | Select-Object Name,LinkType,Target,Attributes" doesn't show the \??\ prefix on the uv-created junction - not sure if this is relevant. (It also shows as an empty target in subsequent RUN steps.)

After asking investigating the \??\ prefix, it turns out that uv is not setting the Print Name on the junction, but only setting the Substitute Name. When I run fsutil reparsepoint query [file] I can see the Print Name is empty, and on subsequent RUN steps/layers, both are empty for the uv-defined junction, so it seems that the Print Name is being replicated into the Substitute Name in the container layers. With my C:\jun, I can see both are initially set, and both remain set in subsequent RUN steps.

(I'm using Buildkit, containerd, and nerdctl on Windows with an install process adapted from the Buildkit docs, but I suspect it would do the same thing on Docker too.)