The Off-Key Bard
Technology

Why Does Your Computer Sometimes Freeze Without Crashing?

Or: when the computer is still running, but nothing seems to be happening. A freeze often means the part responsible for answering you is waiting for something that refuses to finish.

Or: When the Computer Is Still Running, but Nothing Seems to Be Happening

You're working in a document when the application stops responding. The pointer still moves and you can switch windows, but clicking inside the document does nothing, and Windows may eventually announce that the app is not responding. Sometimes it's worse: the whole desktop seems dead, the taskbar ignores you, Task Manager won't open, yet the fans keep spinning and the lights stay on.

Then, occasionally, everything wakes up at once and the clicks you made during the freeze execute one after another.

It's tempting to blame an overloaded processor or assume Windows crashed. But a computer can stay powered, execute instructions, and run a functioning operating system while looking completely frozen. A freeze often means the part responsible for responding to you stopped making progress.

A Freeze Is Not a Crash

A crash is when software hits a condition that makes it terminate unexpectedly or get terminated by the operating system. The application vanishes, shows an error, or leaves diagnostic information. A freeze is different. The program may remain in memory, its process may still exist, and parts of it may still run, but it no longer responds to input. A whole-system freeze can likewise happen without an operating-system crash, with the machine powered while essential software or hardware stops progressing.

The distinction matters because causes and remedies differ, and a frozen application doesn't automatically mean a frozen operating system.

Many Threads, One Interface

Windows juggles network traffic, updates, audio, hardware interrupts, and background services alongside your document. A CPU has limited cores but the system may have thousands of software threads, so a scheduler decides which runnable threads get processor time. But not every thread is always ready to run. Sometimes a thread has to wait, and waiting is where many freezes begin.

An application also isn't one unbroken stream of instructions. A browser uses separate threads for rendering, scripts, and networking, which lets software do complicated work without locking the interface, and it opens the door to coordination problems: if one thread depends on another and the dependency is mishandled, progress stops.

The Message Loop

Graphical programs receive events such as keystrokes, mouse clicks, and window changes. A traditional Windows desktop application typically has a message loop that retrieves and handles them. When you click a button, the thread responsible for the interface has to process that click.

If that thread gets occupied with a long operation, it stops processing new input. The window remains visible because Windows still knows it exists, but it no longer responds normally. This is among the most common reasons an application looks frozen. EurekaLog's documentation on hangs states the rule plainly: the UI thread's primary responsibility is to retrieve and dispatch messages, and if a message has not been retrieved within 5 seconds, the Desktop Window Manager declares the window hung. That's the logic behind "Not Responding." Windows doesn't know why the app stopped pumping messages. It might be doing a legitimate calculation, waiting on storage, deadlocked, or stuck in a bug. The label describes observed behavior, not a diagnosis, which is why a program can recover after being marked unresponsive.

Take an enormous spreadsheet. If loading and calculating happen on the interface thread, the window freezes while the processor works flat out, then recovers when the calculation finishes. To you the app froze; to the CPU it was busy. So high CPU during a freeze doesn't mean something is broken. The question is whether the operation eventually completes.

Well-built applications push lengthy work to background threads, but multithreading doesn't make freezes impossible: the interface thread might wait synchronously for a background task, or threads may fight over shared resources. Concurrency done carefully improves responsiveness, and done carelessly creates whole new classes of problems.

Deadlock: Waiting Forever Together

One of the more interesting failures is deadlock. Picture two workers and two tools. Worker A grabs Tool 1 and waits for Tool 2, while Worker B grabs Tool 2 and waits for Tool 1. Neither will let go until the other tool is free, so both wait forever.

Software does the same thing. Thread A holds a lock protecting one resource and waits for a resource held by Thread B, which is waiting for the one held by A. Wikipedia's article on deadlocks describes it as two or more processes waiting for each other to release a resource, and lists the four conditions that must all hold: mutual exclusion, hold and wait, no preemption, and circular wait. The processor doesn't need to be overloaded and memory doesn't need to be low. The threads are just trapped in a circle.

Locks are necessary, since two threads modifying the same data at once can produce inconsistent results. But taking multiple locks in inconsistent orders invites deadlock, holding a lock during a slow operation delays everyone else, and failing to release one in an error path leaves others waiting indefinitely. Wikipedia notes that imposing a consistent ordering on resources is one way to prevent deadlock.

Not every wait is a deadlock, either. A program might be waiting for a file to load or a server to answer, and a poorly written one may wait indefinitely instead of using a sensible timeout. A busy loop is different again: a thread repeatedly checking a condition that never becomes true burns CPU without accomplishing anything, while a deadlocked thread may use almost none.

Waiting on Storage

Imagine opening a document on an external USB drive. The application asks Windows to read the file, and Windows sends the request to the device. If the drive struggles with a difficult read, it may retry or run error correction, and Windows may apply its own timeouts and retries. While that happens, the application waits. If its interface thread is the one waiting, the window freezes, and the processor may look nearly idle because nothing is being calculated. It's waiting for storage.

A problem drive can hurt more than the app using it, since Windows may need files, libraries, or paging data on that device. An old mechanical drive with long retries is a classic cause, though SSDs can stall too, including through the uncorrectable errors discussed in yesterday's article. A powerful CPU can't make progress on information it hasn't received. Task Manager's disk numbers can also mislead: very high active time doesn't mean lots of data is moving, and 100 percent activity with low throughput points to slow operations and latency, not bandwidth.

Waiting on the Network

Programs wait on the network the same way. An application sends a request and waits for the reply, and if it does that on the interface thread while the server is down or slow, the window freezes. That explains why an app can lock up opening a cloud document while the CPU, RAM, and SSD are healthy. The internet doesn't even have to be fully down: one program may depend on a troubled server while your browser works fine, or a DNS lookup or network share may stall. The useful question is what the app is waiting for and whether that thing is answering.

When Memory Runs Short

RAM gives running programs fast working space. When free physical memory gets low, Windows reclaims memory, trims working sets, and moves pages to secondary storage. That's normal virtual-memory management, and using a page file doesn't by itself mean you lack RAM. Trouble begins when the memory active programs need exceeds what physical RAM can hold efficiently. Applications keep needing pages that were just pushed out, so the system has to fetch them from storage before execution can continue.

That condition is called thrashing. Baeldung's explanation describes it as high paging activity in which processes keep faulting on pages they need right away, with faulting processes queuing for the paging device so that CPU utilization falls and overall throughput plunges. The computer isn't deadlocked or crashed. It's spending its time moving data between RAM and storage instead of doing useful work, and on a slow drive the result can be dreadful. Adding RAM helps when memory pressure is the real bottleneck, and it won't fix every freeze.

CPU Usage Can Mislead

Suppose Task Manager shows an application using 100 percent of a logical processor. That might be a busy loop or a heavy calculation, but a program can also be unresponsive while using almost no CPU because its threads are blocked, and overall percentage can hide one pegged core. The useful question is whether the threads that need to make progress are making progress. Priorities don't guarantee it either: a high-priority thread waiting on stalled storage or a lock can't proceed, and lower-priority work holding a resource can even delay higher-priority work, which is called priority inversion.

Drivers and the Display

Device drivers let Windows talk to hardware, and some run in privileged contexts, so a stuck driver can hurt more than one application: storage drivers affect disk requests, graphics drivers affect rendering. Repeated system-wide freezes deserve more investigation than one app hanging occasionally.

A graphics problem can look like a total freeze. The desktop depends on the graphics system to present new images, so if that stops, you see the last frame stay on screen even while the keyboard and background processes still work. Windows has a recovery mechanism called Timeout Detection and Recovery, or TDR. By default, Windows allows approximately two seconds for a GPU task to complete or be preempted before treating it as a potential timeout. The operating system may then attempt to recover by resetting the graphics driver and GPU, allowing the desktop to become responsive again without requiring a reboot. Users might notice a brief screen flicker or see a message stating that the display driver stopped responding and has recovered. Some applications, particularly older DirectX programs, may display a black screen or need restarting afterward. Recovery isn't guaranteed, however. Under the default configuration, Windows can trigger a system crash if repeated GPU hangs occur within a short period, typically when a sixth hang occurs within one minute after five previous recoveries. TDR is a protective recovery mechanism, not proof that the graphics card itself is defective.

Sometimes it isn't the whole system at all. Windows Explorer is the process behind the taskbar, desktop, and File Explorer windows. If it hangs, those parts of the interface can malfunction while the kernel and other processes keep running, which is why restarting Explorer from Task Manager can bring back the taskbar without rebooting.

Reading the Clues

The mouse pointer is useful evidence. If it moves while an app's window is dead, at least part of the input and display chain is responding, and the system is probably handling pointer movement independently of the app's blocked interface thread. If it doesn't move, the possibilities widen: the display may have stopped updating, an input device may have failed, or the system may be badly stalled.

Keyboard shortcuts help too. Ctrl+Shift+Esc opens Task Manager directly, Ctrl+Alt+Delete invokes a security attention sequence that may respond when an ordinary app doesn't, and on some systems Win+Ctrl+Shift+B requests graphics recovery. None guarantees recovery, but they show scope: if Task Manager opens and other programs respond, the issue may be one app.

Resist hammering a frozen window. Input events may sit queued while the interface thread is blocked, so when it resumes, a burst of pending clicks can execute at once. When a program is merely busy, giving it a chance to finish beats piling on commands.

When Hardware Is the Culprit

Not every freeze is an application flaw. Unstable RAM settings, overclocking, voltage problems, or failing components can cause inconsistent freezes, and if they began after hardware changes or aggressive tuning, return to stable settings. Heat is a tempting suspect, but hot components usually throttle first, which hurts performance without necessarily freezing anything. The workload gives context, not proof.

Windows keeps records you can use. Event Viewer holds application errors, storage warnings, and driver events, but entries need interpreting: Kernel-Power Event ID 41 commonly means Windows restarted without a clean shutdown, so if you held the power button because it froze, that event just records your forced restart. Reliability Monitor (search "View reliability history") charts failures over time so you can see whether trouble started after a driver update or installation. A timeline is often the first step toward a cause.

Recovering Safely

Restarting works because it terminates processes and reinitializes drivers and services, which clears a deadlock or other temporary condition, but it doesn't fix an underlying bug or bad driver, so the freeze may return. If Windows is still partly responsive, try closing the app, restarting Explorer, or doing a controlled restart before holding the power button. A forced power-off can lose unsaved work and interrupt storage operations, so treat it as a last resort, not a habit.

The best diagnosis starts with "Which parts are still responding?" If the mouse moves and other apps work, it's probably one program. If the taskbar is frozen but Task Manager opens, suspect Explorer. If the display stops updating while audio continues, look at graphics. If disk activity is extreme while everything waits, think storage or memory pressure. None of that is a diagnosis, but each narrows it down. The goal is to find the operation that stopped making progress.

The Bard's Take

When a computer freezes, it hasn't necessarily stopped computing. The processor may still be executing instructions, Windows may still be scheduling threads, and background services may still be running. What's missing is that one essential part is waiting for something that isn't happening. An interface thread may be buried in a calculation, two threads may be deadlocked on each other's locks, a program may be blocked on a struggling drive or an unresponsive server, memory pressure may have the system shuffling pages instead of working, or a graphics problem may have frozen the picture while everything else carries on.

That's why a freeze and a crash are different. A crash usually means something terminated unexpectedly or the system stopped because it couldn't safely continue. A freeze usually means progress is blocked. The software still exists in memory, its threads may still exist, and its files are intact, but the part responsible for answering you isn't finishing its work. So the most effective troubleshooting asks about scope. Can you move the mouse? Does Task Manager open? Are other programs responsive? Is disk activity unusually high? Did this start after a driver update or hardware change?

And sometimes the strangest thing happens. You wait thirty seconds, the storage request finally completes, a blocked thread becomes runnable, the application begins handling messages again, and every click you made takes effect at once. To you the computer came back from the dead. To the operating system, a dependency finished. A frozen computer isn't always a computer that has stopped working. Sometimes it's still working, but waiting for something that refuses to finish.

Sources

← Back to the Desk — Technology