Repository navigation
Every alias launch starts an AppX UpdateUsingAppInstaller operation - scheduled workloads grew AppXSvc to 22 GB and exhausted system commit #396
Description
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 /Fas SYSTEM failed andsc stopreturned 1061 — only a reboot released the memory.
Repro sketch
- pymanager installed, its
python.exealias first on PATH. - AppXSvc resident (Automatic start, or started manually and left running).
- Run
python -c "pass"through the alias every 30-60 s with any scheduler. - 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.
Activity
zooba commentedon Aug 18, 2026
No argument - it is 100% an OS issue, not ours. We're using the provided interfaces correctly, so this will need to be reported to Microsoft.
Best thing you can do is when it's reproducing, use Feedback Hub to send a problem report. That will collect the logs that the team expect and create a bug for them. Best to do this when the memory usage is high so that it can
You'd need to search more broadly for an OS bug, since it is almost certainly not unique to Python.1 But you can't search Microsoft's internal database, so no big deal. You've analysed it more than most though, so wouldn't surprise me if there's nothing else out there.
I'm interested how you would suggest avoiding it, without fundamentally rewriting our entire app. If you meant by rewriting the entire app, then that's clearly out, and the best hope would be to report it to the OS. But if you've got some other idea it'd be nice to hear about it.
Footnotes
There's a very small chance that Python is the only user of some OS feature, but I know there are plenty of other users of all the MSIX features we are using. ↩
Thenewmanator15 commentedon Oct 24, 2026
Another data point, with one detail that may explain why the 24-hour limit doesn't hold.
Environment: Windows 11 Pro Insider, build 26300.9807. Python Install Manager 26.4.240.0, installed from python.org.
py/pythonresolve to%LOCALAPPDATA%\Microsoft\WindowsApps\py.exe.Size: AppXSvc's svchost reached 42.4 GB of commit after 5.6 days of uptime. Resource-Exhaustion-Detector (event 2004) named it first five times, and the system ran out of commit. 5,206 of the 5,349 deployment starts kept in
AppXDeploymentServer/OperationalwereUpdateUsingAppInstallerOperationforPythonSoftwareFoundation.PythonManager, all requested by Appinfo.Measured cost: 30 launches of
py -c "pass"moved AppXSvc from 784 MB to 858 MB. In a second, recorded run, 50 launches (plus other activity: 150 update checks logged in that minute) moved it from 1,424 MB to 1,679 MB. That is about 1.5 to 1.7 MB per check, never released.What may defeat the 24-hour limit: the published
pymanager.appinstallerasks for<OnLaunch HoursBetweenUpdateChecks="24"/>, and Windows reportsHoursBetweenUpdateChecks : 24. ButGet-AppxPackageAutoUpdateSettingsstill showsalthough 26.4.240.0 is installed and thousands of checks have run since. If that record never moves, every launch is more than 24 hours after the "last check", so every launch checks. My guess, which I have not confirmed, is that the record went stale when an update arrived by some route other than the .appinstaller. That would be worth knowing for anyone reproducing this.
As you said, the leak itself is an OS bug. I've filed it through Feedback Hub (Apps > App Installer) with a recording, the 2004 events and the settings output above.
Workaround for others who land here: call the interpreter by its full path, or turn off the
py/python/python3app execution aliases. Then no update check runs per launch. A Claude Code plugin hook that runspy -3three times per tool call was the main driver here, as in anthropics/claude-code#98929.