Firefox crashing — where the browser completely disappears, or individual tabs show an error page — is a solvable problem in almost every case. The challenge is that Firefox crashes can come from completely different sources: a buggy extension, an outdated GPU driver, a corrupted profile, RAM exhaustion, or occasionally a Firefox bug itself. Knowing which is the first step. You’ll find the complete rundown in our Google Chrome Errors.
The fastest way to narrow it down: press Ctrl + Shift + P to open a Private window and browse normally for 10 minutes. Private windows disable all extensions. If Firefox stays stable in Private mode but crashes in regular mode, an extension is responsible — you just identified the cause in 60 seconds. If it crashes in Private mode too, the issue is at the profile or installation level.
Using the Crash Reporter
Firefox records every crash in a log accessible at about:crashes in the address bar. Open this before doing anything else. The crash entries show a Signature field — the specific function where Firefox failed. This is often enough to identify the cause without working through every possible fix.
What to look for in the Signature:
- A function containing “gl” or “nvoglv” → GPU/OpenGL crash — hardware acceleration is the issue
- A function referencing an extension name → that extension is crashing Firefox
- “OOM” anywhere → Out Of Memory crash — RAM exhaustion is the cause
- A Windows DLL name (like an antivirus module) → third-party software injecting into Firefox is crashing it
Each of these maps to a specific fix below. The Signature takes the guesswork out of it entirely.
Fix 1: Find and Remove the Problem Extension
If Private window or the crash reporter confirmed an extension, find which one by process of elimination: Firefox menu → Add-ons and Themes → Extensions → disable all → restart → test. If stable, re-enable extensions one at a time, restarting and testing after each. When the crash returns after re-enabling a specific extension, that’s the one.
The most commonly problematic extensions: password managers that inject into every page, ad blockers running very large custom filter lists, and older extensions from the Firefox Add-ons store that haven’t been updated for recent Firefox versions. Check the extension’s last update date in the Add-ons manager — extensions that haven’t updated in two or more years often break in ways that cause crashes.
Fix 2: Disable Hardware Acceleration
Firefox uses the GPU to render pages through hardware acceleration. When the GPU driver has a compatibility issue with Firefox’s rendering code — which happens more often after GPU driver updates and after major Firefox updates — the GPU process crashes and takes the browser with it. The pattern: crashes specifically while scrolling fast, while watching video, or on pages with heavy animations.
Settings → General → Performance → uncheck “Use recommended performance settings” → uncheck “Use hardware acceleration when available” → restart Firefox. Test stability for a session. If crashes stop, the GPU driver is the underlying issue. Update it from NVIDIA/AMD/Intel’s website directly, then re-enable hardware acceleration.
Fix 3: Refresh Firefox
Firefox’s Refresh function rebuilds the entire profile from scratch while keeping bookmarks, passwords, and browsing history. This resolves corrupted preferences, broken extension data, and accumulated profile damage without losing the things you actually care about.
Firefox menu → Help → More Troubleshooting Information → Refresh Firefox → confirm. Firefox closes, rebuilds the profile, and reopens. Extensions are removed (reinstall only the ones you actually use — this is also a useful opportunity to audit them). After refreshing, test whether crashes persist before reinstalling extensions one by one.
Fix 4: Memory Exhaustion Crashes
Firefox crashes specifically after long sessions with many tabs open are memory exhaustion rather than bugs. Firefox keeps all open tabs fully loaded in RAM by default — on 8 GB machines with 20+ tabs, total memory consumption approaches the system limit and the OS begins killing processes, starting with Firefox’s content processes.
Enable tab unloading: type about:config → accept the risk → search for browser.tabs.unloadOnLowMemory → set to true. Firefox then automatically unloads inactive tab content when memory gets tight — the tab stays open visually but reloads when you click it. Also check dom.ipc.processCount in about:config — reducing this from 8 to 4 or 6 cuts Firefox’s baseline memory consumption by reducing parallel renderer processes.
At about:memory, click “Minimize memory usage” to immediately free memory held by inactive content without changing any settings.
Fix 5: Antivirus DLL Injection
Security software that monitors browser activity does so by injecting its own DLL into Firefox’s process. When this injected DLL conflicts with Firefox’s sandbox or multi-process architecture (which Firefox has strengthened significantly in recent versions), crashes result. The crash signature in about:crashes names the DLL — if it belongs to an antivirus vendor, this is the cause.
Test: temporarily disable the antivirus software’s web protection or browser monitoring component (not the full antivirus — just browser-specific monitoring) and test Firefox stability. If crashes stop, the AV injection is the confirmed cause. The fix is either: adding Firefox to the AV’s excluded applications list so it doesn’t inject into Firefox’s process, or updating the security software to a version with improved Firefox compatibility.
Fix 6: Session Restore Crash Loop
Firefox crashing immediately when trying to restore the previous session — where it crashes, recovers, and tries to restore again, creating a loop — has a specific fix. The session data file itself is corrupted.
Navigate to %appdata%MozillaFirefoxProfiles[your profile] and rename the file sessionstore.jsonlz4 to sessionstore.jsonlz4.old. This prevents Firefox from trying to load the corrupt session. Open Firefox — it starts with a clean session instead of attempting the restore that was crashing it. Your previous tabs are gone from automatic restore, but Firefox Sync preserves history and passwords from the cloud.
Fix 7: Reinstall Firefox
When crashes persist through all the above — no extension identified, hardware acceleration disabled, profile refreshed — the Firefox installation itself is corrupted. A clean reinstall:
- Uninstall Firefox via Settings → Apps
- Navigate to
C:Program FilesMozilla Firefoxand delete any remaining folders - Download the latest Firefox installer from mozilla.org
- Install fresh
This preserves your Firefox profile (bookmarks, passwords, history) because profiles are stored separately from the installation. After reinstalling, Firefox loads the existing profile automatically and crashes caused by corrupted binaries are resolved.
WebGL Crashes and About:Config Workarounds
Firefox crashing specifically on pages with WebGL content (3D graphics, some maps, online games) traces to the WebGL implementation interacting poorly with specific GPU driver versions. Two about:config settings address this:
webgl.force-enabled → set to true: forces WebGL even if Firefox has blacklisted the current GPU/driver combination due to known issues. Try this first.
webgl.disabled → set to true: disables WebGL entirely, which prevents WebGL-related crashes at the cost of 3D content not rendering. Use this when the force-enabled approach doesn’t resolve it.
Check about:support → Graphics section to see the current WebGL renderer and whether Firefox has already fallen back to software rendering for WebGL — if it shows a software renderer rather than the hardware GPU, Firefox already detected a problem with GPU WebGL support.
Our guide on Firefox not responding covers the freeze scenarios that share root causes with crashes — hardware acceleration conflicts affect both behaviours and the Troubleshoot Mode diagnostic applies equally. For memory-related browser instability, our Chrome memory management guide covers browser tab memory strategies that apply across browsers. Mozilla’s crash documentation covers the crash reporter submission process and how Mozilla uses crash signatures to identify and prioritise fixes for widespread crash patterns.
Crash Frequency Patterns and What They Mean
The pattern of crashes is often as informative as the crash signature itself. Understanding the pattern saves time by ruling out entire categories of fixes:
Crashes immediately on launch: Profile corruption or a broken extension that runs at startup. Start with Fix 3 (Refresh Firefox) and Fix 6 (session restore). If neither helps, Fix 7 (clean reinstall).
Crashes after a specific amount of time (30 minutes, an hour): Memory exhaustion. The duration correlates to how long it takes Firefox to reach the memory ceiling. Fix 4 is specifically for this pattern.
Crashes on specific websites only: WebGL content (Fix 7’s about:config options), an extension blocking something that causes a crash rather than a simple load failure, or a site-specific Firefox bug. Testing in Private mode on that specific site confirms whether it’s extension-related.
Crashes randomly with no pattern: RAM instability or GPU driver instability. Run Windows Memory Diagnostic to test RAM. Update the GPU driver. These random-pattern crashes are hardware-level issues that manifest through Firefox but aren’t Firefox’s fault.
Crashes started after a Firefox update: The new version introduced a regression or changed how it interacts with an extension or hardware. Check Firefox’s known issues page (browsing to bugzilla.mozilla.org and searching for the crash signature) — if many users are reporting the same signature, it’s a known regression that Mozilla will patch. The short-term workaround is downgrading to the previous Firefox version (available at ftp.mozilla.org/pub/firefox/releases/).
Multi-Account Containers and IndexedDB Crashes
Firefox Multi-Account Containers (Mozilla’s official extension for isolating browsing contexts) can cause crashes specifically when switching between containers or when the container’s local storage database becomes corrupted. The crash report Signature references a storage or database function rather than a rendering operation.
Fix for container-related crashes: in Firefox, open the Multi-Account Containers extension settings → look for a “Clear Container Data” option for the specific container that was active when crashes occur. If that option isn’t available, removing the extension, clearing its data from Preferences → Privacy → Cookies and Site Data → Manage Data, and reinstalling the extension from scratch resolves the corrupted database without affecting other Firefox data. Container assignments to specific sites will need to be reconfigured, but this is a quicker fix than a full Firefox Refresh when containers are the confirmed cause.
Firefox on Windows 11 with Secure Boot
Windows 11’s Virtualization-Based Security and Memory Integrity features occasionally conflict with Firefox’s process sandbox, particularly on machines where these features were recently enabled (after a Windows update or BIOS change). The conflict produces crashes in Firefox’s content process specifically, with crash signatures referencing sandbox or IPC (Inter-Process Communication) functions.
Check Memory Integrity status: Settings → Privacy and security → Windows Security → Device Security → Core isolation → Memory integrity. If this was recently enabled, test Firefox with it temporarily disabled to confirm whether it’s the conflict source. Firefox has been actively working on Memory Integrity compatibility in recent versions, so updating Firefox to the latest release is often sufficient to resolve this conflict without needing to disable the security feature.
Third-Party Accessibility Software
Screen readers, magnification software, and other accessibility tools hook into Firefox’s accessibility API to read and relay screen content. When this hooking conflicts with Firefox’s multi-process architecture, crashes occur — specifically in the parent process rather than the content process, which is distinguishable in crash reports. Firefox shows a “Disable Firefox Accessibility Service” prompt when it detects that accessibility software is interacting with it.
If accessibility software is installed: check about:config → search for accessibility.force_disabled. If set to 1, Firefox has disabled its accessibility service due to a detected conflict. Setting this to 0 re-enables accessibility features, but may re-introduce the crashes if the conflict with the specific accessibility software persists. Check whether the accessibility software has a Firefox-specific compatibility mode or Firefox add-on that provides integration without triggering the crash-causing API hooks.
Firefox ESR for Stability on Older Hardware
Firefox ESR (Extended Support Release) is a version of Firefox that receives security updates but not feature updates for approximately one year between major version bumps. It’s designed for enterprise and educational deployments but is available to anyone. On machines where the latest Firefox version has persistent crashes that don’t respond to fixes — often older hardware where new Firefox features introduce incompatibilities — switching to Firefox ESR provides a stable, security-maintained alternative without giving up Firefox entirely.
Download ESR from mozilla.org/firefox/enterprise. Installing ESR alongside the regular Firefox release (using different profile names) lets you confirm whether ESR is stable before committing to the switch. Profile data from regular Firefox is compatible with ESR — bookmarks, passwords, and history transfer directly.
One frequently missed step: after identifying and fixing a crash cause, clear the crash history in about:crashes by clicking “Delete All Reports.” This makes it easier to identify whether new crashes after your fix are the same issue recurring or genuinely different crashes — distinguishing “my fix worked but something else is now causing crashes” from “my fix didn’t work and the same crash continues” requires a clean crash log from the point after the fix was applied. Related: How to Fix Chrome Keeps Crashing.
