After my PC froze just now, a black block was left in the middle of the screen—only Task Manager wasn’t afraid of it—and in the end I pinned the blame on Typeless

AIDO debug
,
1

I just ran into a pretty amusing Windows glitch on this machine, so I’m recording the troubleshooting process.

Let me describe the symptoms in plain language first:

The PC froze for a moment, and then a huge black rectangle appeared in the center of the screen. The craziest part was that it would block other windows, but for some reason it wouldn’t block Task Manager.

It felt really uncanny, because it didn’t look like a full system hang, and it didn’t look like the monitor was broken either. It was more like a “ghost window” had appeared out of thin air on the screen.

My initial instincts actually went in a few directions:

  • The monitor panel is damaged
  • Chrome or some browser window’s rendering blew up
  • The GPU driver just reset
  • Some resident floating window/overlay program crashed, but the window wreckage was still left on the desktop

After checking them one by one, I basically narrowed the answer down.

First, confirm it isn’t a broken monitor

The most critical little detail was: this black block could be captured in a screenshot.

This is important, because if it’s a panel defect, liquid crystal leakage, pressure damage, etc., it usually won’t show up in screenshots.
If it shows up in the screenshot, it means it’s something inside the Windows graphics stack—a “software-layer window,” not physical screen damage.

Then, check the system logs

I looked up logs around 2026-04-06 01:27, and the timeline was pretty interesting:

  • 01:27:12: alttab_windows.exe hung
  • 01:27:19: DWM (Desktop Window Manager) exited and restarted
  • 01:27:20: CPALauncher.exe crashed
  • After that there was a string of LiveKernelEvent 117 / 141 / 1a8 / 1b8
  • WindowsBlackScreenDiagnosticsV1 also appeared

The most valuable line here wasn’t who crashed, but that in CPALauncher’s .NET exception it literally said:

Desktop composition was disabled, DwmExtendFrameIntoClientArea could not complete

The meaning of that sentence is very straightforward:
It wasn’t that CPALauncher broke the system first; it was that desktop composition/DWM dropped out briefly at that time. It just happened to call a DWM API at that moment, so it blew up along with it.

So the overall direction was already clear:

First the display/graphics chain had an issue, and then various apps started erroring in a cascade.

Why I later suspected it wasn’t a single app, but the entire graphics chain wobbling

Because the subsequent noise was unusually consistent:

  • In Typeless’s Sentry logs, screen.display-removed / added / metrics-changed kept appearing repeatedly
  • PixPin.exe later crashed twice in d3d11.dll
  • NVIDIA Overlay was also repeatedly rebuilding its overlay processes during that time

When you put these together, it doesn’t look like “one app being dumb,” but more like:

The system thought the display device was removed and then added back, or the GPU driver/composition chain was doing recovery.

Once the Windows graphics chain wobbles, the programs that love messing with the desktop tend to be the first to break:

  • Floating windows
  • Overlays
  • Screenshot tools
  • Window switching enhancers
  • Transparent windows
  • Global hotkeys
  • Electron mini tools

And on this machine, I happen to have quite a few of those.

The moment I actually pinned down what the black block was

After that I stopped guessing and directly enumerated the top-level windows over the region in the center of the screen.

The hit was very clean:

  • Process: Typeless
  • Window title: Status
  • Position and size: basically matched the black block exactly

In other words, this black thing wasn’t the browser, wasn’t the desktop, wasn’t the GPU OSD itself—it was a Typeless status floating window.

Then I checked Typeless’s local resources, and you can even directly see:

  • floating_bar__window__title = "Status"

At this point it was basically confirmed:

That black block is essentially Typeless’s status floating window, but after the graphics-chain anomaly it wasn’t redrawn/closed correctly, so it turned into a pure-black top-level ghost window.

Why the detail “Task Manager isn’t blocked” was so useful

This behavior really resembles a high-level overlay window.

If a normal app window goes black, Task Manager will still be blocked by it.
But if it’s some special top-level floating window, always-on-top window, tool window, layered window, etc., Task Manager can sometimes override it due to its own display priority.

So the detail “it blocks other windows but not Task Manager” is actually strongly hinting:

Check top-level overlay windows—don’t just stare at browser tabs.

The final fix was actually very simple

No mystical tricks.

The one action that truly made the black block disappear was:

Directly kill the Typeless process.

As soon as I ended it, the black block was gone immediately.

This also shows it wasn’t a “the system is broken and must be rebooted to recover” kind of state, but rather a window entity that was still alive, just with corrupted contents.

My current understanding of the “root cause” and the “proximate cause”

I’d split it into two layers:

Proximate cause

Typeless’s Status floating window failed to recover after a display-chain anomaly, leaving behind a black top-level window.

Deeper root cause

The Windows graphics stack had issues during that period, such as:

  • DWM being interrupted/rebuilt
  • A GPU watchdog event being triggered
  • The GPU driver or display topology becoming unstable momentarily

So Typeless wasn’t the only source of the problem; it was more like one of the most visible victims in this incident.

Looking back now, what seems most suspicious

In my own priority order:

  1. Momentary instability in the GPU driver / graphics stack
  2. Too many resident window-enhancement/overlay programs stacked together
  3. Typeless itself not handling display topology changes robustly enough

The “high-risk type programs” present at the time included:

  • Typeless
  • PixPin
  • alttab_windows
  • NVIDIA Overlay
  • And CPALauncher, which I’ve already removed

Any one of these alone might not be a problem, but stacked together, it really feels like a stress test for DWM and D3D11.

If I run into a similar failure next time, how I’d handle it faster

My troubleshooting order for this kind of issue would be changed to:

  1. First check whether the black block can be captured in a screenshot
  2. If it can, immediately conclude it’s a software-layer window, not a broken screen
  3. Open Task Manager first and look for floating-window/overlay/screenshot/window-enhancement processes
  4. Enumerate or visually identify which window the black block belongs to
  5. Kill that process first, then go back to check system logs
  6. Only then decide whether to deal with deeper GPU driver issues

Tentative conclusion

This time it wasn’t “the monitor is broken,” nor was it as simple as “Chrome black screen.”

More accurately:

A graphics-chain/DWM-level anomaly took down a bunch of programs that depend on desktop composition; and Typeless’s Status floating window was unlucky enough to end up as a huge black ghost window left in the center of the screen.

This kind of issue is very Windows, and also kind of interesting:

It’s not the kind of failure you can recognize at a glance—you have to first accept the fact that “the black block is also a window object,” and then everything suddenly starts to make sense.

If later I can narrow down the driver version, reproduction conditions, or which specific Typeless feature triggers this state, I’ll add another post.