Your computer will not close YouTube and refuses to open anything else because the browser tab hosting YouTube is trapped by a hung renderer, a deadlock inside the browser's process model, or an operating system that has exhausted memory or file handles. The browser cannot paint the close animation, and the OS cannot launch new processes, so every click appears to do nothing.
This is not one bug. It is a collision between how modern browsers isolate web pages into separate processes and how the operating system allocates finite resources. Three days of persistence points away from a random glitch and toward a structural failure: a leaking process, a corrupted profile, or a driver-level conflict that survives reboots.
The Renderer Deadlock Mechanism
Chromium-based browsers, which include Chrome, Edge, Brave, and Opera, run each tab inside a renderer process sandboxed from the browser's main process. When you click the X on a YouTube tab, the browser main process sends an inter-process communication message asking that renderer to shut down. If the renderer is stuck in an infinite loop or blocked on a synchronous call, it never acknowledges the request. The tab stays visible because the browser only removes the tab after the renderer confirms termination.
YouTube is unusually prone to this because it runs a persistent media pipeline. Video decoding, audio processing, adaptive bitrate switching, and service worker caching all happen inside the renderer. A single stalled decoder queue can block the message loop that processes the close request. The browser waits, the tab lingers, and the interface appears frozen even though the main process is technically alive.
Opening a new application compounds the problem. Each new process requires memory pages, thread handles, and file descriptors from the kernel. If the hung renderer holds a lock on a shared resource, the OS scheduler cannot service the launch request. The click registers, but the process creation call blocks. That is why the failure feels total.
Quantified Process and Memory Context
A single YouTube tab commonly consumes 250 to 500 megabytes of resident memory in a Chromium browser, with 4K playback pushing higher. Each tab is a separate process, so ten tabs can easily exceed 3 gigabytes on a machine with 8 gigabytes of RAM. When physical memory is exhausted, the OS spills pages to disk through the page file, and latency rises by orders of magnitude.
Windows commits memory in 4-kilobyte pages by default and uses a page file that typically ranges from 1 to 1.5 times physical RAM. Once commit charge approaches the commit limit, allocation requests fail or stall, and new process launches queue behind swap traffic. macOS handles this through compressed memory and swap, and Linux uses an out-of-memory killer that may terminate the wrong process. None of these systems reliably kill the hung renderer because a blocked process does not respond to standard termination signals promptly.
Edge Cases That Mimic a Browser Freeze
A failing storage device can produce identical symptoms. When a solid-state drive's controller stops responding, every process that touches the page file or browser cache blocks on I/O, and the desktop appears frozen. SMART attribute 187, reported unrecovered read errors, climbing into the hundreds signals this failure mode. The browser is not the culprit; the disk is.
A corrupted browser profile is another common impostor. The preferences file, the extensions database, or the service worker cache can become malformed after an unclean shutdown. The browser then hangs during startup or shutdown routines. A profile reset resolves it, but only if you preserve bookmarks and passwords first.
Security software scanning every file operation adds 30 to 300 milliseconds of latency per call. Under heavy video streaming, that overhead compounds until the interface stops responding to input. macOS Input Monitoring permissions and Windows filter drivers are the usual suspects.
Common Misconceptions
The most persistent myth is that closing the window closes the program. It does not. The browser main process keeps running in the background, and the hung renderer stays alive. The tab reappears, and the user concludes the click failed. Use the task manager or activity monitor instead.
A second misconception holds that restarting the computer fixes everything. It clears volatile memory but leaves the corrupted profile, the failing drive, and the leaking extension untouched. The problem returns within hours, which matches the three-day pattern.
A third myth blames YouTube itself. YouTube serves the same code to millions of users. The failure lives in your local process state, driver stack, or storage health. Treating it as a website outage wastes time.
Red flag: SMART attribute 187 rising by more than 10 per week. Red flag: event log entries showing repeated application hangs for the browser process. Red flag: the same tab reappears after every restart without user action. Red flag: system fans ramping to maximum with no CPU load. Red flag: file explorer also fails to open new windows.
Timeline of a Three-Day Failure
| Hour or Day | Observable Symptom | Underlying Process State |
|---|---|---|
| Hour 0 | YouTube tab stops responding to close | Renderer blocked in media pipeline |
| Hour 1 | New tabs open slowly or not at all | Commit charge rising past 80 percent |
| Hour 6 | Clicking any icon does nothing | Process creation queued behind swap |
| Day 1 | Restart temporarily fixes the issue | Volatile memory cleared, profile intact |
| Day 2 | Task manager cannot kill the tab | Renderer ignores termination signals |
| Day 2, evening | Antivirus scan stalls | Filter driver competing for I/O |
| Day 3 | Boot time doubles | Profile corruption plus disk latency |
The table shows why a three-day pattern is diagnostic. Each restart buys hours, then the leak rebuilds. That signature separates a genuine memory leak from a one-off crash.
Comparison of Intervention Options
| Intervention | Mechanism | Typical Time Cost | Risk Level | Best For |
|---|---|---|---|---|
| Kill the renderer process | Terminates the sandboxed tab directly | Under 1 minute | Low, tab data lost | Immediate unblock |
| Browser safe mode | Disables extensions and hardware acceleration | 5 minutes | Low | Extension conflict |
| Profile reset | Rebuilds preferences and cache databases | 15 minutes | Medium, settings lost | Corrupted profile |
| RAM upgrade | Raises physical memory headroom | 30 minutes | Low | Chronic memory pressure |
| Disk replacement | Restores I/O responsiveness | 1 to 2 hours | High, data migration | Failing SSD |
| Driver rollback | Reverts a faulty graphics driver | 20 minutes | Medium | Post-update freezes |
Use the cheapest intervention first and escalate. Most three-day failures resolve at the safe-mode or profile-reset stage, not at the hardware stage.
Practical Actions and Thresholds
Open the operating system's process list and sort by memory. Kill the specific renderer tied to the YouTube tab first, then the browser main process. Do not kill unrelated processes, because the OS may become unstable.
If the process list is unresponsive, log out of the desktop session and back in. Session logout terminates user processes more reliably than task manager. If logout hangs, hold the power button for 10 seconds, which forces a hardware reset after the OS ignores the shutdown request.
Then inspect storage health. On Windows, run a SMART query through the manufacturer's tool and check attributes 5, 187, and 197. On macOS, use the disk utility's SMART status. On Linux, use smartctl. Any uncorrectable error count above zero warrants a drive replacement.
Next, reset the browser profile. Sign out of the browser account first, back up bookmarks, then create a fresh profile. Reinstall extensions one at a time and test YouTube after each. A leaking extension typically reveals itself within 10 minutes of playback.
Finally, verify memory pressure under load. Open the browser, play a video for 30 minutes, and watch commit charge. If it climbs past 90 percent of the commit limit, add RAM or reduce tab count. On a machine with 8 gigabytes, keep active tabs under 10 with video playing.
Limitations and What This Explanation Cannot Cover
This explanation describes stable process and resource mechanisms. It cannot identify your specific failing component without local diagnostics. Firmware bugs, motherboard capacitor degradation, and thermal throttling produce overlapping symptoms that only hardware testing can separate. A three-day pattern narrows the field but does not confirm a diagnosis.
If the problem persists after safe mode, profile reset, and storage checks, escalate to a qualified repair technician rather than continuing to reinstall software. Repeated reinstalls risk data loss without addressing the root cause.