What "Not Responding" Really Is — How Windows Decides an App Has Hung, and How to Design Apps That Don't

“The screen goes white during processing and the title bar says ‘Not Responding.’” “Users tell us it hangs occasionally, but it never reproduces on a development machine.” These are common complaints about Windows business apps.

The first thing to understand is that it is Windows, not the app itself, that displays “Not Responding.” Windows detects that the window’s message processing has stopped and replaces the original screen with a substitute window. The key to tracing the cause is what the UI thread that owns that window is doing that keeps it from processing the next message.¹²

This article is for developers building business apps on Windows and for IT staff who field tickets about apps that hang. It proceeds in the order the OS’s check → the message loop → isolating the cause by category → designs that don’t hang → an investigation procedure. If you need to investigate an app that is hung right now, read Chapter 7 first.

1. The Bottom Line First: Free the UI Thread, Don’t Hide the Display

The mechanism behind “Not Responding,” how to fix it, and how to investigate it become much clearer when divided as follows.

The principle of the fix is don’t wait long and don’t compute heavily on the UI thread. The UI thread handles input, painting, progress display, and accepting cancellation, and is kept separate from time-consuming work.³

Also, the time until “Not Responding” appears and the response time that feels comfortable are two different things. Staying under 5 seconds is not good enough. Section 4.5 explains this difference.

2. “Not Responding” Is the OS’s Call: The 5-Second Rule and the Substitute Screen

2.1 The Unit of Judgment Is the Window and Its Owning Thread, Not the Whole Process

Microsoft’s documentation for IsHungAppWindow treats a window as not responding when it meets the following conditions.¹

The OS does not look at what the app is computing; it looks at whether the message loop is turning. The message loop is the mechanism that retrieves input and repaint requests in order and processes them. Chapter 3 explains how it actually works.

The same documentation also states that the 5-second value may change in the future. It is the internal timeout for the not-responding check, not a design rule that says “you may block the UI for up to 5 seconds.”¹

The check is not per-process. In an app with multiple UI threads, one window may be hung while windows owned by other threads keep working. In an investigation, too, you must go beyond looking at the process and identify the thread that owns the hung window.

2.2 The Frosted-White Screen Is a “Ghost Window”

When a top-level window is judged not responding, Windows hides the original window and replaces it with a ghost window that has the same Z-order, position, size, and appearance. The “(Not Responding)” in the title and the frosted-white look under the Aero theme come from this substitute screen, not from the hung app.²

Being able to move the substitute window does not mean the app’s contents have started working again. The OS is only standing in for the minimum operations.²⁴

A complaint that “the display appears too soon” should also be treated first as a problem of the UI thread not returning to message processing for a long time. Investigating the stalled processing comes before suppressing the display.

2.3 Not Seeing It Under the Debugger Does Not Mean It Isn’t Hung

While a debugger is attached, the OS does not create ghost windows. So even when there is a difference such as “it does not appear when run under the debugger, but it goes Not Responding in normal execution,” the UI thread may be blocked in exactly the same way, with only the display differing.²

There is also an API that disables the ghost-window swap per process, but it is not an API that fixes the hang itself. Section 6.2 explains its intended use separately.

3. Why the Screen Stops: The UI Thread and the Message Loop

3.1 Input and Repainting Are Handled by the Same Thread

Windows GUI apps are event-driven. They receive messages for the mouse, keyboard, repaint requests, timers, and so on, and run the processing that corresponds to each. Every thread that creates a window has a message queue and runs a loop like the following.⁵

MSG msg;
while (GetMessage(&msg, NULL, 0, 0) > 0) {
    TranslateMessage(&msg);
    DispatchMessage(&msg);   // the window procedure is called
}

GetMessage retrieves a message from the queue, and DispatchMessage calls the window’s window procedure. The window procedure is the function that performs the processing for a message. Button-click handling, repainting, and WinForms and WPF event handlers all connect back to this message processing on the UI thread.⁶

flowchart TB
    accTitle: Basic structure of the message loop
    accDescr: The OS puts mouse, keyboard, and other input into the thread's message queue; the UI thread's loop retrieves it with GetMessage and calls the window procedure with DispatchMessage, and when processing finishes it returns to the top of the loop
    os["OS (input, repaint requests, timers)"] --> q["Thread's message queue"]
    q --> gm["Retrieve with GetMessage"]
    gm --> dm["DispatchMessage"]
    dm --> wp["Process in the window procedure"]
    wp --> gm

Figure 1: Retrieve a message, process it in the window procedure, and return to the loop. This cycle is what keeps input and painting working.

Now, what happens when a long operation is called from inside a click handler? Until that operation returns, the UI thread cannot retrieve the next message. Clicks and repaint requests that arrive afterward can no longer be processed. This is the basic structure of a “frozen screen.”

3.2 PostMessage and SendMessage Return at Different Times

Message delivery has two paths: one that places the message on the queue, and one that waits for processing to complete.⁵⁷

In particular, when SendMessage is sent to a window on another thread, the sender is also made to wait until the receiver can process the message. This difference leads directly to the deadlock in Section 4.3.⁷

4. Causes by Category: Five Patterns That Block the UI Thread

The “Not Responding” display looks the same, but what is blocking differs. First separate the candidates, then confirm with the dumps and traces of Chapter 7.

4.1 Synchronous I/O and Network Calls

The most common pattern is performing synchronously, inside a button-click handler, a read or write of a large file, a database query, a Web API call, or access to a network drive.

What finishes in a fraction of a second on the development machine can become a wait of tens of seconds under production network latency or a file-server problem. Network drives have long timeouts when the connection drops, which makes the symptom worse. “It was fast on the development machine” is not a reason to wait on the UI thread.

4.2 The UI Thread Waits for a Lock a Worker Holds

Locks that protect shared data can also stop the UI. When a worker holds a lock for a long time and the UI thread also tries to take that lock, the UI thread ends up waiting until it can acquire it.

Even after moving the work to a worker, the screen does not free up if the UI thread waits for that work to finish or for the lock to be released. Lock discipline is covered in detail in the practical multithreading series.

4.3 Waiting for Each Other’s Completion via SendMessage

The classic deadlock is the combination in which the UI thread waits for a worker to finish, and that worker sends SendMessage to the UI and waits. The UI is waiting and cannot process messages, and the worker cannot return from SendMessage, so neither can move forward.⁷⁵

sequenceDiagram
    accTitle: Deadlock from cross-thread SendMessage
    accDescr: When a worker thread sends SendMessage to the UI thread's window while the UI thread is blocked waiting for the worker's result, each waits for the other to finish and the result is a deadlock
    participant U as UI thread
    participant W as Worker thread
    U->>U: Wait for the worker to finish (blocked)
    W->>U: SendMessage (does not return until processed)
    Note over U: Cannot process messages (waiting)
    Note over W: Cannot return from SendMessage
    Note over U,W: Waiting on each other: deadlock

Figure 2: Moving work to a worker alone is not enough. When the UI and the worker wait for each other’s completion, the result is a deadlock.

Sending to HWND_BROADCAST also calls for care. A single unresponsive window is enough to drag the sender in. Where you cannot afford to keep waiting, consider SendMessageTimeout, which sets a timeout, or PostMessage, which does not wait for processing to complete.⁸

4.4 A COM STA Stalls and Drags Other Threads Down with It

Calls from other threads into an STA object are delivered as window messages. So when the UI thread (an STA) is blocked, COM calls into it block too. It is a structure in which not only the UI but the callers as well end up waiting.

The relationship between apartments and message processing is explained in the COM STA/MTA article.

4.5 Repeating “Just an Instant” 100 Times

Even a 50 ms synchronous operation adds up to 5 seconds when repeated 100 times. Do not judge by measuring individual functions and finding them short; think in terms of the total time until the UI thread returns to the message loop.

Perceived sluggishness starts at around 100 ms. Do not aim for the 5-second not-responding threshold; design on the assumption that the UI thread may be blocked only for milliseconds.

5. Designs That Don’t Hang: Separate Running the Work from Updating the Screen

5.1 Separate Computation and Synchronous APIs from Asynchronous I/O

The principle of the fix is to push time-consuming work off the UI thread. Not everything is moved the same way, however.

With asynchronous I/O there is no need to occupy a thread just to wait. The code sample below, too, uses Task.Run for computation and the native asynchronous API for HTTP communication.³

5.2 In C#, Use async/await to Return to the UI and Update It

The next example separates heavy work from UI updates in a WinForms click handler. Because this example starts from a UI event handler and preserves the UI’s execution context, the continuation after await returns to the UI thread, where it can update controls.³

private async void RunButton_Click(object sender, EventArgs e)
{
    runButton.Enabled = false;
    try
    {
        // CPU-heavy work and synchronous-only APIs go to a worker via Task.Run
        var result = await Task.Run(() => HeavyCalculation(input));

        // For I/O, use a natively async API (it does not consume a thread either)
        var data = await httpClient.GetStringAsync(url);

        // After await we are back on the UI thread, so controls can be touched directly
        resultLabel.Text = result + data.Length.ToString();
    }
    catch (Exception ex)
    {
        // An exception leaking from an async void handler crashes the app. Catch it here
        MessageBox.Show($"The operation failed: {ex.Message}");
    }
    finally
    {
        runButton.Enabled = true;
    }
}

There are four points to take from it.

This is a code sample that shows the division of roles; the implementation of HeavyCalculation and the like, handling of form close, and progress and cancellation are omitted. The progress and cancellation that long-running work needs are added separately, as in Section 5.4.

WinForms controls and WPF elements are handled from the thread that created them. Touching them directly from a worker leads to exceptions or undefined behavior. To return to the UI thread explicitly, use Control.Invoke / BeginInvoke in WinForms and Dispatcher.InvokeAsync in WPF.³

5.3 In Win32, Notify Completion with PostMessage

The division of roles is the same in native Win32. Hand the work to a worker, and when it finishes, send a custom completion message with PostMessage and update the screen in the UI thread’s window procedure. Because PostMessage returns once the message is queued, the worker does not wait for the UI to finish processing.⁷

flowchart TB
    accTitle: Division of roles in an app that does not hang
    accDescr: The UI thread handles only accepting input, showing progress, and accepting cancellation; a worker thread runs the heavy work and returns completion to the UI thread via PostMessage or an await continuation
    ui["UI thread: input, progress, cancellation"] -->|"hand off the work"| w["Worker thread: heavy work"]
    w -->|"PostMessage / await continuation"| ui
    ui -.-> ng["No synchronous I/O or long computation on the UI thread"]

Figure 3: Hand heavy computation and synchronous work to a worker, and return screen updates to the UI thread. Asynchronous I/O is awaited with an asynchronous API, as in Section 5.1.

Waiting on the worker itself is written according to the discipline covered in the condition variable article. It is also important that the UI thread does not go back to waiting synchronously on the worker.

5.4 Design Progress and Cancellation from the Start

Even if the screen does not freeze, if nothing changes for a long time the user cannot tell whether it is working. So design progress display and cancellation as part of the processing.

The worker stops at a convenient boundary and cleans up. Having a means of progress and cancellation reduces the situations in which users resort to force-quitting. Force-quitting can lead to data corruption.

6. Two Methods That Look Like Workarounds, and Their Limits

6.1 DoEvents Invites Other Events into the Middle of the Work

Inserting Application.DoEvents() or a PeekMessage loop during heavy work processes messages and avoids the Not Responding display. However, another event handler now runs while the original work is still unfinished. This is reentrancy.

For example, DoEvents is called partway through transforming data, and a queued re-click of the button is processed. That handler modifies the same data, and then the original work resumes. In this order, the state the original work assumed is already gone.

Buttons are not the only thing that reenters. Closing the form and timers come in too. Bugs such as corrupted in-flight data or an exception from touching a closed form are timing-dependent and hard to reproduce, and they tend to be harder to investigate than Not Responding.

The principle is to separate the work, not to pump the loop by hand. Keep manual message processing confined to limited structures such as a modal progress dialog. For ordinary long-running work, use the separation and reentrancy prevention of Chapter 5.

6.2 Disabling Ghost Windows Does Not Bring Back Control

DisableProcessWindowsGhosting is an API that disables the ghost-window swap for the calling process. The disablement lasts for the lifetime of the process.⁴

It exists for special uses such as kiosk terminals, where you want to prevent the OS from putting up a substitute, operable window. The fact that message processing has stopped does not change, and the user also loses the means to move or close the window that the ghost window provided. It is not something to use as a Not Responding countermeasure in ordinary apps.

7. Investigation Procedure: Preserve the Hung Moment Before Closing

7.1 Take a Dump First

In an investigation of “it hangs occasionally,” the most valuable thing is the thread state at the moment it is hung. Once you exit or restart, that state is lost.

On the Details tab of Task Manager, right-click the target process and choose Create dump file. That gives you a full dump containing every thread’s stack. Share the procedure with the people who field the tickets, too: “when it hangs, take a dump before closing it.”

For building a collection mechanism, see the crash dump collection article.

7.2 Look at the Thread That Owns the Hung Window

Open the dump in WinDbg and check the UI thread’s stack. The thread running the message loop is usually thread 0, but some apps have multiple UI threads, so do not decide by number alone; look at the thread that owns the hung window.

The UI thread’s stack shows what it is waiting on. When a deadlock is suspected, match up the wait targets of both threads, not just one. How to read them is explained in the introductory WinDbg article.

flowchart TB
    accTitle: Basic procedure for investigating Not Responding
    accDescr: Take a dump at the hung moment, look at the UI thread's stack, identify whether it is stopped on synchronous I/O, a lock wait, or cross-thread SendMessage, and connect that to the corresponding design fix
    hang["The hung moment"] --> dump["Take a dump (before closing)"]
    dump --> stack["Look at the UI thread's stack"]
    stack --> io["Synchronous I/O or network wait"]
    stack --> lock["Lock wait"]
    stack --> sm["Cross-thread SendMessage"]
    io -.-> fix["Separate the site onto a worker"]
    lock -.-> fix
    sm -.-> fix

Figure 4: From a dump of the hung moment, trace what the UI thread is waiting on. For I/O, make it asynchronous or separate it; for locks and SendMessage, check the waiting structure as well.

7.3 Choose Between Live Inspection and Timeline Analysis

Besides dumps, there is a way to look at a running process on the spot and a way to record the flow of time.

How to capture a timeline is covered in WPR/WPA in Practice.

7.4 Narrow the Candidates from the Symptom, Then Confirm with Evidence

Reproduction conditions are also an entry point for the investigation. But do not decide the cause from the symptom alone; cross-check it against dumps and traces.

8. Summary

“Not Responding” is a mechanism in which Windows determines that a window’s message processing has stopped and puts up a substitute screen. The unit of judgment is the window and its owning GUI thread, not the whole process. The 5-second internal timeout is a value that may change in the future and is distinct from a comfortable UI response time.¹²

What to fix is not the display but the computation or wait that occupies the UI thread for a long time. Send CPU work and synchronous-only APIs to a worker, send asynchronous I/O to asynchronous APIs, and return screen updates to the UI thread. Design progress, cancellation, and reentrancy prevention as a set. Working around it with DoEvents or disabling ghost windows is no substitute.

When the cause is unknown, start by taking a dump before exiting and looking at what the thread that owns the hung window is waiting on. Replace “it looks broken” with “the UI thread cannot return to message processing,” and the places to look and the design fixes connect.

Related Articles

• Spurious Wakeups — Why Condition Variables Wake “Without Being Notified” and How to Wait Correctly on Windows
• Practical Multithreading Best Practices: .NET Edition
• COM STA/MTA Fundamentals - Threading Models and How to Avoid Hangs
• Reading Crash Dumps with WinDbg + SOS — A Practical Guide to Analysis After Collection
• Process Explorer / Handle / VMMap in Practice — Chasing Hangs, Leaks, and “File in Use” from the State Right Now
• Windows Shutdown as Seen from Your App — Surviving Exit Notifications, Restarts, and Power Loss Correctly

Related Consulting Areas

KomuraSoft LLC handles root-cause investigation (dump analysis and trace analysis) of business apps that “hang occasionally” or go “Not Responding,” refactoring of legacy UI code full of synchronous processing into async/await and worker-thread separation, and reviews of UI designs that do not freeze. Even before a reproduction procedure is known, we can help starting with designing how to gather the evidence.

• Bug Investigation & Root-Cause Analysis
• Technical Consulting & Design Review
• Windows Application Development
• Contact Us

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

Under what conditions does "Not Responding" appear?

The OS judges a window not responding when a windowed app is not waiting for input, is not in its startup processing, and has not retrieved a message (PeekMessage) for 5 seconds. The top-level window so judged is hidden and replaced with a "ghost window" of the same position, size, and appearance. The "(Not Responding)" text in the title bar and the frosted-white look belong to this ghost window, which allows only move, minimize, and close. In other words, "Not Responding" is not something the app itself displays; it is a screen the OS puts up on the app's behalf.

Is there a setting that keeps "Not Responding" from appearing while work is in progress?

Calling DisableProcessWindowsGhosting disables the swap to a ghost window for that process. That only makes the hang harder for the user to see, though: the window still does not react to input, and to the user it looks like a complete freeze that can be neither moved nor closed. The real fix is not suppressing the display but moving heavy work to a worker thread so the UI thread is never blocked for even a tenth of a second, let alone five. Note also that the OS does not create a ghost window while a debugger is attached, so it can look as if "Not Responding never happens while debugging."

Is it acceptable to avoid "Not Responding" with DoEvents (pumping the message loop by hand)?

It is not recommended. Running DoEvents or a PeekMessage loop in the middle of heavy work avoids the not-responding judgment, but any event handler can then reenter partway through the work: a re-click of the button, closing the window, a timer, and so on. Reentrancy bugs such as another handler rewriting the data being processed, or touching a form that should already be closed and throwing an exception, are timing-dependent and hard to reproduce, and they are more troublesome than Not Responding itself. The proper approach is to move the work itself to a worker thread with Task.Run or similar, and leave the UI thread responsible only for showing progress and accepting cancellation.

How do I update the screen (controls) from a worker thread?

WinForms controls and WPF elements may be touched only from the thread that created them (normally the UI thread). Touching them directly from a worker thread causes exceptions or undefined behavior. In C#, async/await is the easiest way: the continuation after await returns to the calling UI thread, so you can update controls normally after the await. To switch explicitly, use Control.Invoke/BeginInvoke in WinForms and Dispatcher.InvokeAsync in WPF. In native Win32, the established pattern is for the worker thread to send a custom completion message to the UI thread with PostMessage, and for the window procedure to update the screen.

How do I investigate the cause of an app that is showing "Not Responding"?

The important thing is to capture the state at the moment it is hung. First take a full dump from the Details tab of Task Manager with "Create dump file", then look at the stack of the UI thread (the thread running the message loop) in WinDbg. Whether it is stopped in synchronous I/O, a network wait, a lock wait, or a wait on another thread via SendMessage shows up directly on the stack. To look at a live process, use the thread list and stack view in Process Explorer; to follow it over time, capture a trace with WPR. See also this site's articles on getting started with WinDbg, Process Explorer in practice, and WPR/WPA in practice.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.