Digital Garden
The Black Curtain Case: A Rescue Without a Reboot
After the computer froze, of two monitors only the secondary showed an image; the main screen looked as if a curtain had fallen — the taskbar remained, everything else black. The programs were all alive, merely minimized. This is not the opening of a sci-fi film; it is a real system event.
I. Memory maxed out and DWM’s sudden death
The first read-only diagnosis quickly pinned the timeline. At 21:46:39, Windows triggered a “virtual memory low” diagnostic (event ID 2004) — the biggest consumers then were java.exe at 6.8 GB, gakumas.exe at 4.6 GB, and python.exe at 3.9 GB. Measured live, physical memory of 32 GB had only 0.32 GB free, and committed memory at 50.0 of 51.3 GB was maxed out. At 21:47:07, dwm.exe (Desktop Window Manager) crashed, faulting module dwmcore.dll, exception code 0xC00001AD = STATUS_COMMITMENT_LIMIT — literally: the commit limit has been reached.
Not a dead GPU: no display-driver TDR events (4101), RTX 5090 driver status normal. The blacked-out screen was the main one (Redmi 27”, 2560×1440@164Hz); the secondary (Dell S2719DGF) was fine. At 21:47:21 DWM restarted automatically, but the main screen’s composition did not recover — the classic symptom of “taskbar alive (drawn by explorer), everything else black.”
II. The failure of the standard remedy
By the standard script, Win+Ctrl+Shift+B (restart the display driver and force re-composition) is the targeted cure. It failed. So the second act unfolded: WindowFromPoint sampling the window ownership of black-screen points, then pulling the z-order of the main screen’s windows — every sample point on the main screen belonged to Discord’s window, with Chrome rendering itself black; but the z-order still held a suspect: NVIDIA GeForce Overlay DT (a CEF overlay, always-on-top, covering the main screen, in an abnormal “visible” state after the crash).
The third act was the judgment of four screenshots: after hiding NVIDIA GeForce Overlay DT, Chrome rendered completely at once — it was the culprit. Continuing to hide TextInputHost and ChatGPT, Chrome stayed normal; with Chrome hidden too, the desktop and cmd window displayed normally.
The culprit revealed: NVIDIA’s overlay render window (CEF-OSC-WIDGET). After the DWM crash it sat in an abnormal “visible” state, painted opaque black across the whole main screen — and it sits exactly one layer below the taskbar in the window stack, which is why the taskbar stayed visible while everything else was covered by this “black cloth.” Chrome, Discord, and Feishu had been fine all along. This also explains why Win+Ctrl+Shift+B failed: it rebuilds the display driver, whereas the black screen was the overlay window’s own problem.
III. The root cure lives in memory
After the repair, the culprit was restored to hidden, and the mistakenly hidden ChatGPT and Chrome windows were put back. One trick filed for the future: next time DWM crashes and a screen goes black, besides Win+Ctrl+Shift+B, try Win+D (show desktop) and press again to toggle back — minimizing and restoring windows forces a rebuild of render surfaces.
But the last line of the diagnostic report is written for the future: this is a chronic condition, not an accident. The system log’s “virtual memory low” warnings have appeared almost daily since October 7, with a fixed cast of culprits — the MuMu emulator (6.8–7.5 GB), java instances (12 GB combined), the gakumas game itself (4–4.6 GB), Blender (6.3 GB), python, kilo-desktop. 32 GB of physical memory plus a 19.9 GB pagefile equals a 51.3 GB commit ceiling, pressed to 50 GB by these heavyweights combined. The prescription: do not run the emulator, the game, Blender, and the IDE simultaneously; cap the MuMu memory limit in its settings; enlarge the pagefile to leave headroom on the commit ceiling; watch “committed” in Task Manager — past 85% of the ceiling is the pre-explosion warning.
Real coordinates
- Event line: 21:46:39 virtual memory low (ID 2004, java 6.8 G / gakumas 4.6 G / python 3.9 G); 21:47:07 dwm.exe crash (dwmcore.dll, 0xC00001AD STATUS_COMMITMENT_LIMIT); 21:47:21 DWM auto-restarts but the main screen does not recover
- Symptom machine: main screen Redmi 27” 2560×1440@164Hz black (taskbar only), secondary Dell S2719DGF normal; no display-driver TDR (4101) events
- Culprit: NVIDIA GeForce Overlay DT (CEF-OSC-WIDGET) — after the DWM crash, abnormally visible, painted opaque black, one layer below the taskbar; hiding it restores the screen, the reason Win+Ctrl+Shift+B failed
- Live state: committed memory 50.0/51.3 GB maxed (32 G physical + 19.9 G pagefile); free memory recovers 0.3 G→9.5 G after the crash
- Prescription: heavyweights list (MuMu 6.8–7.5 G / java 12 G / gakumas 4.3–4.6 G / Blender 6.3 G); near-daily “virtual memory low” warnings since 10-07; alternate fix: Win+D round trip to force rebuild of render surfaces
Comments