Why Does a Restart Fix Things? A Visual Guide to How OS and Memory Management Really Work

If you use a PC, you’ve probably run into something like this more than once.

• Your PC sometimes asks for a restart after an OS update or similar event. What’s the difference between “shutting down and starting up” and “restarting”?
• Your phone gets sluggish after a long stretch of use. Why does turning it off and on again bring it back to life?

Most people just do this without thinking, and very few can explain why it works. But trace each case back to the root and they share the same reason.

While a PC or phone is running, the OS (the underlying system software) keeps piling up “what it’s currently remembering” on top of memory. A restart is the act of flushing all of that to zero and rebuilding from scratch. And on Windows 10/11, “shut down then start up” and “restart” are not actually the same thing (we’ll get to that in §3-2).

In this article we’ll unpack:

• What memory actually is and why it disappears when you turn the power off (§1)
• How apps run by borrowing memory from the OS (§2)
• What a restart actually does step by step (§3)
• What memory leaks are and why they show up when you use a machine for a long time (§4)
• The other trap besides memory ─ resource handles (§5)
• Why updates often require a restart (§6)
• The “no-restart” world that the cloud and modern dev tooling create (§7)
• A small set of commands you can run yourself to observe all this (§8)

We’ll go step by step with diagrams, assuming zero prior background.

1. What memory really is ─ the difference between a “desk” and a “bookshelf”

To talk about why a restart fixes things, the first thing you need is a feel for memory (the “desk” your PC works on right now). Many people vaguely know “if you fill up memory, the computer slows down”, but let’s go one step deeper.

1-1. RAM is volatile ─ cut the power and it’s gone

Inside a PC there are essentially two kinds of containers for data.

• RAM (main memory) ─ fast, but everything in it disappears when the power is cut (volatile)
• SSD / HDD (storage) ─ slower, but contents survive a power-off (non-volatile)

The desk-and-bookshelf analogy works well. RAM is your desk ─ you can grab any document spread out on it instantly, but when you leave the office at night the desk gets cleared. SSD/HDD are the bookshelf ─ a bit slower to take things in and out of, but the contents stay there overnight.

That’s the physical reason a restart resets the contents of memory. The moment power actually drops (or a feature behaves as if it did), everything RAM was holding is gone, and the OS has to read what it needs from the bookshelf and lay it back out on the desk again.

1-2. The memory hierarchy ─ speed and capacity form an inverse pyramid

There are actually finer layers between RAM and SSD/HDD. From the ultra-fast little stash inside the CPU (registers) all the way down to the SSD/HDD that holds most of your machine’s capacity, speed and capacity form a roughly inverse pyramid.

       [fast / small]
   ┌───────────────────────┐
   │  CPU registers         │  a few ns, dozens of bytes per core
   ├───────────────────────┤
   │  L1 cache              │  ~1 ns, tens of KB per core
   ├───────────────────────┤
   │  L2 cache              │  a few ns, hundreds of KB to a few MB
   ├───────────────────────┤
   │  L3 cache              │  ~10 ns, a few MB to tens of MB per CPU
   ├───────────────────────┤
   │  RAM (main memory)     │  ~100 ns, 8 to 64 GB
   ├───────────────────────┤
   │  SSD                   │  ~100 µs (= 100,000 ns), 500 GB to several TB
   ├───────────────────────┤
   │  HDD                   │  ~10 ms (= 10,000,000 ns), TB-scale
   └───────────────────────┘
       [slow / large]

The key takeaways: each step down the ladder roughly multiplies access time by 10x, and there’s a clear line drawn at L1 through RAM (volatile) versus SSD/HDD (non-volatile). While the power is on, the OS and apps keep loading state into the “fast volatile” layers. When the power goes off, the upper half of the pyramid wipes itself clean.

2. Processes and memory ─ how an app “borrows the desk”

§1 gave you the picture of “memory as a desk”. Next we’ll look at how each app actually uses that desk. The goal is to be able to picture exactly what gets reset by a restart.

2-1. What is a process? ─ each running program, one by one

Open Task Manager and you see Chrome, Slack, Explorer and friends lined up. Each row is a process (one instance of a running program). When you launch an app, the OS hands it a chunk of memory and registers it as a process. When you close the app, that chunk is returned to the OS and recycled for someone else.

So the relationship is:

• A program is a file on disk (.exe, .app, etc.)
• A process is that file unfolded into RAM and currently executing

What gets reset by a restart is the second one ─ all the processes currently laid out in RAM.

2-2. The memory layout of a process ─ four rooms

The memory region assigned to a single process is divided into roughly four “rooms”:

   ┌─────────────────────────┐
   │  Text (code)             │ ← the CPU instructions to execute
   ├─────────────────────────┤
   │  Data / BSS              │ ← global variables and constants
   ├─────────────────────────┤
   │  Heap                    │ ← memory allocated dynamically (grows ↓)
   │   ↓                      │
   │                          │
   │   ↑                      │
   │  Stack                   │ ← function-call records (grows ↑)
   └─────────────────────────┘

• Text is the actual instructions of the running app (the code unfolded into RAM in §1)
• Data / BSS is where variables fixed at startup live
• Heap is where the app says “please give me a bit more memory” to the OS while it runs. This is the part that tends to bloat in long-running apps (the main battleground for memory leaks in §4)
• Stack is the temporary scratchpad used each time a function is called; it cleans itself up when the function returns

Just remember “the heap is the place that grows over time”. That’s what matters in §4.

2-3. Virtual memory ─ each app thinks it has its own private desk

One more layer to know: even when many processes are running at the same time, each app behaves as if it had the desk all to itself. The mechanism that makes this possible is virtual memory (the OS-level “pretend private desk” each app sees).

   The address each app sees (virtual address)
          │
          │   OS memory management (MMU + page table)
          ▼
   The actual location in physical RAM (physical address)

The OS keeps a mapping table (the page table) and translates “write to address 0x1000” into a real physical RAM address. App A’s 0x1000 and App B’s 0x1000 actually point to completely different physical locations.

It’s elegant, but as a side effect the OS ends up holding a huge amount of page-table data and related bookkeeping in memory. That’s also part of the “state” piling up in RAM while the machine is on, and it all goes back to zero on restart.

3. [Core] What a restart actually does

So far we’ve established that “the OS and apps stack up a lot of state in RAM” and “cutting the power wipes that”. So what is the “Restart” button you push so casually really doing under the hood? Let’s break it into 8 phases.

3-1. The 8 phases of a restart

Each phase takes anywhere from a few hundred milliseconds to a few tens of seconds; the total is your “restart wait time”.

1. 1Notify apps to quitThe OS sends running apps a “please wrap up” signal. Apps save state, flush caches, and exit cleanly.
2. 2Stop services / driversBackground daemons and device drivers (small apps that translate between the OS and hardware) shut down in order, releasing their resources.
3. 3FS sync → power offPending writes still buffered in RAM are flushed to the SSD (sync), then the machine is physically powered off. This is where RAM physically empties out.
4. 4UEFI/BIOS POSTRight after power returns, the hardware self-test (POST) runs. CPU / memory / SSD / peripherals each report “I’m here”.
5. 5Bootloader runsThe boot program at the start of the SSD (Windows Boot Manager / GRUB / systemd-boot) loads and decides which OS to start.
6. 6Kernel initializationThe OS core (kernel) is loaded into RAM and brings up memory management, process management, and the filesystem in order.
7. 7Services startThe OS launches the daemons it needs (network, audio, printing, etc.). Win = Services, Linux = systemd, macOS = launchd are the conductors.
8. 8Login → session startThe login screen appears; once you sign in, the desktop and your apps come back up. Restart complete.

Mnemonic: “notify → stop → sync → self-test → boot select → kernel → services → login“. From the moment you press the restart button until your desktop returns, you always pass through these 8 steps.

3-2. Are “shut down then start up” and “restart” the same?

This is the direct answer to the first question in §0. On Windows 10/11 they are not the same.

Since Windows 10, a feature called Fast Startup has been enabled by default. When you choose “Shut down”, instead of really tearing everything down, the OS does this:

1. Close your user-level apps (this much matches a “real” shutdown)
2. Save the kernel and driver state to a file on the SSD (similar to hibernation)
3. Power off

Next time you turn the machine on, the heavy parts (POST → bootloader → kernel init, phases 4–6) are restored from the SSD instead of running from scratch, which makes startup feel faster.

Here’s the catch though: the “state” piled up in the kernel area gets restored intact next time as well. If you choose “Restart”, on the other hand, Fast Startup is bypassed and you go through the full 8 phases, which is the only way to truly rebuild from zero.

So the rule of thumb is:

• If you only care about faster startup → shut down then power on is fine
• If “things have been weird lately” or you want a Windows Update to take effect cleanly → always pick “Restart”

It’s a small but quietly important distinction. macOS and Linux don’t really have this gap ─ shut down → power on and restart are roughly equivalent there.

4. Memory leaks ─ “the desk space that never comes back”

In §2-2 we said “the heap is the part that grows over time”. The contract is: an app should give the area back to the OS once it’s done with it. In practice though, some apps borrow and never return. That’s a memory leak (an accident where forgotten returns gradually shrink your usable workspace).

4-1. What’s actually happening

Borrowing and returning memory roughly looks like this:

   [borrow]                          [return]
   App → "give me 100 MB"            App → "I don't need this anymore, here you go"
   OS  → "here you go"               OS  → "got it, recycling for someone else"

A leak happens when the app forgets to return memory at the moment it should. The cause is almost always a programming bug ─ a reference left around, a shutdown handler not called. Even leaks of just a few hundred bytes can swell to gigabytes over hours or days if they happen inside a loop that runs many times per second.

4-2. RAM gradually getting eaten over time

Here’s a stylized picture of total RAM usage when an app with a leak is left running for 24 hours.

   RAM usage
   100% ┤                                                                ████
        │                                                          ██████████
    80% ┤                                                    ██████████████
        │                                              ██████████████████
    60% ┤                                        ██████████████████████
        │                                  ██████████████████████████
    40% ┤                            ██████████████████████████████
        │                      ██████████████████████████████████
    20% ┤                ██████████████████████████████████████
        │  ██████████████████████████████████████████████████
     0% └─────────────────────────────────────────────────────────────────────→
        0h        4h        8h        12h       16h       20h       24h

An app that started off perfectly fine quietly fills RAM up over the course of a few hours. Once RAM runs short the OS falls back to swap (§2-3) and starts shuffling pages out to the SSD, but swap I/O is roughly 1000x slower than RAM, so the whole machine starts to feel sluggish.

Why a restart fixes it: a restart wipes RAM clean (leaks and all), and every app starts from a fresh state, so the leaked total instantly resets to zero.

4-3. Phones have the same problem

Phones, unlike PCs, don’t really have a “shut down” or “restart” habit. Most people run on sleep alone for weeks or months at a stretch.

But mobile apps leak too:

• A social app in the background quietly hoards memory
• Browser tabs left open keep growing the heap
• A game holds on to image memory it allocated once and never frees it

These pile up. When “my phone has been feeling sluggish lately” or “the battery is draining faster than usual”, the reason turning it off and on again brings it back is the same as on a PC ─ that buildup gets reset. Mobile platforms have stronger automatic memory management than PCs, but they still can’t catch every per-app bug.

5. Resource handle exhaustion ─ memory isn’t the only finite thing

“Restart fixes weird stuff” isn’t only about memory leaks. The OS manages plenty of finite resources besides memory that suffer from the same “borrow and never return” problem. Together they’re called resource handles (numbered tickets the OS hands out, all of them in finite supply).

5-1. The main kinds of handles

The handles the OS hands out to apps come in roughly the categories below. They all have a maximum count, and once that maximum is hit, no new operation of that type is possible.

5-2. What “I can’t open anything” actually means

When handles leak, you tend to see symptoms like:

• “Cannot open file” / “Too many open files” errors
• The browser refuses to open a new tab
• Network connections all fail (because behind the scenes you’ve burned through every socket)
• A “cannot open window” message on Windows

Unlike memory leaks, RAM usage often looks completely normal while these happen, so people get confused: “memory is fine, why is everything broken?” Different surface, same underlying “forgot to return it” problem from §4.

Why a restart fixes it: when a process exits, the OS forcibly reclaims every handle that process was holding. A restart kills every process, so all handle counters reset to zero and the OS’s finite resources are completely freed.

6. Updates and “in-use files” ─ what “restart to apply” really means

Everyone’s seen “Windows Update installed. Please restart to complete the changes.” Why can’t the update simply finish on its own? It comes down to a constraint about files the OS itself is currently using.

6-1. File locks ─ you can’t swap something while it’s running

The OS has a mechanism called locking (the OS putting an “in use, don’t touch” tag on a file). The reason is straightforward: if someone overwrites a document while another party is in the middle of writing to it, you get corruption.

The catch is that the OS itself (the kernel) and the executables of resident services are also locked as “in use” the entire time the system is up.

   [running]
   Kernel file on the SSD ─── locked (no overwriting allowed)
            │
            ▼
   Loaded into memory ───── the CPU is currently executing these instructions

   ↓ Even when an update brings a new kernel file…

   Kernel file on the SSD ─── still locked
   New kernel file        ─── parked alongside, waiting

So you can place a new version, but you can’t swap the running one. “Restart to complete the change” means:

1. Stop the old kernel for a moment (power off)
2. On the next boot, have the bootloader load the new one

In Windows-speak it’s about “creating a moment when the swap is allowed” via a restart.

6-2. How Windows / macOS / Linux differ

The reason is the same on every OS: a running program can’t overwrite its own files in place.

6-3. The exception ─ live patching (updates without a restart)

In recent years there’s also live patching (a limited mechanism that quietly rewrites a running kernel). The main examples are:

• Linux kernel: kpatch (Red Hat) / livepatch (Canonical) / Ksplice (Oracle)
• Windows Server: certain security fixes can be applied as hot patches

That said, they don’t apply to arbitrary updates. High-risk changes (large kernel rewrites, data-structure changes, etc.) still need a real restart. There’s no magic spell yet that handles every update without one.

7. The “no restart” world that exists today

So far we’ve focused on why a restart is needed. On the cloud and in modern dev tooling, however, more and more situations cleverly hide the restart from the user. The natural question ─ “web services run 24/7, so when do they ever restart?” ─ is what we’ll answer here.

7-1. Five approaches that avoid or hide a restart

7-2. How each one works (with plain-language asides)

• Rolling restart ─ run the same service on multiple servers and restart them one at a time. User traffic is routed to the not-yet-restarted machines, so the service as a whole keeps running uninterrupted. The cloud’s “always on” reputation is mostly built on this.
• Container recreation ─ rebuild an entire container (basically a “portable little room” with the app and its dependencies sealed inside) from scratch to update the app. Way faster than restarting the whole OS (a few seconds), and usually combined with rolling restarts.
• Hot reload ─ the technique of swapping in new code or config without stopping the process. The “save the file and the page updates instantly” experience during development is exactly this. Production support varies a lot by language and framework.
• Live patching ─ the §6-3 technique of rewriting a kernel while it’s running. Doesn’t apply to every update, but is used for limited fixes.

7-3. Conclusion ─ “no restart” still means somebody is restarting somewhere

The pattern should be clear by now: even worlds that pretend “no restart” still rely on someone, somewhere, restarting at some point. Cloud services restart their fleets in turn via rolling restarts; containers are recreated all the time.

And in the inverse direction: on a personal PC where you keep using the same OS install for years, periodic restarts are unavoidable, even today. Better not to treat the restart as a villain ─ think of it as “a chance to reset the OS’s state cleanly”.

8. Observe it yourself ─ peek at memory and restart on your own machine

Now that you have the theory, take a look at your own machine. One or two commands per OS will tell you how much RAM is in use right now and when you last restarted.

8-1. Check memory usage

# Windows (PowerShell) ─ top 5 processes by memory
Get-Process | Sort-Object WS -Descending | Select-Object -First 5 Name, @{n=\u0022RSS_MB\u0022;e={[math]::Round($_.WS/1MB,1)}}

# macOS ─ system-wide memory stats
vm_stat

# Linux ─ memory in human-readable form
free -h

8-2. Check boot time (when you last restarted)

The “when did I actually last restart?” question:

# Windows (PowerShell) ─ boot time
(Get-CimInstance -ClassName Win32_OperatingSystem).LastBootUpTime

# macOS / Linux ─ how long it's been up
uptime

uptime prints “current time, time since boot, logged-in users, and load averages” on a single line. On a Linux server, an uptime in the hundreds of days is sometimes a flag for “have you been applying security updates?” (a healthy operation often prefers periodic restarts).

8-3. Check handle counts (advanced)

Curious about the handles from §5? You can check live counts like this:

# Linux ─ system-wide file descriptors in use
cat /proc/sys/fs/file-nr

# Windows (PowerShell) ─ top 5 processes by handle count
Get-Process | Sort-Object Handles -Descending | Select-Object -First 5 Name, Handles

If the counts keep climbing without ever coming down, that’s a strong leak signal.

Summary ─ four-line essence

Long article, but the essence boils down to four lines:

• A restart = rebuilding volatile memory and OS state from zero ─ RAM physically empties out, so all state is gone
• You need a restart for three things ─ leaks, handle exhaustion, and in-use files ─ none of which clear up while a process is alive
• “Shut down then start up” is not the same as “restart” on Windows 10/11 ─ pick “Restart” when you actually need a clean state
• The cloud cleverly hides restarts behind rolling restarts and containers ─ on a personal PC, periodic restarts remain a healthy practice

Once you internalize this framework, “why is this thing acting up and why does a restart fix it?” becomes the same lens for PCs, phones, and servers alike.

For the network-side foundation see What Is an IP Address?, and for the software-side handshake with the OS see Why Doesn’t Software Work Without Installation?. Combined with this article’s “state the OS accumulates” angle, you have a roughly complete view of what’s actually going on inside your computer.

FAQ

Q1. How are sleep, hibernate, and restart different?

A. They differ in where state is saved and whether you get the “restart effect”. Sleep keeps RAM powered and just pauses the CPU and screen ─ contents are intact, so you wake in seconds, but nothing about the OS state gets reset (the glitch is still there). Hibernate writes RAM contents to a file on the SSD and powers off; on the next boot the file is restored to RAM, so the state still comes back (still glitchy). Shut down then start up on Windows 10/11 saves the kernel hibernation state via Fast Startup, which means it’s not really a clean cold boot (see §3-2). Only Restart bypasses Fast Startup and walks the full set of phases, physically emptying RAM and resetting all state. If your goal is to fix something weird, just pick “Restart”.

Q2. If I add more RAM, can I stop restarting?

A. No, that’s not a real fix. More RAM just buys you more time before you notice a leak ─ the leak itself doesn’t stop. Worse, the leak can go undetected long enough that swap I/O quietly eats your performance, and one day the machine just falls over. RAM headroom is “insurance”, not a “solution”.

Q3. Are there really servers that don’t restart for hundreds of days?

A. Half true, half a bit misleading. Yes, there are individual servers with uptime over 1,000 days. But in modern cloud operations, periodic deliberate restarts are actually recommended (to apply security updates reliably, reset latent leaks and handle exhaustion, detect configuration drift, and so on). The “always-on” feeling of a service is achieved by the rolling restart approach in §7-1, where individual servers do restart regularly while the service as a whole keeps serving traffic. In other words, “the application never goes down” and “the OS instance never restarts” are different things.

Q4. Will frequent restarts wear my machine out?

A. For normal usage, basically no. In the HDD era there was some concern about mechanical wear, but modern SSDs effectively eliminate that worry. What you should avoid is holding the power button to force a hard kill ─ that skips the FS sync (phase 3 of §3-1) and risks file corruption. Choosing “Restart” properly is safe even if you do it daily.

Q5. I heard Macs barely need restarting ─ is that true?

A. Half right. macOS has looser file locking so app updates often don’t need a restart, kernel updates do still demand one, and its aggressive memory management (compressed memory, etc.) hides RAM pressure better, so you “notice the need to restart” less than on Windows. That said, memory leaks and handle exhaustion happen on every OS, so “Macs never need restarting” is overconfidence. If something feels off, just go ahead and restart.