Windows Telemetry Spikes: Stop DiagTrack and CompatTelRunner RAM Bursts

I stopped a baffling, short-lived RAM surge on my Windows 11 PC by taking aim at a little-known telemetry service Microsoft runs under the name Connected User Experiences and Telemetry — the system component many users never notice until it misbehaves. The service (service name: DiagTrack) is the Windows backbone for event-driven diagnostic collection and compatibility scanning; when it kicks in it can briefly allocate large amounts of memory, run inside shared Service Host processes, and produce spikes that look like phantom memory usage in Task Manager.

Background / Overview​

Windows ships with a layered telemetry architecture: a settings surface in Settings → Privacy & security → Diagnostics & feedback, Group Policy/MDM controls for enterprise deployments, and background components that collect, process, and transmit diagnostic artifacts. The Connected User Experiences and Telemetry service is the local manager for event‑driven collection and the telemetry pipeline — it queues events, assembles diagnostic artifacts, and hands off workloads to companion components when deeper analysis is needed. This is by design: telemetry is event‑driven, not a constant low‑level drain. But that very design is what creates the bursty memory and CPU behaviour many users see.
Microsoft documents the service as providing the “event‑driven collection and transmission of diagnostic and usage information” when diagnostic options are enabled. That wording matters: the service won’t necessarily be active 100% of the time, but it will wake up when Windows decides something needs checking — updates, driver changes, application installs, or scheduled maintenance windows. Those wakeups can look like sudden, unexplained resource spikes.

---

Why you see sudden RAM spikes: the technical anatomy​

Event-driven telemetry = bursty resource use​

Telemetry tasks are frequently triggered by events — a Windows update completing, a driver install, an app registration, or a scheduled compatibility scan. When an event happens, the telemetry service allocates memory to inspect files, build diagnostic bundles, or run compatibility assessments, then releases it after the job completes. On modern machines this often happens so quickly you don’t notice, but on systems with particular workloads or on machines with unusual configuration it becomes visible as a brief lag and then a return to normal. Microsoft explicitly describes the service as managing this event‑driven collection.

Grouped service host processes complicate tracing​

Until recent Windows releases, many services run inside shared Service Host (svchost.exe) processes; after the Windows 10 Creators Update Microsoft began refactoring service hosting so that many services run in separate Service Host instances on machines with ≥3.5 GB RAM. That improves isolation and diagnostics, but it also means resource usage can still be grouped or split in ways that make attribution tricky in Task Manager. In short: a memory spike reported against a Service Host process may hide which specific service triggered the spike.

The compatibility scanner — CompatTelRunner.exe — does the heavy lifting​

A frequent offender for pronounced spikes is CompatTelRunner.exe, the executable for the Microsoft Compatibility Appraiser scheduled task. That task scans installed applications, drivers, and system state to determine whether a device is compatible with future feature updates and to create compatibility telemetry artifacts. The scanner reads many files, checks version and compatibility rules, and writes binary appraiser outputs — work that can consume notable CPU, disk and memory while it runs. CompatTelRunner typically runs as a scheduled background job (Microsoft Compatibility Appraiser under Task Scheduler), which is why the spikes often appear to come from nowhere.

---

How this shows up for the end user​

• Short, unexplained RAM/CPU spikes that disappear quickly.
• Task Manager showing higher memory use for a Service Host instance without a clear named process.
• Temporary stutters or lag during otherwise idle times (or right after update/driver events).
• Reboots or manually killing tasks won’t permanently stop it because the service and associated scheduled tasks will re‑trigger automatically.

These behaviours are often misdiagnosed as browser/extension problems or as driver issues — because the telemetry work is invisible until it runs. If you haven’t checked Services, Task Scheduler, or event logs, the spike will look like a random Windows hiccup.

---

What happens if you disable the service?​

Short answer: disabling Connected User Experiences and Telemetry (DiagTrack) stops a large portion of Windows’ event‑driven diagnostic collection on that device, and with it many of the compatibility scans that produce the visible spikes. It does not disable required system functionality such as the Windows Update engine, device activation, or core security services — those are separate components. Practically, people who disable DiagTrack report more predictable memory usage and fewer surprise spikes.
Important context and caveats:

• Disabling the service reduces the diagnostic data that Microsoft can use for troubleshooting and product improvement. That makes remote Microsoft‑assisted troubleshooting harder, and in some enterprise scenarios it will cause devices to stop reporting to management/telemetry platforms that expect that data. Microsoft’s documentation and enterprise policy controls reflect this trade‑off.
• Windows may re‑enable telemetry components during major feature upgrades or when administrative policies (Group Policy, MDM) enforce specific diagnostic levels. In enterprise environments, central policy typically controls telemetry, so local changes may be overwritten.
• Some preview/insider flows and Microsoft feedback features will be hampered when optional diagnostic data is blocked; if you rely on preview builds or actively submit diagnostic traces for Microsoft, disabling is not recommended.

---

How to identify the telemetry spike on your system — practical troubleshooting​

• Open Task Manager (Ctrl+Shift+Esc) and expand Service Host entries to see what services are grouped under a high‑memory svchost instance. If you see “Service Host: Connected User Experiences and Telemetry,” take note.
• Check Task Scheduler: open Task Scheduler → Task Scheduler Library → Microsoft → Windows → Application Experience. Look for the task named Microsoft Compatibility Appraiser and note its Last Run Time and next trigger. CompatTelRunner is launched by this task.
• Inspect the Event Viewer (Windows Logs → System / Applications) for any entries coinciding with the spike timestamp; diagnostic tasks often log start/stop events or errors that reveal a correlation.
• Use Resource Monitor or Process Explorer for deeper attribution: both show per‑process memory, threads and open files. If CompatTelRunner or the DiagTrack service is performing disk reads of many files, Process Explorer will reveal it.

These steps narrow down whether telemetry or the compatibility appraiser is the cause before you take action.

---

How to stop the spikes: options, ranked from least invasive to most invasive​

Below are safe, practical options for users who want to reduce the telemetry‑driven spikes while preserving Windows diagnostics where possible.

1. Settings (recommended first step for most users)​

• Settings → Privacy & security → Diagnostics & feedback: turn Send optional diagnostic data off and disable Tailored experiences.
• This reduces optional telemetry and prevents many of the bigger telemetry workloads from being collected and transmitted while leaving required diagnostic data intact. This is the least risky approach and can be reverted instantly.

2. Disable the CompatTelRunner scheduled task (surgical, reversible)​

• Open Task Scheduler → Microsoft → Windows → Application Experience → Right‑click Microsoft Compatibility Appraiser → Disable.
• This prevents the heavy compatibility scan from running automatically while leaving DiagTrack active for other diagnostic needs. Many power users prefer this because it addresses the most pronounced cause of spikes with minimal side effects.

3. Disable the DiagTrack service (stronger, less reversible locally)​

• Use Services (services.msc): find Connected User Experiences and Telemetry (service name: DiagTrack) → Stop → set Startup type to Disabled.
• Or run elevated Command Prompt / PowerShell:
• sc config DiagTrack start= disabled
• sc stop DiagTrack
• This prevents most event‑driven diagnostic collection on the machine. It’s effective, but more intrusive than the prior two options and will reduce the telemetry pipeline that Microsoft and some support tools rely on.

4. Group Policy / Registry (enterprise-grade control)​

• For Windows Pro, Enterprise, and Education, use the Group Policy Editor: Computer Configuration → Administrative Templates → Windows Components → Data Collection and Preview Builds → Allow Diagnostic Data → set to Disabled (or set allowed value to “Required data” depending on policies). For a managed fleet, use MDM policies instead. This enforces diagnostic behavior centrally and is the correct approach for organizations.

5. File‑level blocking (last resort)​

• Some guides suggest renaming or removing CompatTelRunner.exe or altering file permissions to prevent execution. This is brittle and can break update workflows; it is not recommended unless you know the system implications and can recover from problems. If you go this route, be prepared to restore the file from a known good source.

---

Step‑by‑step: disable the Microsoft Compatibility Appraiser safely (recommended midline approach)​

• Press Windows+R, type taskschd.msc, and press Enter to open Task Scheduler.
• Navigate to Task Scheduler Library → Microsoft → Windows → Application Experience.
• Right‑click Microsoft Compatibility Appraiser and choose Disable.
• Optionally, disable ProgramDataUpdater in the same folder if present (it occasionally triggers compatibility tasks).
• Reboot and monitor Task Manager for the previously observed spikes.

Disabling the scheduled task stops the heavy compatibility scan without completely removing diagnostic capabilities. It’s reversible (right‑click → Enable) and safe for most users.

---

The trade‑offs: what you lose, and what you keep​

When you disable CompatTelRunner or DiagTrack you gain predictability and fewer surprise spikes, but you also reduce the volume of diagnostic telemetry Microsoft receives from that device. That has implications:

• Reduced ability for Microsoft to detect and analyse compatibility or crash patterns for your specific hardware and software mix. This can slow root‑cause analysis for problems that Microsoft support might otherwise diagnose.
• Some “tailored experiences” and feature‑improvement features depend on optional telemetry. Turning it off removes those personalization signals.
• Enterprise management and update compliance tools may rely on diagnostic data and Update Compliance / Desktop Analytics features. If you disable telemetry in managed devices, you may remove those reporting signals and break certain compliance or servicing workflows. For managed fleets, use policy to set an organizational stance rather than disabling locally.

If your priority is a single‑user desktop where privacy and consistent performance matter more than feeding optional telemetry, disabling the scheduled compatibility appraiser or DiagTrack is a reasonable choice. If your priority is receiving full Microsoft support, participating in preview builds, or being visible to IT management, prefer Settings or Group Policy approaches that retain required diagnostic channels while limiting optional data.

---

Addressing exaggerated or unverified claims​

Over the years you’ll see sensational headlines claiming telemetry can “eat 10–20 GB of RAM” or suggesting it’s part of a secretive spying mechanism. Those anecdotes exist — community posts and smaller publications report dramatic memory growth tied to diagnostic queues or corrupted diagnostic files — but they are usually case‑by‑case, often linked to corrupted .etl files, network stalls that prevent uploads, or specific system configurations. Treat large numbers like “20 GB” as anecdotal unless you can reproduce them on your hardware and confirm via tools such as Process Explorer or RAMMap. In other words: there are real telemetry‑related memory problems; extraordinarily large numbers should be treated as unverified unless backed by forensic traces.

---

Best practices and safer alternatives​

• Start with Settings: turn off optional diagnostic data first. This is reversible and recommended for most users.
• If spikes persist, disable the Microsoft Compatibility Appraiser scheduled task before disabling DiagTrack entirely. This addresses the most common cause of heavy scanning while keeping other diagnostics functional.
• For enterprise or multiple machines, codify your stance via Group Policy or MDM so settings remain consistent and auditable.
• Use Process Explorer, Resource Monitor, or PerfView to capture what triggers spikes. Capture timestamps and correlate with Task Scheduler/ Event Viewer entries before changing the system state — this helps you revert if a change causes unexpected side effects.
• Keep a recovery plan: know how to re‑enable services or restore files if an update or support session requires telemetry to be available.

---

My verdict: when to disable, when not to​

• Disable the Compatibility Appraiser scheduled task if you see recurrent, noticeable spikes or disk thrash that aligns with the Microsoft Compatibility Appraiser run times. It’s effective, reversible, and low risk for single‑user systems.
• Reserve disabling DiagTrack for when you’ve validated the behaviour and accept the diagnostic trade‑offs — e.g., a privacy‑focused personal workstation where you don’t use preview builds and prefer consistent performance. Make sure you can revert the change if needed.
• In managed environments, don’t disable telemetry locally; use the supported centralized controls (Group Policy/MDM) to set the diagnostic level for the organization.

---

Closing thoughts​

Windows’ telemetry pipeline is doing two things at once: collecting signals that help Microsoft improve compatibility and reliability, and occasionally performing heavy compatibility scans that can leak into the user experience as short, frustrating spikes. The best approach combines measurement, minimally invasive fixes, and an informed trade‑off between privacy/performance and diagnostics/supportability. For most home users, disabling the Microsoft Compatibility Appraiser scheduled task solves the problem without collateral damage; for power users and privacy‑conscious people, disabling DiagTrack is a valid option provided you accept the consequences.
If you decide to act, document your steps, take a System Restore point (or a full backup) first, and monitor the machine for a few days to ensure no unintended side effects surface. When in doubt, prefer the Settings surface or Group Policy controls — they offer the best blend of safety and reversibility.

---

---

Source: MakeUseOf I finally fixed my RAM spikes by disabling this useless Windows 11 service