You upgraded Fedora and the desktop froze
You open your laptop after a routine package update and the cooling fans immediately hit maximum RPM. The cursor stutters. Application windows take three seconds to appear. You pull up a terminal and run htop. The top process is gnome-shell, sitting at 90 percent CPU usage. The desktop environment that is supposed to run smoothly is now consuming every available processor cycle. This scenario happens frequently after an extension update, a kernel change, or a graphics driver mismatch. You need to isolate the render loop, remove the trigger, and restore normal compositor behavior.
What is actually happening
GNOME Shell is not a static window manager. It is a dynamic compositor written in JavaScript and C, built on top of the Mutter display server. Every window animation, workspace switch, and panel widget runs through a continuous render loop. When that loop gets stuck, the CPU spikes. The loop usually stalls for one of three reasons. A third-party extension throws an unhandled exception and forces the shell to retry rendering. The graphics stack falls back from hardware acceleration to software rendering because a driver update broke the GPU interface. Or a background process hooks into the shell and triggers constant redraws.
The architecture matters here. GNOME Shell runs as a single process that owns your entire desktop session. If you are on Wayland, that process is tightly coupled to the display server. The compositor, the session manager, and the input router share the same memory space. If you are on X11, the shell runs as a separate client that talks to the X server over a socket. The fix path changes slightly depending on which protocol you are using, but the diagnostic steps remain the same. You isolate the render loop, you remove the trigger, and you restore hardware acceleration.
Extensions run JavaScript inside the shell process and have direct access to the rendering pipeline. A single bad setInterval or a broken CSS rule can force the compositor to redraw the entire screen dozens of times per second. The shell catches the error, logs it, and continues. But if the error happens inside a render callback, the shell retries the callback on the next frame. That creates an infinite loop. The CPU usage climbs until the thermal limits kick in.
Run journalctl -xeu gnome-shell first. Read the actual error before guessing.
The fix
Start by identifying whether an extension is causing the loop. Extensions are the most common culprit. Disable every installed extension at once and restart the shell safely. Do not use killall -9. That command drops you to a black screen on X11 and terminates your entire session on Wayland.
Here is how to disable all extensions and restart the compositor without losing your session.
# Disable every enabled extension to stop them from loading on next start
gnome-extensions disable $(gnome-extensions list --enabled)
# Restart the GNOME shell process on X11 without dropping the display server
# On Wayland, this command will fail gracefully. Log out and back in instead.
gnome-shell --replace &
Wait ten seconds. Open htop again. If the CPU usage drops below 10 percent, an extension was responsible. If the usage stays high, the problem lives in the core shell, the Mutter compositor, or your graphics stack.
When the shell itself is the bottleneck, the issue usually points to a driver regression or a missing firmware blob. Fedora ships open-source drivers by default, but some NVIDIA and AMD GPUs need proprietary firmware or specific kernel modules to maintain hardware acceleration. Check whether your system is falling back to software rendering.
# Query the current OpenGL renderer to verify hardware acceleration status
glxinfo | grep "OpenGL renderer"
# Check your active session type to know which logs and restart methods apply
echo $XDG_SESSION_TYPE
If the output says llvmpipe or softpipe, your GPU is not being used. The shell is rendering every frame in CPU memory, which explains the 100 percent load. Update your system packages to pull in the latest kernel and driver stack. Use dnf upgrade --refresh for weekly maintenance and bug fixes. Do not confuse it with dnf system-upgrade, which is reserved for crossing major Fedora releases.
# Refresh repository metadata and apply all pending updates including kernel and firmware
sudo dnf upgrade --refresh
# Reboot to load the new kernel and initialize GPU drivers cleanly
sudo reboot
After the reboot, verify the renderer again. If it now shows your actual GPU model, the high CPU usage should be gone. If it still shows software rendering, you need to install the proprietary driver stack or check your BIOS for secure boot restrictions that block unsigned modules.
Reboot before you debug. Half the time the symptom is gone.
Verify it worked
Do not assume the fix stuck until you see the metrics. Run a quick stress test on the desktop. Open three browser windows, switch workspaces, and play a video. Watch the CPU usage in real time.
# Monitor gnome-shell CPU and memory usage continuously
watch -n 1 'ps aux | grep gnome-shell | grep -v grep'
# Check the journal for recent compositor warnings or crashes
journalctl -xeu gnome-shell --since "10 minutes ago"
The watch command should show stable CPU percentages between 2 and 8 percent during idle, spiking briefly only during window animations. The journal should show clean startup messages without repeated Failed to load or Segmentation fault lines. If you see repeated warnings about mutter or clutter, the render pipeline is still fighting something.
Configuration files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. If you edited any shell or extension configuration, verify you changed the /etc/ copy or your ~/.config/ directory. Manual file edits drift, snapshots stay.
Common pitfalls and what the error looks like
Forcing the shell to die with killall -9 gnome-shell is a common mistake. On X11, it drops you to a black screen with a terminal. On Wayland, it terminates your entire session because the compositor and the session manager are the same process. You lose unsaved work and have to log in again. Always use gnome-shell --replace on X11, or log out cleanly on Wayland.
You will also encounter extension errors that do not crash the shell but silently degrade performance. The error usually appears in the journal as a JavaScript stack trace.
JS ERROR: Error: Cannot read properties of undefined (reading 'get_label')
at file:///usr/share/gnome-shell/extensions/user-theme@gnome-shell-extensions.gcampax.github.com/extension.js:142:23
That stack trace means an extension is trying to access a UI element that no longer exists in the current GNOME version. The shell catches the error, logs it, and continues. But if the error happens inside a render callback, the shell retries the callback on the next frame, creating an infinite loop. Disable the extension mentioned in the path. Do not ignore JavaScript errors in the journal.
Another trap is mixing X11 and Wayland troubleshooting steps. gnome-shell --replace only works on X11. Wayland sessions require a full logout. The XDG_SESSION_TYPE variable tells you which one you are running. Check it before you run restart commands.
SELinux can also interfere with custom extensions that try to read system files or modify panel behavior. Denials show up in the journal with a one-line summary.
setroubleshoot: SELinux is preventing gnome-shell from read access on the file /home/user/.config/custom-theme.css.
Read those denials before disabling SELinux. You can usually fix them by adjusting file contexts or moving the configuration to the correct directory. Trust the package manager. Manual file edits drift, snapshots stay.
When to use this vs alternatives
Use gnome-extensions disable when you suspect a third-party add-on is causing render loops or UI freezes. Use gnome-shell --replace when you are on X11 and need to restart the compositor without logging out. Use sudo dnf upgrade --refresh when the CPU spike started immediately after a partial update or a kernel change. Use glxinfo | grep "OpenGL renderer" when you need to confirm whether hardware acceleration is active. Switch to the X11 session at the login screen when Wayland compositing consistently fails on your GPU architecture. Report a bug to Red Hat Bugzilla when the issue persists after disabling all extensions and updating the kernel.