How to Troubleshoot MEM ConfigMgr Memory Issues
Why This Is Happening
I've seen this exact scenario play out on dozens of enterprise endpoints and site servers: you open Task Manager, and CcmExec.exe is sitting at 800 MB of RAM, the SQL Server process tied to your ConfigMgr database is eating 12 GB, and half your helpdesk tickets are complaints that machines are "slow" right after patch Tuesday. You check the ConfigMgr console and everything looks green. That gap , between "console says fine" and "machines are suffering" , is where MEM ConfigMgr memory troubleshooting lives.
Microsoft Endpoint Manager Configuration Manager (MEM ConfigMgr, formerly SCCM) is a distributed system. It has components running on the site server, the SQL Server host, distribution points, management points, and every managed client. Memory pressure can originate from any of those layers. The tricky part is that a memory leak on a management point will show up as sluggish policy delivery on clients, not obviously traceable back to the MP without digging into logs.
The most common culprits I see in the field:
- CcmExec.exe (SMS Agent Host) memory leak, the client-side service that handles policy downloads, software deployments, and hardware inventory. It's notorious for growing unbounded over weeks without a restart.
- WMI repository corruption, ConfigMgr's client relies heavily on Windows Management Instrumentation. A corrupt WMI repository causes CcmExec to keep retrying operations, spinning up memory with each attempt.
- Hardware inventory cycles on large endpoints, if a device has thousands of software titles installed, or you've enabled aggressive custom MIF extensions, hardware inventory can balloon CcmExec to 1+ GB temporarily.
- SQL Server not respecting max server memory limits, the ConfigMgr database SQL instance is frequently misconfigured at default "unlimited" memory, and it will happily take everything the OS offers.
- SMS_Executive service component crashes causing restart loops, Event ID 4999 in the Application log signals an SMS_Executive component has failed and is repeatedly reloading, chewing through memory on each cycle.
- Outdated ConfigMgr client version, clients running a version more than two Current Branch releases behind are full of fixed memory bugs. This is low-hanging fruit.
One thing that drives me crazy about ConfigMgr's error messages: they rarely say "memory." Instead you get vague warnings in CcmExec.log like Failed to get the process handle or policy application errors. You have to correlate logs with Performance Monitor counters to connect the dots. That's exactly what this guide walks you through.
Browse all Microsoft fix guides → if you're dealing with other ConfigMgr or Windows issues alongside this one.
The Quick Fix, Try This First
Before you spend an hour in logs, try the fix that solves about 60% of CcmExec memory bloat cases in under five minutes. You're going to restart the SMS Agent Host service, flush the CcmExec cache, and verify the client version is current.
On the affected client machine:
Open an elevated PowerShell prompt (Start → type "PowerShell" → right-click → Run as administrator) and run this sequence:
# Stop the ConfigMgr client service
Stop-Service -Name CcmExec -Force
# Clear the software distribution cache (adjust path if custom)
Remove-Item -Path "C:\Windows\CCMCache\*" -Recurse -Force -ErrorAction SilentlyContinue
# Clear the CcmStore data (forces policy re-evaluation on next start)
Remove-Item -Path "C:\Windows\CCM\CcmStore.sdf" -Force -ErrorAction SilentlyContinue
# Restart the service
Start-Service -Name CcmExec
# Confirm it's running and note the memory after ~2 minutes
Get-Process CcmExec | Select-Object Name, WorkingSet64, CPUAfter the restart, CcmExec typically drops from 600–900 MB back to 80–150 MB on a healthy system. If it climbs back above 400 MB within 30 minutes, you have an active memory leak, keep reading for the deeper fix.
While you're at it, check the client version:
(Get-WmiObject -Namespace root\ccm -Class SMS_Client).ClientVersionCompare that against the current ConfigMgr Current Branch release at your site. If the client is more than one version behind, force a client upgrade from the ConfigMgr console under Administration → Updates and Servicing → Client Update Settings. Outdated clients are a massive source of memory-related bugs that Microsoft already fixed.
Before you fix anything, get a baseline. Blind fixes waste time. Open Task Manager (Ctrl+Shift+Esc → Details tab) and sort by "Memory (private working set)." On a ConfigMgr client, CcmExec.exe should idle under 200 MB. On a site server, SMS_Executive.exe should be under 500 MB. If SQL Server is on the same box, check sqlservr.exe separately.
For a more precise picture, open Performance Monitor: Start → type "perfmon" → Enter. Add these counters by clicking the green "+" icon:
- Process → Working Set → CcmExec
- Process → Private Bytes → CcmExec
- SMS Agent Host → Active Threads (if available)
- Memory → Available MBytes
- Memory → Pages/sec
Run this for 15–20 minutes during normal working hours. If "Private Bytes" for CcmExec climbs continuously without plateauing, that's a textbook memory leak. If "Pages/sec" spikes above 20 consistently, the system is paging to disk, memory exhaustion is already causing performance degradation.
You can also collect a quick snapshot via PowerShell for remote analysis or logging:
$proc = Get-Process CcmExec -ErrorAction SilentlyContinue
if ($proc) {
[PSCustomObject]@{
Machine = $env:COMPUTERNAME
WorkingSetMB = [math]::Round($proc.WorkingSet64 / 1MB, 1)
PrivateBytesMB= [math]::Round($proc.PrivateMemorySize64 / 1MB, 1)
HandleCount = $proc.HandleCount
ThreadCount = $proc.Threads.Count
Uptime_Hours = [math]::Round((Get-Date - $proc.StartTime).TotalHours, 1)
}
}A healthy CcmExec shows under 200 handles and under 40 threads at idle. If you're seeing 800+ handles or 100+ threads, a component is looping. Note the uptime, a process running for 30+ days without restart is almost always bloated.
WMI repository corruption is the second most common cause of MEM ConfigMgr memory issues I encounter in the field, and the one most people skip because they don't think to check it. ConfigMgr's client stores nearly all of its operational data in WMI namespaces under root\ccm. If those namespaces are corrupt or inconsistent, CcmExec retries queries in tight loops, never completing operations, and memory climbs.
Check for WMI errors first. Open Event Viewer (Start → eventvwr.msc → Windows Logs → Application) and filter for Source = "WinMgmt" or Source = "Microsoft-Windows-WMI-Activity/Operational". Error IDs 10 and 63 are the most common indicators of WMI repository problems tied to ConfigMgr.
Run the WMI consistency check in an elevated PowerShell window:
# Verify WMI repository consistency
winmgmt /verifyrepository
# If it returns "WMI repository is inconsistent", run:
winmgmt /resetrepository
# Then force ConfigMgr namespace re-registration
Stop-Service CcmExec -Force
Start-Sleep -Seconds 10
# Re-register ConfigMgr WMI providers
$wmiFiles = Get-ChildItem "C:\Windows\System32\wbem" -Filter "*.mof" |
Where-Object { $_.Name -like "*ccm*" -or $_.Name -like "*sms*" }
foreach ($f in $wmiFiles) {
mofcomp $f.FullName
}
Start-Service CcmExecAfter the repository reset, wait about five minutes and then check CcmExec memory again with the PowerShell snippet from Step 1. If memory stabilizes under 200 MB and stops climbing, WMI was your culprit. You should also verify the ConfigMgr client health in the console: navigate to Assets and Compliance → Devices, find the machine, right-click, and select Client Check → View Configuration Manager Client Activity. A healthy client shows green checkmarks for WMI, Client Health, and Policy.
I cannot count how many ConfigMgr site server memory problems I've traced back to SQL Server running at its default memory configuration: 2,147,483,647 MB, effectively unlimited. SQL will consume all available RAM, leaving the OS and ConfigMgr's own services fighting for scraps. This causes ConfigMgr components to page heavily, triggering cascading performance issues that look like application memory leaks.
The rule of thumb for ConfigMgr SQL memory allocation is to leave at least 4 GB free for the OS, plus buffer for other services. On a dedicated SQL host with 32 GB RAM, set SQL max memory to 26–28 GB. On a co-located site server/SQL host, be more conservative, leave 6–8 GB free.
Fix it in SQL Server Management Studio (SSMS). Connect to the ConfigMgr SQL instance, then:
- Right-click the server name → Properties
- Click Memory in the left panel
- Set Maximum server memory (in MB) to your calculated value
- Click OK
Or do it faster with T-SQL (replace 26624 with your target value in MB):
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'max server memory (MB)', 26624;
RECONFIGURE WITH OVERRIDE;
-- Verify
EXEC sp_configure 'max server memory (MB)';This change takes effect immediately, no SQL restart required. Monitor SQL memory usage in Task Manager after applying it. The sqlservr.exe working set should stabilize at or below your configured maximum within a few minutes as SQL releases pages back to the OS.
While in SQL Management Studio, also check for long-running queries that are holding memory. Run this against the ConfigMgr database (CM_<sitecode>) to find queries running over 60 seconds:
SELECT TOP 10
r.session_id,
r.status,
r.command,
SUBSTRING(t.text, 1, 200) AS QueryText,
r.cpu_time,
r.total_elapsed_time / 1000 AS ElapsedSec,
r.reads, r.writes
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.total_elapsed_time > 60000
ORDER BY r.total_elapsed_time DESC;ConfigMgr's logs are genuinely excellent once you know where to look. Every component writes its own log, and memory-related issues always leave traces. The default log path on a client is C:\Windows\CCM\Logs\. On a site server, logs live at <ConfigMgr Install Dir>\Logs\, typically C:\Program Files\Microsoft Configuration Manager\Logs\.
Use CMTrace.exe (included with the ConfigMgr client, usually at C:\Windows\CCM\CMTrace.exe) to view these logs, it highlights warnings in yellow and errors in red, which saves enormous time.
Key logs for MEM ConfigMgr memory troubleshooting:
| Log File | What It Covers | Memory-Related Errors to Look For |
|---|---|---|
CcmExec.log | Main client service lifecycle | "Failed to allocate memory", "Out of memory", thread crash messages |
InventoryAgent.log | Hardware/software inventory cycles | Very long inventory collection times, timeouts during collection |
PolicyAgent.log | Policy download and application | Repeated policy download failures, retry loops |
ClientIDManagerStartup.log | Client registration | WMI access failures during startup |
SMS_Executive.log | Site server main service | Component thread failures, restart loops |
smsdbmon.log | Database monitor | SQL connection failures, timeout errors |
To search for memory-related errors across all client logs at once, use PowerShell from an elevated prompt on the machine:
$logPath = "C:\Windows\CCM\Logs"
$keywords = @("out of memory","failed to allocate","memory pressure","WMI.*fail","thread.*exit")
Get-ChildItem $logPath -Filter "*.log" | ForEach-Object {
$file = $_.FullName
$matches = Select-String -Path $file -Pattern ($keywords -join "|") -ErrorAction SilentlyContinue
if ($matches) {
Write-Host "=== $($_.Name) ===" -ForegroundColor Cyan
$matches | Select-Object -Last 10 | ForEach-Object { Write-Host $_.Line }
}
}If InventoryAgent.log shows inventory cycles taking more than 20 minutes, your hardware inventory configuration is too aggressive. If PolicyAgent.log shows thousands of retry lines, policy delivery is broken, usually a management point issue or a WMI problem feeding bad data back to the MP.
When a full service restart, WMI repair, and SQL tuning haven't resolved the MEM ConfigMgr memory problem, the client installation itself may be damaged. Partial upgrades, interrupted installations, or antivirus interference during a client push can leave ConfigMgr in a state where it works just enough to report healthy but bleeds memory constantly.
The cleanest solution is a full client reinstall. Do this from an elevated command prompt:
REM Step 1: Uninstall the existing client
"C:\Windows\CCMSetup\ccmsetup.exe" /uninstall
REM Wait for ccmsetup to complete (check Task Manager, when ccmsetup.exe disappears, uninstall is done)
REM Then verify the CCM folder is cleaned up:
dir C:\Windows\CCMIf CCMSetup isn't present locally, or the uninstall fails, force-remove with this PowerShell sequence:
# Force stop all ConfigMgr services
$services = @("CcmExec","smstsmgr","CmRcService","ccmsetup")
$services | ForEach-Object { Stop-Service $_ -Force -ErrorAction SilentlyContinue }
# Remove WMI namespaces
Get-WmiObject -Namespace root -Class __Namespace |
Where-Object { $_.Name -like "ccm*" } |
ForEach-Object { $_.Delete() }
# Remove leftover folders
Remove-Item "C:\Windows\CCM" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "C:\Windows\CCMSetup" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "C:\Windows\CCMCache" -Recurse -Force -ErrorAction SilentlyContinue
# Remove ConfigMgr registry keys
Remove-Item "HKLM:\SOFTWARE\Microsoft\CCM" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "HKLM:\SOFTWARE\Microsoft\CCMSetup" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "HKLM:\SOFTWARE\Microsoft\SMS" -Recurse -Force -ErrorAction SilentlyContinueAfter cleanup, trigger a fresh client push from the ConfigMgr console: Assets and Compliance → Devices → right-click the target machine → Install Client. Walk through the Client Push Installation Wizard, ensure "Always install the client software" is checked, and let it run. The new client install typically takes 10–20 minutes. After it completes, verify in the console that the client shows a green check under Client Activity, then monitor memory for 2 hours. A fresh install of a healthy client idles at 80–150 MB, consistently.
Advanced Troubleshooting
Group Policy Conflicts with ConfigMgr Client Behavior
In domain-joined environments, Group Policy can interfere with ConfigMgr memory management in ways that aren't obvious. Specifically, the policy Computer Configuration → Administrative Templates → Windows Components → Windows Management Instrumentation (WMI) → Disallow WMI providers loading in the service host will prevent ConfigMgr's WMI providers from loading correctly, causing CcmExec to retry continuously, classic symptom: memory grows 5–10 MB per minute and never plateaus.
Check your effective policies on the affected machine:
gpresult /h C:\Temp\gpresult.html /f
# Then open C:\Temp\gpresult.html in a browser and search for "WMI"Also check for software restriction policies or AppLocker rules that might be blocking ConfigMgr components. Event ID 8004 in Application and Services Logs → Microsoft → Windows → AppLocker → MSI and Script will show you if anything ConfigMgr-related is being blocked.
Event Viewer Correlation for Site Server Memory Issues
On the site server itself, open Event Viewer and navigate to Application and Services Logs → Configuration Manager (if that channel exists) and Windows Logs → Application. Filter for these specific Event IDs that indicate memory-pressure-related failures:
- Event ID 4999, SMS_Executive component has terminated unexpectedly. Frequent recurrences mean a component is crash-looping and eating memory on each load.
- Event ID 5000, CCM component unable to initialize. Often precedes memory exhaustion on an MP.
- Event ID 1000, Faulting application
CcmExec.exe, actual crash, gives you the faulting module (often a third-party AV DLL injected into CcmExec). - Event ID 2019 / 2020 in System log, non-paged pool or paged pool exhaustion. This is OS-level memory depletion, often caused by driver leaks but can be triggered by ConfigMgr's heavy kernel object usage during large deployments.
Management Point Memory, The Hidden Bottleneck
If all your clients are hammering a single management point during business hours, the MP's IIS worker process (w3wp.exe) can exhaust memory. Check the MP's IIS application pool configuration: IIS Manager → Application Pools → SMS Management Point Pool → Advanced Settings → Maximum Worker Processes. On an MP serving more than 5,000 clients, set this to 2 or 3. Also set a Private Memory Limit (KB) of around 1,572,864 (1.5 GB) to force worker process recycling before it takes the whole server down.
Registry Tweak for CcmExec Memory Threshold
ConfigMgr has an undocumented registry value that controls the memory threshold before the client reduces its operational footprint. On clients with chronic memory pressure:
# Set CcmExec to be more aggressive about releasing memory
# Value is in bytes; 524288000 = 500 MB soft cap
reg add "HKLM\SOFTWARE\Microsoft\CCM" /v MaxCCMMemoryMB /t REG_DWORD /d 500 /fThis is a soft hint, not a hard limit, but I've seen it help on machines with 4 GB RAM where ConfigMgr is competing aggressively with other applications.
procmon.exe from Sysinternals) capturing CcmExec activity for 10 minutes during the memory climb, and export the ConfigMgr client logs. Then open a case at Microsoft Support with those artifacts ready. Reference the Event ID 4999 or 1000 entries specifically, it helps route your case to the ConfigMgr product team faster.
Prevention & Best Practices
Once you've fixed the immediate MEM ConfigMgr memory problem, the goal is to make sure it doesn't come back quietly. I've managed environments where these issues were just accepted as "normal ConfigMgr behavior" for years. They're not normal, they're fixable and preventable.
Size your infrastructure for your client count. Microsoft publishes specific hardware requirements for each ConfigMgr role. An MP supporting 10,000 clients needs at least 8 GB RAM and a dedicated CPU core for the IIS worker pool. Running ConfigMgr roles on undersized VMs is the number one cause of chronic memory exhaustion that never fully resolves.
Keep ConfigMgr Current Branch current. Microsoft releases several Current Branch updates per year. Each one contains memory bug fixes and performance improvements. The pattern I see consistently: shops running CB 2203 while CB 2403 is available are experiencing bugs that were already fixed. Set up a test hierarchy or use a phased ring to stay within one version of the latest release.
Monitor proactively with built-in ConfigMgr health tools. Enable the Client Health Dashboard at Monitoring → Client Status → Client Health Dashboard. Set the client health evaluation schedule to run daily rather than the default weekly. This surfaces memory-related client failures before users start complaining.
Tune hardware inventory to only collect what you need. Every custom hardware inventory class you add, every extra WMI namespace, every file collection rule, adds memory load to every client during inventory cycles. Audit your hardware inventory settings at Administration → Client Settings → Default Client Settings → Hardware Inventory → Set Classes and disable anything not actively used in reports or compliance baselines.
Implement SQL maintenance plans. ConfigMgr's SQL database grows index fragmentation over time, causing queries to take longer and hold memory longer. Schedule weekly index rebuilds and daily statistics updates using the ConfigMgr Toolkit's SQL Maintenance scripts or the built-in Site Maintenance task at Administration → Site Configuration → Sites → Site Maintenance. Enable Delete Aged Discovery Data, Delete Aged Status Messages, and Rebuild Indexes tasks.
- Set SQL Server max memory to 75–80% of total RAM on dedicated SQL hosts; 60% on co-located hosts, do this on day one of every ConfigMgr deployment
- Enable CcmExec restart via a scheduled task or ConfigMgr baseline on a 14-day cycle to drain accumulated memory leaks before they cause user impact
- Set IIS application pool private memory limits on all Management Points to prevent MP crashes from cascading to client policy failures
- Subscribe to the SCCM/ConfigMgr release RSS and apply each Current Branch update within 90 days of release to stay ahead of known memory bugs
Frequently Asked Questions
CcmExec.exe is using 1 GB of RAM, is that normal?
No, that's not normal during steady-state operation. A healthy ConfigMgr client idles at 80–200 MB. You'll see CcmExec spike to 400–600 MB temporarily during hardware inventory cycles or large software deployments, but it should drop back down within 30 minutes of the operation completing. If CcmExec is consistently sitting at 1 GB, restart the SMS Agent Host service first, then check InventoryAgent.log for a stuck or runaway inventory cycle. If the problem returns after the restart, follow Step 2 in this guide to repair the WMI repository.
How do I know if it's a client problem or a site server problem causing slow ConfigMgr performance?
The fastest way to tell: check whether the issue affects all clients or just some. If every machine in your environment is slow to receive policies and deployments, the problem is almost certainly on the site server, management point, or SQL Server. If only specific machines are sluggish, the issue is on those clients. Run the PowerShell CcmExec memory check from Step 1 on a sample of "fast" versus "slow" machines to compare, the numbers will tell you where to focus. Check smsdbmon.log on the site server for database errors if you suspect the server side.
My ConfigMgr SQL Server is using all available memory, is that a problem?
Yes, this is a very common and easily fixed problem. SQL Server's default behavior is to consume all available RAM it can get, which is actually by SQL Server design for caching query results. But when ConfigMgr's SQL instance shares a host with other services, or with the site server itself, leaving SQL uncapped starves the OS and ConfigMgr services of memory. Follow Step 3 in this guide to set an explicit maximum memory value. As a quick rule: leave at least 4 GB free for the OS, more if you have other roles on the same box. This change alone often resolves what looks like a complex ConfigMgr memory issue.
Will rebuilding the ConfigMgr client delete software or data from the machine?
No, rebuilding the ConfigMgr client (ccmsetup) removes and reinstalls only the management agent. It does not uninstall software that was previously deployed, does not touch user data, and does not remove compliance baselines or their results from the machine. The only thing you lose is the local client cache (C:\Windows\CCMCache), which contains temporary copies of deployment content that can be re-downloaded. After the client reinstalls, it will re-download policy from the management point and re-establish its health state in the console within about 15–30 minutes.
Event ID 4999 keeps appearing for SMS_Executive, what does it mean?
Event ID 4999 in the Application log means a specific SMS_Executive component thread has crashed and been restarted. Look at the full event description, it names the component (like SMS_DISTRIBUTION_MANAGER or SMS_POLICY_PROVIDER). If the same component crashes repeatedly within hours, open the corresponding site server log file (e.g., distmgr.log or policypv.log) in CMTrace and look for the error preceding each crash. Frequently the root cause is a SQL connection timeout, an access permission issue, or a specific content item that the component is failing to process. Fixing that underlying issue stops the restart loop and eliminates the associated memory churn.
Can antivirus software cause ConfigMgr CcmExec memory leaks?
Absolutely, and this is one of the most frequently missed causes I see. Antivirus products that use DLL injection or process inspection hooks can destabilize CcmExec if they're scanning every WMI call or file operation ConfigMgr makes. The signature is CcmExec handles climbing into the thousands (visible in Task Manager → Details → Handle count column). Exclude the C:\Windows\CCM\, C:\Windows\CCMCache\, and C:\Windows\CCMSetup\ directories from real-time AV scanning, and add CcmExec.exe and ccmsetup.exe to your AV process exclusion list. Microsoft documents these exclusion recommendations in their ConfigMgr deployment guidance.