Problem description
In some Windows 11 systems, Microsoft Excel may become intermittently unresponsive in a way that superficially resembles an application freeze, but is in fact a display rendering problem.
Identification
A characteristic pattern is that Excel appears “blocked” or stops reacting to mouse interaction and repainting, yet immediately becomes usable again if the window is moved to another monitor, particularly one with a different resolution or display scaling. In contrast, moving the window to a monitor with the same resolution or display scaling may not restore responsiveness.
This behavior can persist even when Excel’s own hardware graphics acceleration is disabled, indicating that the root cause lies outside Excel’s internal rendering settings.
Technically, the issue appears to involve the interaction between Excel, the Windows 11 Desktop Window Manager (DWM), graphics drivers, and monitor configuration.
Excel uses GPU-assisted rendering for large parts of its user interface, including worksheet display, scrolling, redraw operations, and composition of interface elements.
Under Windows 11, these rendering operations are often passed through a Windows graphics optimization called Multiplane Overlay (MPO). MPO is intended to improve performance and reduce GPU overhead by allowing applications to render portions of the screen through separate hardware overlay planes rather than requiring all content to be composited centrally by the GPU.
Under certain hardware and driver constellations, however, MPO appears to malfunction.
This is especially seen in systems with multiple monitors, differing resolutions, different DPI scaling, mixed refresh rates, hybrid graphics environments, or specialized display hardware.
Instead of continuously repainting Excel’s graphical surface, the DWM compositor may effectively stall or fail to update the Excel window correctly.
Importantly, Excel itself may continue running internally: calculations may still proceed, the process remains alive, and the application has not crashed in the conventional sense.
Rather, the visible interface stops refreshing or accepting interaction because the graphical presentation layer has become stuck.
The observation that moving Excel to a monitor with a different resolution instantly restores function provides an important clue.
A transition to a display context with different resolution or scaling forces Windows to reconstruct the rendering surface and compositor state for that application window.
In practical terms, this “rebuild” of the display path causes Excel to repaint correctly and become responsive again. Moving to another monitor with the same display characteristics may not trigger a sufficient compositor reset, explaining why the problem selectively disappears only on displays with different resolution or scaling.
Solution
Workaround: just move the window
A transition to a display with different resolution or scaling forces Windows to reconstruct the rendering surface and compositor state for that application window.
So one approach is to set a different scaling to the displays to allow for Excel to having to rerender the window content, thereby activating it again.
This, as finding that as an issue as such, is extremely simple by way of workaround, but exceedingly difficult to point out or identify.
Solution: Registry modification
A practical and highly effective workaround consists of disabling MPO in Windows through a registry modification. This is achieved by creating the DWORD registry value OverlayTestMode under:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Dwm
and assigning it the value 5.
Setting OverlayTestMode=5 instructs Windows to disable MPO and fall back to a more conventional compositing path for rendering windows. Although this may marginally reduce certain graphical optimizations, it often resolves UI freezes, black windows, redraw failures, browser flickering, and Office application hangs on affected systems. After a reboot, Excel typically returns to normal operation without requiring monitor switching or forced redraws.
In the observed case, this registry modification resolved the problem completely under Windows 11, strongly supporting the interpretation that the underlying defect was not an Excel malfunction itself, but rather a failure of the Windows compositor and MPO rendering path.
Disable Overlay Test Mode / MPO
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Dwm]
“OverlayTestMode”=dword:00000005
Re-enable Overlay Test Mode / MPO
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Dwm]
“OverlayTestMode”=-
Script to do that for you