Windows’ Delivery Optimization — the peer‑assisted engine that was designed to reduce bandwidth and speed updates — has been linked to steady, sometimes dramatic RAM growth on a subset of Windows 11 and Windows 10 machines, and the fastest, reversible way to restore responsiveness for many users is to disable peer downloads or stop the Delivery Optimization service while a platform fix is finalized.
Background / Overview
Delivery Optimization (service name
DoSvc) is a built‑in Windows component that breaks Windows Update and Microsoft Store payloads into small parts and lets devices obtain those parts from Microsoft servers
and other PCs on the local network (or, if enabled, from PCs on the internet). It’s a peer‑assisted distribution model: when it behaves, it reduces upstream bandwidth and speeds rollout in dense environments. Microsoft documents the feature and the user controls that let you disable peer downloads, view activity, and set bandwidth or monthly upload limits. In December 2025 a cumulative update (KB5072033) changed the startup semantics of a related service,
AppX Deployment Service (AppXSVC), moving it from trigger/manual start to
Automatic in some SKUs. The KB explicitly lists this configuration change in its change log (OS builds 26100.7462 and 26200.7462). That single, documented change increased the runtime exposure of components that historically ran only when needed, and it created conditions that made Delivery Optimization’s resident footprint much more visible on many low‑RAM and image‑managed systems.
What the problem looks like in the real world
- Symptom: a svchost.exe process (hosting DoSvc or related services) shows monotonic memory growth over hours or days, eventually consuming hundreds of megabytes to multiple gigabytes of RAM; system responsiveness degrades (swapping, UI lag, RDP freezes), especially on machines with 4–12 GB of RAM. Many community traces show DoSvc’s working set and private bytes climbing without obvious release points.
- Scope: the behavior has been reported most often on Windows 11 devices that received the December 2025 servicing, on constrained consumer laptops, on VM/VDI images, and on some Windows Server 2025 configurations where monitoring systems detected start/stop flapping after the AppXSVC startup change. The worst user‑facing impact is concentrated on lower‑RAM systems; machines with 16 GB or more often tolerate the extra footprint without immediate usability loss.
- Anecdotes vs. verified numbers: individual users have posted extreme traces (one widely shared user plot claimed DoSvc svchost hitting ~20 GB of memory). Those numbers are alarming and worthy of investigation, but they remain user‑reported artifacts until validated by vendor engineering traces (ETW, ProcDump, RAMMap). Treat the extreme figures as credible signals that need structured evidence, not as universal outcomes.
How this surfaced and why it matters now
Community diagnostics — most prominently a public investigation by a Reddit user who tracked DoSvc over time — triggered widespread attention. Public posts and tech outlets reproduced the observations, correlated timing with the KB5072033 change that moved AppXSVC to Automatic, and offered practical mitigations. Those community signals are strong operational evidence and they were quickly amplified by independent outlets. Microsoft’s official KB confirms the AppXSVC startup change but (at the time community reporting spiked) did not label Delivery Optimization itself as a confirmed memory‑leak bug; Microsoft historically resolves regressions via subsequent cumulative updates, Known Issue Rollbacks (KIRs), or out‑of‑band fixes as needed. Why this matters: Windows runs many background services to deliver reliability and features. When a service that used to run
on demand is made
always on, small allocations and caches that were previously transient become long‑lived. On low‑memory devices this can change the user experience from “smooth” to “sluggish” within hours. For administrators, the risk is higher because images, VDI hosts and server SKUs are sensitive to any resident overhead or monitoring flapping.
What Microsoft changed (verified technical detail)
- The December 9, 2025 cumulative update KB5072033 advanced Windows to OS builds 26100.7462 (24H2) and 26200.7462 (25H2) and includes a documented line: “The AppX Deployment Service (Appxsvc) has moved to Automatic startup type to improve reliability in some isolated scenarios.” This is the concrete configuration change that correlates with the timing of the memory‑growth reports.
- Microsoft also published Known Issue Rollback guidance and a KIR‑style Group Policy option to temporarily mitigate the change for managed environments while a fix or clarification is prepared. Administrators can monitor Microsoft’s Windows release health dashboard and Microsoft Q&A for an official patch or guidance.
Step‑by‑step mitigations (practical, safe, reversible)
The following are prioritized by safety and reversibility. Apply the least intrusive first; escalate to more aggressive steps only if the symptom persists or you administer a fleet and need rapid remediation.
For home users — fastest and safest (UI method)
- Open Settings (Win + I).
- Go to Windows Update → Advanced options → Delivery Optimization.
- Turn off Allow downloads from other PCs, or choose Devices on my local network to keep LAN peering only.
- Reboot and monitor Task Manager (Details tab) for the svchost instance hosting DoSvc. Many home users see memory growth stop after this change.
Benefits: immediate, reversible, and does not prevent your PC from receiving updates — it only disables peer‑to‑peer sharing so updates come directly from Microsoft servers. Trade‑off: more upstream bandwidth per device and slightly slower distribution in dense networks.
For power users and technicians — command line & cache cleanup
- Stop Delivery Optimization temporarily:
- Elevated Command Prompt: net stop DoSvc
- Or Services.msc → Delivery Optimization → Stop.
- Clear the Delivery Optimization cache:
- UI: Settings → System → Storage → Temporary files → check Delivery Optimization Files → Remove files.
- Or Disk Cleanup (cleanmgr) as Administrator → Clean up system files → check Delivery Optimization Files → Delete.
- Advanced (PowerShell): Delete‑DeliveryOptimizationCache -Force -IncludePinnedFiles (requires administrative PowerShell and Delivery Optimization module).
Notes: Always stop DoSvc before deleting files in C:\ProgramData\Microsoft\Windows\DeliveryOptimization\Cache to avoid “file in use” errors. Clearing the cache reclaims disk space and reduces immediate background work, but the cache can rebuild if DoSvc runs again.
For administrators and server/VDI images — controlled rollouts
- Pilot first on a small representative group.
- Revert AppXSVC startup type to Manual/Trigger (reversible):
- Elevated Command Prompt: sc config AppXSVC start= demand
- Or PowerShell (elevated): Set‑Service -Name AppXSVC -StartupType Manual
- Optionally stop running instance: sc stop AppXSVC
- If necessary and after careful testing, enforce Delivery Optimization mode via Group Policy or Intune (prefer LAN‑only or throttled modes instead of complete disablement across a fleet).
Caveat: Do not set AppXSVC to Disabled unless you accept delayed Store app registration and potential servicing implications. Reverting the startup type is intended as a temporary, reversible measure while awaiting a fix.
Diagnostics to collect before you escalate
If the memory growth persists after basic mitigations, collect structured artifacts — these materially increase the odds Microsoft engineers will root‑cause and patch the issue:
- Task Manager / Details snapshots with PID → service mapping for the svchost instance.
- Process Explorer captures of Private Bytes, Working Set, handle and thread counts for the DoSvc host.
- RAMMap snapshots and Performance Monitor counters to separate user‑space allocations from kernel pool usage.
- ETW traces recorded with Windows Performance Recorder (WPR) covering the growth window.
- ProcMon captures if specific file or registry activity correlates with growth.
- A concise reproduction plan: steps, time between reboots and onset of growth, whether the machine is idle or actively downloading.
Attach these artifacts to a Microsoft support case or Feedback Hub submission; community guidance and Microsoft support both emphasize that structured traces accelerate engineering response.
Technical analysis — what is likely happening (evidence‑based)
- Verified fact: KB5072033 changed AppXSVC from trigger to Automatic in the December 2025 cumulative update. That is documented in Microsoft’s KB and is the verifiable change that correlates with the timing of the symptom.
- Community evidence: multiple independent traces from users and forums show monotonic growth in the DoSvc host’s memory footprint, and stopping or disabling Delivery Optimization halts or reduces the growth in many cases. Those reproductions are credible operational signals.
- Root cause status: the definitive classification — true native memory leak inside DoSvc, an untrimmed in‑memory cache made visible by AppXSVC’s Always‑On timing, or an interaction across services — requires Microsoft engineering traces and code‑level analysis. The community diagnosis is plausible and actionable, but it is not a vendor confirmation of a single line fault. Treat extreme user‑reported numbers as unverified outliers until confirmed by ETW/procDump traces.
Strengths and risks of Delivery Optimization (contextual evaluation)
- Strengths:
- Bandwidth savings at scale — for campuses, enterprises and households with many Windows devices, LAN‑based peer caching reduces repeated downloads and upstream costs.
- Faster distribution — in dense environments it can lower latency for large app or update deliveries.
- Risks and trade‑offs:
- Resource footprint — peer caching consumes disk for cache and resident memory while services are active; when services run persistently, the overhead is visible on low‑RAM devices.
- Operational visibility — small servicing changes (like service start semantics) can ripple into significant operational effects, especially on servers, VDI images and constrained consumer hardware.
- Enterprise bandwidth — bluntly disabling Delivery Optimization across a fleet increases direct upstream traffic to Microsoft servers; prefer policy‑driven throttling or LAN‑only modes where bandwidth matters.
Practical recommendations — concise checklist
- If your PC is slow and DoSvc is top memory user: toggle Allow downloads from other PCs to Off in Settings and reboot. Monitor Task Manager.
- If freeing disk space is also needed: use Storage → Temporary files or Disk Cleanup and remove Delivery Optimization Files.
- If you manage servers/VDI: pilot
sc config AppXSVC start= demand in a small group and monitor for functional impact before wider reversion. Do not disable AppXSVC entirely.
- Collect traces (Process Explorer, RAMMap, WPR/ETW) before opening a Microsoft support case. Attach time‑stamped evidence.
- Watch Microsoft’s release health messages and the KB for KIR or a definitive patch; KIR options for enterprise devices have already been described in Microsoft’s KB for the December update.
Final verdict and risk notice
Delivery Optimization remains a useful, well‑intentioned subsystem that saves bandwidth and speeds distribution when it behaves. The recent wave of reports — corroborated by community reproductions and tied in timing to KB5072033’s AppXSVC startup change — is a credible operational incident that exposes a resource stewardship issue on a subset of installations, particularly those with constrained RAM or server/VDI images. The immediate remediation is straightforward for home users (turn off peer downloads) and reversible for enterprises (revert AppXSVC to Manual in pilots, apply Group Policy KIRs), but aggressive or permanent service disablement across fleets carries real bandwidth and app‑readiness trade‑offs. Caveat: any extreme numbers cited in forums (for example, claims of a 20 GB svchost working set) should be treated as
user‑reported anomalies until validated with ETW/ProcDump/RAMMap evidence. They are important flags that justify structured diagnostics and vendor escalation but are not, by themselves, proof of an invariant platform bug.
Conclusion
If your PC has become sluggish with low visible CPU or disk activity, check Task Manager for an svchost instance hosting
DoSvc and follow the safe, reversible steps above: turn off peer downloads, clear the Delivery Optimization cache, and if you manage images or servers, pilot reverting
AppXSVC to Manual. Collect structured traces and escalate to Microsoft if the symptom persists. Community documentation and Microsoft’s KB together provide both the explanation (AppXSVC’s startup‑type change in KB5072033) and the pragmatic mitigations needed to restore performance while awaiting a formal engineering resolution.
Key quick actions (one‑line checklist)
- Settings → Windows Update → Advanced options → Delivery Optimization → Turn off Allow downloads from other PCs.
- Clear Delivery Optimization Files (Storage → Temporary files) or run Delete‑DeliveryOptimizationCache in administrative PowerShell.
- If you’re an admin and need a fleet fix: pilot sc config AppXSVC start= demand and monitor before broad rollout.
Short, reversible, and effective — those three words summarize the pragmatic approach while the platform owners investigate and fix the underlying interaction.
Source: Novyny.LIVE
Why your Windows PC gets slower over time