Why Computers Say Not Responding: OS Message Loop Simulator

Mechanical simulation of the Window Manager Watchdog, UI Event Pump, and Thread Starvation

PhotoViewer.exe is Not Responding

Windows has created a Ghost Window surface (IsHungAppWindow = TRUE)

🖼️ PhotoViewer Pro (64-bit) Responding

Interactive Workload Trigger

User Input Injection Area

Click or Tap Rapidly in This Box
Generates WM_LBUTTONDOWN events directly to the message queue
0

Application Rendering Canvas (60 FPS Target)

Smooth Render Box:

When UI thread is free, WM_PAINT executes smoothly every 16.6ms. If the thread freezes, animations halt instantly.

Queue Backlog
0 msgs
UI Loop Latency
16 ms
Events Processed
0
Watchdog State
OK

OS Window Manager Watchdog (5000ms Ping Threshold)

Probe Normal
0ms (Responding) 2500ms (Delayed) 5000ms (Not Responding Ghost Window Created)
OS Desktop Window Manager (DWM) periodically sends non-blocking ping messages to top-level windows. If the thread does not dispatch within 5 seconds, OS flags IsHungAppWindow = TRUE.

UI Thread FIFO Message Buffer (PeekMessage / GetMessage Pipe)

Pump Active
Queue empty (Ready for window events)
Events are strictly sequential (FIFO: First-In, First-Out).

Thread Execution Engines

Thread 0: UI Message Loop (Main Dispatcher) PUMPING_MESSAGES
Running DispatchMessage() — < 16ms event latency
Thread 1: Background Worker (Async Pool) IDLE
Worker thread disabled in synchronous presets

System Internals & Post-Mortem Diagnostics

Inspect the exact win32/POSIX OS mechanics that govern application freezes.

1. Why Clicking Makes It Worse

When an application freezes, the operating system hardware drivers continue capturing mouse clicks and keyboard presses. Each click generates a WM_LBUTTONDOWN message pushed directly into the process FIFO queue.

When the UI thread finally completes its heavy work, it must sequentially chew through every single queued click before it can process WM_PAINT. This is why dozens of spam clicks make the window stutter and replay old clicks after unfreezing.

2. The Ghost Window Mystery

If an app doesn't call GetMessage() or PeekMessage() for 5000 milliseconds, modern window managers (like Windows DWM or X11/Wayland compositors) conceal the unresponsive window behind a ghost bitmap.

The OS dims the frame and draws "(Not Responding)" in the title bar. This gives the user access to move, minimize, or close the dead window even if the process is hard-locked.

3. Real-Time Post-Mortem Log

Initializing OS Message Loop Monitor... Ready for user input.

Architecture Benchmark Comparison

Pattern UI Thread Responsiveness Watchdog Trigger Queue Backlog Handling Production Verdict
Single-Threaded Sync Stalls during long operations (6000ms+) Triggers at 5000ms (Ghost Window) Accumulates unhandled input events Anti-pattern for I/O & Heavy Compute
Async Worker Thread Constant < 16ms (60 FPS maintained) Never triggers (DWM pings dispatched) Pumps and discards clicks immediately Industry Standard (Promise/Threadpool)
Unchecked Mutex Lock Permanent freeze (Deadlock) Permanent Ghost Window state Fills until memory limit or task kill Fatal Crash / Requires OS Kill Signal
Enjoy this tool? Build your own with Super