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.

Beginnen Sie mit dem Ausführungsaliaspfad von python.exe und reproduzieren Sie die geplante bare-python-Workload, während Sie das Ereignis 603 von AppXDeploymentServer/Operational und die privaten Bytes von AppXSvc überwachen. Untersuchen Sie, ob wiederholte Starts UpdateUsingAppInstaller-Vorgänge in die Warteschlange stellen, und überprüfen Sie anschließend, dass ein bereits installierter Interpreter bei jedem Start keinen Vorgang mehr auslöst und dass die gemeldete Ereignisserie endet.