DWM Memory Consumption Workarounds

What is the Problem with the DWM?

An issue effecting thousands/millions of people ... On Windows 10/11 PCs, dwm.exe commonly consumes more and more memory (gigabytes), making the system slower and slower. Ultimately:

• Programs become too slow to use.
• Programs crash.
• Gigabytes of hard disk space are temporarily consumed (until the next restart).
• The screen goes black suddenly, for minutes/hours or until the next restart.
• The screen remains black after a sleep, for minutes/hours or until the next restart.

What is the DWM?

Before Windows Vista, a Windows program would draw directly to the screen. In other words, the program would write directly to the memory buffer shown by the video card. This approach can cause visual artifacts if a window does not repaint itself correctly. For example, if the user drags one window over another window, and the window underneath does not repaint itself quickly enough, the top-most window can leave a trail:

Source: The Desktop Window Manager - Win32 apps | Microsoft Learn

Desktop composition is performed by the Desktop Window Manager (DWM). Through desktop composition, DWM enables visual effects on the desktop as well as various features such as glass window frames, 3-D window transition animations, Windows Flip and Windows Flip3D, and high resolution support.

Source: Desktop Window Manager - Win32 apps | Microsoft Learn

Monitoring dwm.exe: Task Manager

Typically, if a program is consuming too many resources, the CPU usage and/or the memory usage will be high. The CPU and memory (working set memory) values can be checked in Task Manager. However, dwm.exe often consumes a lot of resources without these values being high. Instead, you need to check the process's commit size. This can be done using Task Manager... To open Task Manager: right-click the taskbar, click Task Manager To open Task Manager (alternative): press Ctrl+Shift+Esc To view the commit size for dwm.exe: click the Details tab [note: the Commit size column is not shown on Task Manager by default] right-click a column header (e.g. right-click Name) click Select columns if Commit size is unticked, click the Commit size checkbox to tick it click OK click the Name column header to sort processes by name press d to skip to processes beginning with d (to find dwm.exe) Some translations for 'commit size' can be found here: Microsoft UI String Search. On my PC, the commit size for dwm.exe is typically in the range 65-85 MB. But it can balloon to 10 GB and beyond. The commit size often increases relatively slowly, at less than 1 GB per hour. The fastest increase I saw in a 1-hour period was 5964 MiB (5.82 GiB). The fastest increase I saw in a 3-hour period was 11416 MiB (11.15 GiB). An example of dwm.exe temporarily decreasing the available disk space: in one instance, the dwm.exe commit size increased by 12472 MiB (12.18 GiB), while the free hard disk space (temporarily) decreased by 9328 MiB (9.11 GiB).

Monitoring dwm.exe: AutoHotkey

An example AutoHotkey script for monitoring the dwm.exe commit size:

#Requires AutoHotkey v2+
;monitor dwm.exe commit size (MB):
;this appends to a text file every 5 minutes:
vMinLast := -1
Loop
{
	vMin := A_Min
	if !Mod(vMin, 5) && (vMin != vMinLast)
	{
		vPID := ProcessExist("dwm.exe")
		vSize := ComObjGet("winmgmts:").ExecQuery("SELECT * FROM Win32_PerfFormattedData_PerfProc_Process WHERE IDProcess=" vPID).ItemIndex(0).PageFileBytes
		;vSize := ComObjGet("winmgmts:").ExecQuery("SELECT * FROM Win32_Process WHERE ProcessId = " vPID).ItemIndex(0).PageFileUsage * 1024 ;an alternative
		vSizeMB := vSize // 1024**2
		vPathOut := A_Desktop "\z log DWM.txt"
		vDate := FormatTime(, "yyyy-MM-dd HH:mm")
		vOutput := vDate "`t" vSizeMB "`r`n"
		FileAppend(vOutput, vPathOut, "UTF-8")
		vMinLast := vMin
		Sleep(4500)
	}
	Sleep(10)
}

Temporarily Stopping the Problem

Three possible solutions are: Restart the dwm.exe process. Restart the PC. Turn off the monitor temporarily via SC_MONITORPOWER. (A solution that I discovered.) Restart the dwm.exe process: You can end dwm.exe using Task Manager. (Details tab, right-click dwm.exe, End task, End process.) The system then creates a new instance of dwm.exe. However, it's possible that there could be some minor or major negative side effects of doing this. (Anecdotally, I've heard that this is OK to do on Windows 10, but could cause serious problems on Windows 11.) Restart the PC (or log out/shut down): You could press Ctrl+Alt+Del, sign out, then sign back in. Otherwise you could restart the PC. (Click the Start button, click Power, click Restart.) Otherwise you could shut down the PC, then switch it back on. (Click the Start button, click Power, click Shut down.) Turn off the monitor temporarily via SC_MONITORPOWER: (dwm.exe can be monitored manually via Task Manager.) (SC_MONITORPOWER can be triggered manually by typing a PowerShell command into the Run dialog. See lower down.) I use an AutoHotkey script to inform me when the dwm.exe commit size is above 110 MB. I then use another AutoHotkey script to send SC_MONITORPOWER to the system. This turns the monitor off temporarily. I turn the monitor back on again, by pressing any key. Some results... In January 2024, the dwm.exe problem occurred 5 times on my Windows 10 PC. The increase in size stopped immediately on all 5 occasions when I used SC_MONITORPOWER. So from my perspective, the problem is essentially solved.

Emergency Exiting a Computer with a Black Screen: Narrator and the Run dialog

If the screen goes black, press Ctrl+Win+Enter to start Narrator. Narrator can inform you of what program is active, what text is being typed in, and what text is selected. You can use this to help you close programs and initiate a shut down. However, if the screen has gone black due to high memory usage, it may be difficult to start Narrator, switch windows, or do anything else. If the computer is very unresponsive, Task Manager will probably also be very unresponsive, it could be rendered useless or almost useless. A better approach could be to open the Run dialog (by pressing Win+R), and type in commands, to end processes and/or initiate a shut down, e.g.:

taskkill /f /im chrome.exe
taskkill /f /im firefox.exe
taskkill /f /im msedge.exe
shutdown -f
shutdown -r -f
shutdown -l -f

Note: -f to force a shut down/restart/log off. Note: -r to restart. Note: -l to log off. If even the Run dialog fails, you could try Ctrl+Alt+Del, and click 'Sign out'.

Emergency Exiting a Computer with a Black Screen: AutoHotkey

If the screen goes black, closing certain processes often helps to recover visibility. The screen may reappear, either immediately, or after some minutes, or not at all. An example AutoHotkey script to close processes (which may make the screen reappear) and schedule a shutdown (in case the screen never reappears): Since the screen would be black, beeps are used, and the NumLock light is used (on/off), to indicate that the script is working.

#Requires AutoHotkey v2+
;close key programs:
;NumLock works as per usual,
;although it beeps every time it's pressed,
;and if NumLock is pressed 5 times in quick succession,
;key processes are ended,
;and a system shutdown is scheduled to occur in 25 minutes' time:
NumLock:: ;close key programs (for when the PC is very sluggish or when the screen has gone black)
{
	SoundBeep(1000)
	SetNumLockState(!GetKeyState("NumLock", "T"))
	global vGblNumLockCount
	if !IsSet(vGblNumLockCount)
		vGblNumLockCount := 0
	if InStr(A_PriorHotkey, "NumLock")
	&& (A_TimeSincePriorHotkey < 5000)
		vGblNumLockCount++
	else
		vGblNumLockCount := 1
	if (vGblNumLockCount >= 2)
		ToolTip(vGblNumLockCount)
	else
		ToolTip()

	if (vGblNumLockCount >= 5)
	{
		;close programs:
		ProcessClose("mpc-hc64.exe") ;Media Player Classic
		ProcessClose("chrome.exe") ;Chrome
		ProcessClose("firefox.exe") ;Firefox

		;schedule a restart in 25 minutes' time:
		;Win+R (Run dialog), 'shutdown -a' to abort:
		vDelaySec := 25 * 60
		Run("C:\WINDOWS\system32\shutdown.exe -r -f -t " vDelaySec,, "Hide")

		ComObject("SAPI.SpVoice").Speak("programs closed")
		ToolTip()
	}
}

Possible Causes and Fixes: The Problem Starting and Sometimes Pausing

Some of my observations: The problem usually occurs when the PC resumes after a sleep. The commit size of dwm.exe starts to gradually increase. I regularly switch monitors between PC only and TV only. It often occurs that switching to the PC pauses the problem: the commit size remains stable, it stops increasing (often for hours or days). (This connection is not something I have seen documented anywhere.) The following code can often trigger the dwm.exe commit size increase problem immediately: It also appears to be reliable in temporarily stopping the problem (commonly stopping it for days):

#Requires AutoHotkey v2+
;code to potentially trigger the dwm.exe problem:
;note: this turns off the display
;note: press any key to turn the screen back on again
;WARNING: if the PC is under heavy load, the screen may remain black
SendMessage(0x112, 0xF170, 2,, "ahk_class Progman") ;WM_SYSCOMMAND := 0x112 ;SC_MONITORPOWER := 0xF170

;equivalent to typing this into the Run dialog (Win+R):
;powershell (Add-Type '[DllImport(\"user32.dll\")]public static extern int PostMessage(int h,int m,int w,int l);' -Name a -Pas)::PostMessage(-1,0x0112,0xF170,2)

There are 2 key system settings related to the dwm.exe problem. They can be viewed/changed by typing this into the Win+R Run dialog:

control /name Microsoft.PowerOptions /page pagePlanSettings

This opens up: Control Panel\All Control Panel Items\Power Options\Edit Plan Settings Where one can specify the wait periods for: Turn off the display Put the computer to sleep Letting 'Turn off the display' occur, by leaving the PC idle, can trigger the dwm.exe problem (even with 'Put the computer to sleep' set to Never). Anecdotally, setting 'Turn off the display' to Never, reduces the number of times the dwm.exe problem occurs, but doesn't stop it completely. I.e. it appears that 'Turn off the display' and 'Put the computer to sleep' can both cause the dwm.exe problem, even with the other disabled. Deliberately turning off the display via code for a few seconds (using SC_MONITORPOWER) or by leaving the computer idle to trigger 'Turn off the display', may help pause the commit size increase. I.e. turning off the display may trigger the commit size problem, but once the problem has already started, turning off the display may help pause the problem (commonly stopping it for days). Closing and reopening certain programs might help reduce the speed of commit size increase. Note: using a screensaver does not appear to affect dwm.exe. Screensaver options can be changed by typing this into the Win+R Run dialog:

control desk.cpl,,@screensaver

By detailing these observations, and by providing code for others to monitor the dwm.exe commit size, I hope that further correlations will be observed, leading to better workarounds and solutions.

My Experiences

On my PC with 8 GB RAM: If the dwm.exe commit size gets to 3 GB, that's no problem. But at some point between 3 GB and 10 GB, the problem can get serious. The commit size often increases relatively slowly, at less than 1 GB per hour. That allows you to restart dwm.exe (or sign out and sign back in) when it's convenient. However, if the worst-case scenario does happen, and the screen goes black, my AutoHotkey script is constantly running, and is there to the rescue. Since there is no official word on whether it is safe to end the dwm.exe process via Task Manager: To sign out, then sign in, then do an errand for a few minutes while the system starts and programs load, would be a pretty good solution. However, on Windows 10, often the Windows 11 update prompt will appear, after you type in your password, but before your programs load. So the restart stalls until you dismiss the nag, and you have to find another 3-minute errand to do as your programs load. This problem usually affects me two to three times per week. Sometimes it doesn't occur for a week or 2 weeks. Based on the number of complaints online, this problem affects thousands, perhaps millions, of people.

Recommendations for Microsoft

• Provide an official webpage detailing the dwm.exe problem, including the most recent news.
• Confirm whether or not it is safe to forcibly close dwm.exe.
• State the equivalent of 'commit size' in different languages, so that people can add the column to Task Manager. See Microsoft UI String Search.
• List any 'solutions' that are known not to work.
• List any tips that might help slow down the commit size increase.
• State roughly how many people are affected by the problem.
• State whether having more free hard disk space available, could help prevent the commit size increase causing the PC to crash.
• (If it remains necessary to log-out-then-log-in to solve the problem...) Add a registry value to disable Windows 11 update prompts, permanently (or for a time period such as a year), since these halt the start-up process.
• Give details of other problems that may affect the CPU/memory/commit size of dwm.exe, that are unrelated.
• Add more granular control over the 'Turn off the display'/'Put the computer to sleep' wait periods, to minimise the time between screen off (which can trigger the dwm.exe problem), and computer asleep (when the problem ceases until the PC awakes). E.g. add more 15-minute intervals, or allow specifying an exact number of minutes. This would also help the environment by allowing people to switch off the computer sooner than otherwise e.g. after 90 minutes of idle time, not 2 hours.

I appreciate that bugs happen, and that bugs may be the fault of a third party... But the measures outlined above would provide a reasonable quick fix in the mean time. The combination of: the dwm.exe problem, the restart-stalling nags, and the lack of official information from Microsoft... This is, at present, a really bad user experience. I will happily update this article, should the information/nag situation improve. [written: 2023-10-15] [updated: 2024-02-03]