Every alias launch starts an AppX UpdateUsingAppInstaller operation - scheduled workloads grew AppXSvc to 22 GB and exhausted system commit

Every launch of the python.exe execution alias starts an AppX deployment operation in the background (UpdateUsingAppInstallerOperation, event 603 in AppXDeploymentServer/Operational). On a machine where scheduled jobs call bare python a few times a minute, those operations made AppXSvc's svchost grow to 22 GB of commit over 2.3 days, until total system commit ran out and every allocation-heavy process on the box started dying at once (all terminal windows, browsers, git). Windows kills whichever process asks for memory at the ceiling, not the service holding it, so the failure looked like random app crashes and took a while to trace back here.

The unbounded growth itself is arguably AppXSvc's problem, not pymanager's. I'm reporting it here because the per-launch deployment operation originates with the pymanager package, pymanager is in a position to avoid or debounce it, and I could not find this failure mode reported anywhere (searched this tracker for AppXSvc / leak / UpdateUsingAppInstaller before filing).

Environment

• Windows 11 Home 25H2, build 26200.8875. AppXSvc ran with StartType=Automatic on this machine (i.e. permanently resident — which is what let the growth accumulate 24/7; it appears the Dec 2025 cumulative KB5072033 made it Automatic, it is Manual on stock systems).
• Package name as it appears in the events: PythonSoftwareFoundation.PythonManager_26.3.240.0_x64__3847v3x7pw1km
• Workload: a dozen-plus scheduled jobs (Task Scheduler plus a process manager) invoking bare python, which resolved to the WindowsApps alias.

What I measured

• Event 603 fires for the PythonManager package on every alias launch. In the 20 most recent events before I changed my PATH, 20/20 were PythonManager UpdateUsingAppInstaller, with timestamps matching the schedulers' cadence exactly.
• Final 24 h before reboot: 6,400 events (~266/h). Earlier in the same incident I measured ~58/h — the rate simply tracks how often something runs python.
• AppXSvc's svchost reached 22 GB commit in 2.3 days. Its working set stayed small the whole time, so Task Manager's default view showed nothing unusual; Resource-Exhaustion-Detector (System log, event 2004) is what finally named it as the top commit consumer.
• End state: commit ceiling hit (64 GB RAM + 27 GB pagefile). The svchost could not be stopped — taskkill /F as SYSTEM failed and sc stop returned 1061 — only a reboot released the memory.

Repro sketch

1. pymanager installed, its python.exe alias first on PATH.
2. AppXSvc resident (Automatic start, or started manually and left running).
3. Run python -c "pass" through the alias every 30-60 s with any scheduler.
4. Watch event 603 accumulate and the AppXSvc svchost's private bytes climb over hours.

Expected

Launching an already-installed interpreter shouldn't enqueue a deployment/update operation on every launch. Debouncing the check (once a day would be plenty) would make unattended workloads unable to grind AppXSvc regardless of the service-side leak.

Workaround that ended it

Real interpreter directory prepended to PATH, explicit interpreter paths in the scheduled jobs, AppXSvc back to demand start. After a reboot, event 603 went from ~266/h to zero across the same scheduled workload.

I can attach exported event logs (the 603 series and the event 2004 record) or run diagnostics on a live setup if that helps.

从 python.exe 的执行别名路径开始，在监视 AppXDeploymentServer/Operational 事件 603 和 AppXSvc 专用字节数的同时，重现计划的 bare-python 工作负载。调查重复启动是否会将 UpdateUsingAppInstaller 操作加入队列，然后验证已安装的解释器不再在每次启动时触发一个操作，并且报告的事件序列会停止。