Microsoft’s December cumulative update, KB5072033, fixed several visible quirks in Windows 11 but also introduced quieter service‑level changes that some users now blame for unexpectedly high RAM use — most notably reports that the
Delivery Optimization service (DoSvc) and a reconfigured
AppX Deployment Service (AppXSVC) are consuming much more memory than expected after the patch. Early accounts come from user reports and community testing rather than an official Microsoft admission of a memory bug, but the pattern is consistent enough that power users, helpdesk teams and IT administrators should pay attention now and take measured, reversible steps to protect system responsiveness and monitoring integrity.
Background / Overview
KB5072033 is the December 9, 2025 cumulative update for Windows 11 (builds 26200.7462 for 25H2 and 26100.7462 for 24H2). The package bundles security hardenings, fixes carried forward from earlier December preview releases, and a number of quality updates such as File Explorer dark‑mode polish and Copilot reliability improvements. Buried in the “System Components” notes is one short but consequential change:
the AppX Deployment Service (AppXSVC) was moved to an Automatic startup type. Microsoft describes this as an intentional reliability tweak intended to help in “some isolated scenarios.” That apparently small configuration flip has real operational consequences: services that were previously trigger‑started — invoked only when needed — now run at boot. On constrained machines or tightly consolidated server hosts, always‑on background services become a measurable overhead. Community posts and vendor write‑ups capture emerging problems that include excessive RAM use from system services, start/stop flapping detected by monitoring tools, and occasional update‑installation anomalies tied to the same cumulative package.
What changed in KB5072033 (short, practical summary)
- The cumulative update advances Windows 11 to OS builds 26200.7462 / 26100.7462 and installs a collection of security and quality fixes.
- Microsoft explicitly documented that AppXSVC (AppX Deployment Service) is now set to start automatically to “improve reliability in some isolated scenarios.” That single line is the origin of many follow‑on observations.
- Users and administrators quickly noticed side effects: extra resident memory, additional background activity from previously dormant services, and monitoring alerts triggered by unexpected start/stop behavior. Community troubleshooting threads recommend temporary reversion to the previous startup model for sensitive environments.
Delivery Optimization (DoSvc) — the symptom set being reported
What is Delivery Optimization?
Delivery Optimization (service name DoSvc) is Microsoft’s peer‑assisted update distribution mechanism. It lets PCs fetch Windows Update and Microsoft Store content from other PCs on the local network or from devices on the internet, reducing repeated downloads from Microsoft servers and improving distribution performance across large networks. The service has historically been configurable (peer sharing on/off, bandwidth limits, etc. and triggerable rather than always resident.
What users are seeing after KB5072033
- Users report that the DoSvc process (often seen as a DoSvc host or grouped under svchost.exe in Task Manager) steadily increases memory consumption over time, sometimes to levels that noticeably impact system responsiveness on machines with limited RAM. These reports surfaced quickly in Windows‑focused news writeups and community boards after the rollout.
- The growth pattern described — memory allocation that climbs continually without an obvious release point — is consistent with a memory leak hypothesis, though community posts stop short of definitive engineering proof. That means the symptom is real to users, but an official root‑cause analysis is not yet public.
- Separately, the AppXSVC “automatic” change can amplify the problem: if background services that previously only ran on demand are left running for long periods, any incremental memory consumption becomes far more visible. This is especially true on laptops, low‑end desktops, and virtualized desktop hosts.
Evidence: what independent sources show (and what they do not)
- Microsoft’s official KB entry for KB5072033 lists the AppXSVC startup‑type change in the release notes; this is the authoritative confirmation that the service configuration was intentionally changed. The KB also describes the security fixes and quality improvements wrapped into the cumulative update.
- Multiple independent outlets and community threads noted the AppXSVC change and reported that the outcome was increased background activity and monitoring noise on servers and constrained devices; BetaNews and community discussion threads capture both the documented change and early feedback from admins.
- Emerging coverage that points to DoSvc memory growth originates in user reports (WindowsReport summarized early Reddit/Neowin titles). Those articles are valuable indicators of real user pain, but they are not engineering confirmations. At the time of writing, Microsoft has not published a DoSvc‑specific bug acknowledgement tied to KB5072033. Treat community reports as timely signals, not final root‑cause proof.
Technical analysis — why these changes produce noticeable effects
Why trigger‑start vs Automatic matters
Trigger‑start services are dormant until an explicit system trigger or client action requires them. This preserves memory and CPU for foreground workloads. When a service is switched to Automatic, the service binary and thread pools are instantiated at boot. Even when the service is idle it still has code mapped in memory, registered timers, worker threads, and potentially cached state. On modern desktop PCs that’s trivial; on 4–8 GB machines or shared VDI hosts it becomes a visible cost.
Delivery Optimization’s attack surface for leakage
DoSvc implements a variety of caching, peer discovery and network state machines. Memory growth can stem from:
- Unbounded in‑memory caches that aren’t trimmed correctly under new timing or trigger semantics.
- Threads or worker queues that allocate objects and retain references (preventing garbage collection or freeing).
- Interaction with the new service startup timing that initializes additional subsystems earlier than before, exposing latent bugs in rarely executed code paths.
Any of these can cause steady RAM growth even if CPU or network use appears low. Community trace tools (Process Explorer, RAMMap, ETW traces) are usually required to differentiate retained allocations from normal caching.
Start/stop flapping and monitoring noise
On servers, setting a service to Automatic while its binary still implements trigger semantics can produce a cycle: the service starts, performs minimal work and stops, then SCM restarts it because of its Automatic flag — and repeat. Monitoring systems like Zabbix interpret frequent stop/start as failure events, generating false positives and operational noise. That behavior is already documented for AppXSVC after KB5072033 in public support threads.
Who’s most likely to be affected
- Systems with 4–8 GB of RAM where background resident memory is a material percentage of available physical memory.
- Laptops and lower‑spec desktops used for multitasking and gaming, where stutters and UI jank are especially visible.
- VDI images, Remote Desktop Session Hosts and tightly consolidated server hosts where every resident process impacts density and monitoring.
- Organizations that rely on agented monitoring and automated alerts; start/stop changes can flood ticket queues.
How to determine if you’re affected (practical checks)
- Open Task Manager (Ctrl+Shift+Esc) and sort by Memory. Look for Delivery Optimization (DoSvc) or its host svchost.exe entry growing over time. Use the Details tab to match the PID to DoSvc. If memory climbs steadily across several minutes without foreground activity, that’s evidence to investigate further.
- Use Resource Monitor (resmon.exe) or Process Explorer for deeper inspection: check private bytes, working set, handles and thread count for DoSvc. Tools like RAMMap and ProcMon help pinpoint file/registry activity that correlates with growth. Community guidance specifically recommends these tools for quantifying background service impact.
- For servers, check your monitoring dashboards for new or increased alerts on AppXSVC start/stop cycles, and correlate timing with the KB5072033 install window. Microsoft Q&A threads and forum reports show administrators encountering precisely this symptom on Server 2025.
Immediate mitigations and step‑by‑step workarounds
Note: All mitigations below are reversible. They trade off certain background behaviors (peer downloads, faster Store installs, immediate AppX readiness) for stability and lower resource usage. For managed fleets, test these in a pilot group before roll‑out.
1) Gentle first step — limit Delivery Optimization via Settings (recommended for most home users)
- Open Settings → Windows Update → Advanced options → Delivery Optimization.
- Toggle Allow downloads from other PCs to Off, or set bandwidth limits under Advanced options. This limits DoSvc’s activity without disabling core update capability. Microsoft documents these controls and recommends bandwidth caps if needed.
2) If symptoms persist — disable DoSvc temporarily (for troubleshooting)
- Stop the service from Services.msc: find Delivery Optimization, click Stop and set Startup type to Disabled.
- Or use the Registry to make the change persistent: set the Start value under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DoSvc to 4 (Disabled). Reboot to apply. Trusted guidance covers both approaches and cautions managed devices may prevent changes.
3) Revert AppXSVC to Manual (for servers and VDI where monitoring/consumption matters)
- Use the Service Control utility to revert the AppXSVC start type:
- Open an elevated Command Prompt or PowerShell.
- Run: sc config AppXSVC start= demand
- Reboot or stop the service if necessary.
- Note: community threads and Microsoft Q&A explain that the update changed AppXSVC to Automatic and that reverting to Manual reduces flapping and resident memory on sensitive hosts. Administrators reported success testing this mitigation; do not disable the service entirely unless you accept losing store/app deployment behavior.
4) For managed enterprises — use Known Issue Rollback (KIR) or pilot controls
- If a widespread operational impact is confirmed, Microsoft sometimes distributes KIR MSIs to revert specific behavioral changes on managed devices. Administrators should consult their update management tooling, pilot the KB in representative rings, and be prepared to script reversion using Group Policy or Intune if necessary. Community guidance recommends holding updates in production rings until the behavior is fully assessed.
Step‑by‑step: safe command and registry examples
- Revert AppXSVC to demand (manual trigger start):
- Open elevated Command Prompt.
- sc config AppXSVC start= demand
- Disable Delivery Optimization via registry:
- Run regedit as Administrator.
- Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DoSvc
- Modify the Start REG_DWORD value to 4 (Disabled).
- Reboot.
- Use Services.msc:
- services.msc → Delivery Optimization → Stop → Startup type: Disabled.
These procedures are well documented in community guides and mainstream troubleshooting sites; they are reversible and commonly used when Delivery Optimization causes unwanted network or resource behavior. Always take a system restore point or snapshot before changing service startup behaviors on production images.
Risks, trade‑offs and things to watch out for
- Disabling Delivery Optimization changes update delivery behavior: downloads will come directly from Microsoft servers rather than peers, possibly increasing bandwidth and load on constrained links. That’s usually acceptable for single devices but matters at scale.
- Reverting AppXSVC to Manual reduces background readiness for Store and packaged app deployment. On most desktops this is fine; on kiosk or managed devices expecting immediate app registration it may introduce delays.
- Registry edits and low‑level ACL changes (sometimes suggested in support threads) can break servicing behavior if performed incorrectly. Prefer official commands (sc config) or managed policy changes. Community posts that require temporary ownership of TrustedInstaller ACLs are advanced workarounds and should be applied only by experienced admins.
Recommended action plan (concise)
- If you’re a home user with no noticeable slowdowns: monitor. Keep the patch installed — it addresses security issues — and check for driver updates (graphics and firmware) that often mitigate UI/graphics side effects.
- If you see rising memory use linked to DoSvc: first, toggle Delivery Optimization off in Settings and observe. If that resolves it, consider a permanent bandwidth cap or leaving it off on that device.
- If you manage servers, VDI, or tightly consolidated hosts: pilot a reversion of AppXSVC to Manual in a test cohort and evaluate monitoring noise and memory signatures before rolling out more broadly. Use group policy or scripted sc config changes for consistent remediation.
- Capture diagnostics (Process Explorer, RAMMap, ProcMon traces) and file structured feedback with Microsoft (Feedback Hub or Microsoft Q&A) if you observe persistent, reproducible leaks — attach trace artifacts when possible. Community threads show Microsoft engineers monitor these artifacts when provided.
What Microsoft has (and hasn’t) said — and what to expect next
- Microsoft’s KB for KB5072033 explicitly lists the AppXSVC start type change; that confirms the intentional, patch‑level configuration shift. The KB also documents other fixes and security updates included in the rollup.
- Microsoft has not, at the time of writing, posted a public advisory acknowledging a Delivery Optimization memory leak directly linked to KB5072033. News coverage and community threads are the leading signals for this particular symptom. Until Microsoft provides a formal root‑cause analysis or patch note, treat DoSvc memory claims as credible user reports that require cautious mitigation rather than confirmed engineering facts.
- Historically, Microsoft addresses regressions discovered after cumulative updates either by bundling fixes into the next Patch Tuesday release, issuing an out‑of‑band hotfix, or providing a Known Issue Rollback for enterprise customers. Administrators should watch the Windows release health dashboard and Microsoft Q&A threads for follow‑up.
Final analysis — balancing security, reliability and resource stewardship
KB5072033 demonstrates a common servicing trade‑off: Microsoft folded quality and security fixes into a single cumulative package and also changed a default behavior to improve reliability in edge scenarios. That change — moving AppXSVC to Automatic — is small in the release notes but substantial in operational effect. For most modern consumer systems with ample RAM the change is likely benign or even beneficial; for constrained devices, image‑managed servers and tightly monitored fleets it increases the surface for regressions, resource noise and support overhead. The reports of Delivery Optimization memory growth are a real user problem, but they stem from community observation rather than a Microsoft‑confirmed bug tied to KB5072033 at the time of publication. That distinction matters: fixes for confirmed platform code problems and fixes for misconfigured startup semantics require different remedies. The immediate, pragmatic course for users and administrators is to monitor, apply temporary mitigations (toggle Delivery Optimization, revert AppXSVC to Manual for sensitive hosts), collect diagnostics, and escalate through support channels if the issue materially impacts operations.
Checklist for readers (one‑page takeaways)
- Confirm your Windows build: Win + R → winver. KB5072033 corresponds to builds 26200.7462 / 26100.7462.
- Look for DoSvc memory growth: Task Manager → sort by Memory → identify DoSvc / svchost instances. Use Process Explorer for deep inspection.
- Simple mitigations: Settings → Windows Update → Advanced options → Delivery Optimization → toggle off or limit bandwidth.
- Server/VDI mitigation: test sc config AppXSVC start= demand in a pilot ring before wide deployment. Revert only if monitoring confirms improvement.
- Capture logs: ProcMon, RAMMap, ETW traces and open a Microsoft support case or submit feedback via Feedback Hub with artifacts if you need engineering engagement.
KB5072033 fixes visible issues and hardens parts of the platform — but it also highlights why even tiny configuration changes in a mass‑deployed OS update can ripple into unexpected performance pain. For now the consensus is practical: don’t uninstall security updates blindly;
measure,
mitigate, and
report the problem so engineers have the data they need to ship a targeted correction that preserves both reliability and resource efficiency.
Source: Windows Report
Windows 11 Users Report High Memory Usage After Installing KB5072033