Windows’ own update-sharing engine has quietly become the villain in a growing number of user reports:
Delivery Optimization (DoSvc) — the peer‑to‑peer service that helps deliver Windows updates and Microsoft Store apps — can incrementally consume large amounts of RAM on some systems, producing sluggishness and long‑running memory growth that only clears after manual intervention or a reboot. This behavior is currently documented mainly through community diagnostics and patch notes that changed related service behavior, and the fastest, lowest‑risk remedy for individual users is to disable peer downloads in Delivery Optimization until a confirmed platform fix is published.
Background / Overview
Delivery Optimization is a built‑in Windows component whose stated purpose is straightforward:
reduce bandwidth and speed up update and app delivery by allowing a device to fetch pieces of update packages from peers on the local network or the internet as well as from Microsoft servers. On paper it’s a sensible optimization for environments with many Windows devices — it reduces repeated downloads, conserves external bandwidth, and can speed delivery during heavy update waves.
Two separate but related components are central to the recent reports:
- DoSvc (Delivery Optimization service) — handles the P2P download logic, caching of chunks, and upload/download accounting.
- AppXSVC (AppX Deployment Service) — responsible for deploying and registering Store apps; a service whose startup semantics were changed by a recent cumulative update and which can run alongside DoSvc in system service hosts.
The situation that surfaced in community threads and diagnostic posts is not that Delivery Optimization is always broken, but that a recent servicing change — specifically a cumulative update that altered service startup behavior — made previously dormant services run more often. That increased runtime exposure made incremental memory growth more visible on devices with limited RAM or on certain server/VDI images. The change is documented in the update notes and community troubleshooting threads, while the memory‑growth symptom is prominent in user reports.
What users are seeing — symptoms and patterns
Across forums and thread captures, the observable pattern is consistent:
- A background service or service host (often DoSvc or an svchost instance that includes DoSvc) begins with normal RAM use but slowly climbs in working set and private bytes over hours or days.
- On machines with 4–8 GB of RAM, that steady growth translates to swapping, UI jank, and an overall perception of a “slow” PC despite low visible CPU or network utilization.
- Some individual anecdotes describe very large allocations (gigabytes of growth). These reports are compelling but remain anecdotal until Microsoft provides an official root‑cause finding. Treat the extreme numbers as user‑reported cases rather than confirmed universal behavior.
These symptoms are easiest to spot on lower‑end laptops, VM desktop hosts, or image‑managed servers where every resident process matters. In enterprise contexts, the change in AppXSVC’s startup semantics has also produced monitoring noise and start/stop “flapping” for some administrators.
How to determine whether Delivery Optimization is the culprit
Quick, reliable triage requires a couple of standard tools and a short checklist:
- Open Task Manager (Ctrl+Shift+Esc), switch to the Details tab and sort by Memory. Match the PID for the svchost host to services to identify DoSvc or AppXSVC.
- Use Process Explorer to see private bytes, working set, thread counts, and handle counts for the service process; look for monotonic increases over time.
- Run RAMMap or Performance Monitor for deeper memory breakdowns (standby list, kernel pools) if you suspect kernel allocations.
- Check Delivery Optimization’s own UI: Settings → Windows Update → Delivery Optimization → Activity monitor to see recent upload/download totals and cache activity.
If you observe steady, unexplained growth in a DoSvc‑hosted process over multiple snapshots (hours), that’s a strong operational signal to apply mitigations and collect traces. Collect time‑stamped Task Manager snapshots or PerfMon counters to make the case if you escalate to support.
Immediate, low‑risk fixes for home users
For most individual users the fastest, reversible fix is also the simplest:
- Open Settings (Windows key + I).
- Navigate to Windows Update → Advanced options → Delivery Optimization.
- Toggle Allow downloads from other computers to Off.
That change turns off peer‑to‑peer transfers and stops the service from doing cross‑device downloads that are most likely to create big cache builds and extra background work. After toggling the option, reboot and watch Task Manager; many users report the memory growth halts and free RAM returns to normal levels.
If you prefer to retain LAN‑only P2P while preventing internet peers from being used, set Delivery Optimization to
Devices on my local network only and apply bandwidth caps in the advanced settings. This is a middle ground for users who want some of the speed benefits without remote peer exposure.
Advanced mitigations for power users and administrators
If toggling peer downloads doesn’t fully resolve the issue, or if you manage multiple machines, the following steps can be useful — but they carry more operational weight and should be applied with care.
- Stop Delivery Optimization temporarily:
- Services.msc → Delivery Optimization → Stop; set Startup type to Manual or Disabled for troubleshooting.
- Or: net stop DoSvc (temporary), sc config DoSvc start= disabled (persistent via sc).
- Clear the Delivery Optimization cache to reclaim disk space and reduce immediate activity:
- Settings → System → Storage → Temporary files → check Delivery Optimization Files and remove.
- For full manual clearing (advanced): stop DoSvc, delete contents of C:\ProgramData\Microsoft\Windows\DeliveryOptimization\Cache, then restart DoSvc. Always stop the service first to avoid “file in use” problems.
- Revert AppXSVC to demand start on sensitive hosts (servers, VDI, image‑managed machines):
- sc config AppXSVC start= demand
- sc stop AppXSVC
- Reboot and monitor for reduced resident memory and fewer flapping events. This is reversible but should be pilot‑tested in enterprise rings because AppXSVC’s behavior affects Store and app deployment readiness.
- For fleets, prefer managed policy changes (Group Policy or Intune) to ensure consistency rather than ad‑hoc registry edits. If you must use registry keys, document the change and provide a rollback script.
These measures are effective but trade functionality (peer sharing, immediate Store app registration) for stability; weigh that against your operational priorities.
Diagnostics to gather before escalating to Microsoft
If the issue persists or you need engineering help, collect structured artifacts to increase the odds of meaningful action:
- Time‑stamped process metrics: working set, private bytes, handle and thread counts for DoSvc/AppXSVC (Task Manager or Process Explorer).
- ETW traces or ProcMon captures during the growth period.
- RAMMap snapshots that show kernel pool, standby, and active lists.
- Delivery Optimization Activity Monitor snapshot showing cache size and transfer totals.
- A brief reproduction plan: steps you took, how long the growth took to appear, whether you toggled Delivery Optimization off and what that changed.
Attach these artifacts to a Microsoft support case or Feedback Hub submission. Community threads indicate Microsoft engineers are likelier to act when structured traces accompany reports.
Trade‑offs and risks of turning off Delivery Optimization
Disabling peer downloads or stopping DoSvc is safe and reversible for most home users, but it comes with measurable trade‑offs:
- Increased bandwidth from Microsoft servers — each device will fetch entire updates directly, which is usually fine for a single PC but can stress constrained office Internet links.
- Slightly slower distribution in large fleets — organizations that rely on LAN caching to reduce bandwidth use will see higher upstream traffic.
- App readiness and deployment changes — on servers or kiosks where immediate AppX readiness is expected, reverting AppXSVC to Manual may delay Store app registration workflows.
Administrators should test mitigations in pilot rings and prefer throttling or LAN‑only peer mode before broad disabling. For home users, the convenience cost is typically minimal and fully reversible.
Why this happened — parsing the technical context
The immediate community signal combined two facts:
- A cumulative update changed AppXSVC’s startup type to Automatic, increasing the runtime exposure of a service that historically ran only when needed. That change is documented in the update notes and is an intentional reliability tweak.
- When previously trigger‑started components run more often, any incremental memory allocation that would previously have been short‑lived becomes visible as a long‑running footprint, especially on low‑RAM devices. The combination of DoSvc activity and AppXSVC being resident created a context where memory growth shows up as a user‑facing problem.
This is an important distinction: the symptom (DoSvc memory growth) is
real to users, but it may be a behavioral regression or an interaction exposed by the update rather than an obvious single‑line code bug. Microsoft has acknowledged the startup‑type change in the KB, but at the time of reporting the company had not posted a separate advisory explicitly labelling a Delivery Optimization memory leak as the root cause. That leaves community diagnostics and mitigations as the pragmatic stopgap. Treat large anecdotal memory figures as meaningful signals that need engineering confirmation.
Practical, prioritized recommendations
For home users:
- Toggle off Allow downloads from other computers (Settings → Windows Update → Delivery Optimization). Reboot and monitor Task Manager.
- If disk space is also an issue, use Settings → System → Storage → Temporary files to remove Delivery Optimization Files.
- If you want to be conservative: set Delivery Optimization to Devices on my local network only and cap bandwidth in advanced settings.
For power users and technicians:
- Use Process Explorer and RAMMap to confirm growth and capture counters.
- If necessary, stop DoSvc temporarily and clear the cache manually (stop service → delete cache → restart service).
- For servers/VDI, pilot sc config AppXSVC start= demand and measure effects on memory and monitoring alerts before wider rollout.
For IT organizations:
- Pilot any change in an isolated group, use Intune/Group Policy to apply consistent Delivery Optimization settings where appropriate, and be ready to use Known Issue Rollback (KIR) or out‑of‑band fixes if Microsoft issues them for broad fleets. Collect and attach structured diagnostics to Microsoft support cases when escalations are required.
Strengths, risks and the larger picture
Delivery Optimization is a valuable feature when it behaves: it reduces redundant downloads, eases bandwidth pressure in large deployments, and can speed updates in high‑density environments. Its strengths are clear in well‑provisioned networks and modern desktops.
The risks exposed by this episode are also instructive:
- Windows is a highly interconnected system where small servicing changes (like making a service Automatic) can magnify secondary effects on resource use at scale.
- Community and forum diagnostics are invaluable in surfacing operational impacts quickly, but they do not substitute for code‑level root cause analysis; extreme numbers reported by individuals should be validated via engineering traces.
- Enterprise management requires a cautious balancing act between staying patched and maintaining predictable operational baselines; administrators should pilot updates and monitor telemetry closely.
The pragmatic trade: disable or throttle Delivery Optimization now if your device shows memory pressure, and monitor for a formal fix that restores intended behavior without manual mitigation.
Conclusion
Delivery Optimization’s P2P model remains a sensible idea for reducing bandwidth and speeding distribution, but recent servicing changes have made its runtime footprint more visible on some Windows installations. The problem — steady DoSvc memory growth and related system sluggishness — is documented by community diagnostics and tied to a known update that changed service startup semantics, though Microsoft had not, at the time of community reporting, published a single definitive root‑cause advisory for a memory leak. The simplest remedy for most users is to
turn off Allow downloads from other computers in Delivery Optimization and clear the Delivery Optimization cache; administrators should pilot targeted mitigations, collect traces if problems persist, and use managed policies at scale rather than manual registry edits. These steps are reversible, effective, and the right short‑term defense while awaiting a confirmed platform fix.
- Quick checklist (one page):
- Check Task Manager for DoSvc/AppXSVC growth.
- Toggle off peer downloads (Settings → Windows Update → Delivery Optimization).
- Clear Delivery Optimization Files via Storage → Temporary files.
- If still affected, stop DoSvc, clear cache manually, and consider sc config AppXSVC start= demand for sensitive hosts.
Follow these steps in order, monitor results, and escalate with structured diagnostics only if the behavior reproduces after the basic mitigations.
Source: PCWorld
This Windows feature secretly eats up RAM and slows your PC over time