Desktop Client Main-Process Freeze: Message-Pump Overload, Not Deadlock

1. Background: A freeze that looked alive but was unclickable

A desktop client used a common architecture: a local main application, a local backend service process, and remote services. After a routine version update, users encountered a highly misleading symptom: the application worked normally at startup, then became progressively slower with use, and eventually froze completely. Clicks, scrolling, and typing all stopped working, and even context menus no longer appeared. Killing the process and restarting reproduced the issue within five seconds. More strangely, reproduction was independent of whether a task had been started; the application also gradually saturated while idle.

What made this failure difficult was the deceptive surface behavior. The window still rendered normally, and no system-level “Not Responding” prompt appeared, making it easy to misdiagnose as “slow frontend rendering” or “network/backend stuck.” The investigation below distills a reusable localization methodology from this case.

2. Evidence matrix: quantify the symptoms first

The first step was not guessing but organizing observations into an evidence matrix:

Observation dimension	Observation result
User perception	Window displayed and no system-level “Not Responding,” but clicks, scrolling, and typing were all ineffective; the UI appeared frozen
CPU	Main process consistently used about 96%–100% of one core and never dropped
Memory	Main process working set slowly grew over time with no sign of dropping
Local backend process	CPU was almost 0%, eliminating the hypothesis of a remote-interaction bottleneck
Window state	Windows were enumerated through system APIs and checked for responsiveness; the main window was always judged “responding”
Reproducibility	Always reproduced after restart, independent of user actions, and also reproduced while idle

The most important contradiction was that the system judged the window as responding while the user could not interact at all. This was the breakthrough point for the entire investigation.

3. Core reasoning: not deadlock, but “fed starvation”

The desktop operating system’s window subsystem does not decide whether a window is “Not Responding” based on whether user clicks have an effect. Instead, it checks whether the thread that owns the window is continuously pumping messages. Only when the UI thread fails to enter the message loop for several consecutive seconds—commonly around 5 seconds in industry implementations—is it marked as hung.

This leads to two important inferences:

• If this were a thread deadlock, the message pump would stop completely, and the system would necessarily show “Not Responding.” That did not happen here, so the message loop was still alive.
• The UI was still unclickable, which indicated that the message queue was filled with a large number of “legitimate but meaningless” synchronous messages or tasks. User input is also a message, so it had to wait at the end of the queue with no realistic chance of timely processing. Each message was short enough not to trigger the system hang judgment, but end-to-end input latency had exploded.

In one sentence: the main thread was not stuck dead; it was drowned—a classic case of livelock and starvation rather than deadlock. The investigation directions for the two are completely different: deadlock requires finding a mutual-wait cycle, while starvation requires finding who is continuously feeding messages.

4. Process topology: narrow suspicion to one thread

A typical browser-kernel-based cross-platform desktop framework uses a multi-process architecture, with responsibilities as follows:

• Main process: window management, lifecycle, menu and tray, and the hub for inter-process communication;
• Renderer process: page rendering and frontend logic;
• GPU process: compositing and rasterization;
• Network service / storage service / audio service processes: carry the corresponding subsystem capabilities as independent processes;
• Crash collector process: dumps and reporting;
• Local backend service process: interacts with remote services and executes inference-type tasks.

The framework usually marks roles for different child processes through startup parameters, for example in the form --type=xxx, making it possible to observe CPU by process.

The observation conclusion was clean: the anomaly appeared only in the main process. The renderer, GPU, network, and storage processes were all normal, and the local backend service process had CPU near 0%, directly eliminating three hypotheses: “model inference busy,” “tool execution busy,” and “network blocked.” The investigation scope narrowed from “frontend rendering / network requests / backend stuck” to the message-handling path of the UI thread in the main process.

5. Why the main process was saturated: common root-cause checklist

Combining the three clues—always reproducible, reproducible while idle, and slowly growing memory—the following high-frequency patterns deserved priority:

1. Timer abuse / retry storms: high-frequency timers or failed retries without backoff, with every callback performing full state comparison or serialization;
2. Event listener leaks: the same callback repeatedly registered, with load growing linearly with runtime—this can explain both “slower with use” and “slow memory growth”;
3. Synchronous IPC flooding: the renderer process made high-frequency synchronous requests to the main process, forcing the main process to respond serially;
4. Heavy work on the main thread: large-object serialization, full diffs, encryption/decryption, and other CPU-intensive operations all crowded onto the single main thread;
5. State synchronization loops: state change → broadcast → change again → broadcast again, forming a self-amplifying message storm.

6. Let the main thread explain itself: three diagnostic methods

1. Sample call stacks: capture the main thread call stack repeatedly. If it always stops in the message-dispatch path, the pump is rotating normally and the bottleneck is message traffic; if it always stops in the same business function, that function is the hotspot.

2. Heartbeat probe to measure scheduling delay (sample code):

// Main-thread heartbeat: measure real event-loop scheduling delay
const INTERVAL = 200;
let last = Date.now();
setInterval(() => {
  const drift = Date.now() - last - INTERVAL;
  report('main_thread_drift_ms', drift); // healthy state should be close to 0
  last = Date.now();
}, INTERVAL);

3. Message latency instrumentation + binary-search isolation: for suspicious messages, record the delta between “enqueue time → actual processing time.” At the same time, disable modules one by one by binary search—auto-update checks, telemetry reporting, state synchronization, and so on—and observe whether saturation disappears. The “reproduces while idle” clue suggests focusing on self-driven paths such as timers, polling, and retries rather than user-interaction paths.

7. Fix and hardening: give the main thread back to interaction

• Offload heavy work: move serialization, diffs, encryption/decryption, and similar work to worker threads or a dedicated utility process;
• Coalesce high-frequency events: throttle, debounce, and batch commits to compress N messages into 1;
• Queue governance: set bounded queues and backpressure policies for pending tasks; degrade and alert when limits are exceeded;
• Idempotent listeners: deduplicate registrations and unregister with the lifecycle to eliminate repeated registration;
• Replace polling with event-driven updates: notify when state changes instead of periodically pulling the full state;
• Watchdog and self-healing: when heartbeat drift continuously exceeds a threshold, automatically collect stack snapshots and metrics, then reload the window or restart the submodule, turning “manually kill the process” into “system self-recovery”;
• Pre-release long-duration stability testing: run an idle stability soak test for several hours and observe whether the main-thread drift curve diverges.

8. Turn it into a process: a reusable troubleshooting framework

Finally, abstract the experience into a general troubleshooting chain:

Reproduce and quantify symptoms → observe CPU per process → probe window responsiveness → determine deadlock vs. starvation → narrow by process topology → sample stacks to locate the hotspot → fix → regression verification.

Supporting observability is equally important: process-level CPU, heartbeat drift, and message latency percentiles should be uniformly reported; crash dumps and stack snapshots can be archived to cloud object storage, and dashboards can be built with logging services and monitoring alerts—capabilities commonly provided as general services on mainstream cloud platforms, such as Baidu AI Cloud, and available out of the box.

This incident also leaves a memorable lesson: no matter how strong remote capabilities are, client engineering quality directly determines the lower bound of user experience. A false freeze where “the system says the window is responding, but the user cannot click anything at all” appears to be a bug on the surface, but behind it is a test of understanding message mechanisms, process models, and thread scheduling—precisely the foundational skills most worth honing in desktop development.