Summary
Every launch of python.exe, python3.exe or py.exe through the App Execution Aliases in
%LOCALAPPDATA%\Microsoft\WindowsApps leaves one CPU-rate-controlled job object alive in the Windows DcomLaunch service
host. It is never freed until reboot. Launching the same runtime through %LOCALAPPDATA%\Python\bin\python.exe, or the
pythoncore-* exe directly, leaks nothing.
The bug is in Windows, not in pymanager: the winget.exe alias leaks the same way, and it has been reported to
Microsoft through Feedback Hub. But pymanager's default setup sends every bare python/py call through the alias, so
pymanager users who run Python often (scripts, build steps, editor and agent hooks) build up thousands of these.
Impact
On my machine a tool hook ran python on every command. After 17 days of uptime there were 17,342 leaked jobs. Each
one adds a scheduling group that Windows walks on every core park and unpark (KiTransitionSchedulingGroupGeneration).
Those transitions grew from microseconds to 4-18 ms inside a DPC, which caused constant USB audio dropouts and UI
stutter. A reboot cleared it; changing the hook to call Python\bin\python.exe stopped it coming back (113 leaked jobs
after 3.5 days, all from other Windows components).
Reproduce
Count the PsJb kernel pool tag (poolmon, or NtQuerySystemInformation(SystemPoolTagInformation)) before and after
20 launches of each:
| 20 launches of |
Leaked jobs (PsJb outstanding) |
%LOCALAPPDATA%\Python\pythoncore-3.14-64\python.exe -I -c pass |
0 |
%LOCALAPPDATA%\Microsoft\WindowsApps\python.exe -I -c pass |
+21 |
%LOCALAPPDATA%\Python\bin\python.exe -I -c pass |
0 |
%LOCALAPPDATA%\Microsoft\WindowsApps\py.exe -I -c pass |
+19 |
%LOCALAPPDATA%\Microsoft\WindowsApps\winget.exe --version |
+27 to +40 |
PsJb blocks are only allocated for jobs with CPU rate control (7,296 bytes each); a plain job allocates none. A pool
trace attributes the leaked blocks to the DcomLaunch svchost, allocated through
NtSetInformationJobObject > PspAddSchedulingGroupToJobChain > PspAllocateRateControl about 66 ms after each alias
launch. I can attach a standalone PowerShell repro script.
Environment: Windows 11 Pro 26200.9457 x64, Python Install Manager 26.4.240.0 (Store), Python 3.14.5.
Suggestions
Until Windows fixes it, pymanager could steer users away from the aliases:
- During
py install --configure (or first run), offer to put %LOCALAPPDATA%\Python\bin ahead of
%LOCALAPPDATA%\Microsoft\WindowsApps on PATH, or to turn off the python/python3 aliases once Python\bin is on PATH.
- Ship a non-alias
py.exe in Python\bin. Today py exists only as an alias, so turning the aliases off removes it.
- Mention the issue in the docs for people who call Python many times (CI, hooks, build tools).
repro-alias-job-leak.ps1.txt
