2040781 - Firefox leaves itself in memory and prevents other programs from running correctly

Status: UNCONFIRMED

(Core :: JavaScript: GC, defect, P3)

Description

[Gary Clauson]

Attachment: TaskManager_example_19May2026.jpg

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:151.0) Gecko/20100101 Firefox/151.0

Steps to reproduce:

After using Firefox (in Windows 10), when I close it, there are Firefox fragments left in memory (as shown in Task Manager), as well as memory entries (multiple) for crashhelper.exe. These give a false status of "open browser" for other programs that need browsers to be actually closed. I don't remember when this first started, but much earlier versions of Firefox did not do this.

Actual results:

I have to either open Task Manager and close the entries individually (which can be exceedingly time-consuming), or use a program such as CCleaner to remove all of the Firefox and crashhelper.exe fragments.

Expected results:

Closing Firefox should not leave fragments in memory, i.e., after closing, there should be no entries for Firefox or crashhelper.exe shown in Task Manager.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Performance: Memory' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:jlink, could you have a look please?

For more information, please visit BugBot documentation.

Comment 3

[Justin Link]

Thanks for the report. I am going to redirect this Firefox/General as this isn't actually a memory use issue as BugBot has guessed, however I am noticing that the processes that are remaining are from the 32-bit version of Firefox. When you are closing Firefox through the UI I am wondering if you are interacting with the 64-bit version. If that is the case, then maybe the problem isn't that Firefox is leaving stray processes around even after closing but rather that, for some reason, the 32-bit version of the app is also getting started up somehow and that is what is sticking around.

If you are not intentionally using the 32-bit version of Firefox, you might be able to avoid this whole problem simply by un-installing the 32-bit version.

Comment 4

[Shane Hughes [:aminomancer]]

Hey Gary, which versions of Firefox do you have installed? Can you try following the steps Justin posted? Thanks.

Comment 5

[Robert Hartmann]

Well, perhaps related to https://bugzilla.mozilla.org/show_bug.cgi?id=2040255

Comment 6

[Robert Hartmann]

Attachment: MultipleFirefoxProcesses_No-Firefox-Window.png

Attached is a filtered ProcessExplorer View.
It shows Firefox-Processes running in background after Firefox main window has closed.
On my Windows 10 (64bit) system they stay several minutes ...

Comment 7

[Robert Hartmann]

(In reply to Robert Hartmann from comment #6)

Created attachment 9591908 [details]
MultipleFirefoxProcesses_No-Firefox-Window.png

Attached is a filtered ProcessExplorer View.
It shows Firefox-Processes running in background after Firefox main window has closed.
On my Windows 10 (64bit) system they stay several minutes ...

My steps to reproduce :

1. Boot Windows 10 (64 bit).
2. Start Firefox Versions : Release , Beta, Developer Edition, Nightly
3. Wait until all Firefox main windows are visible and show about:newtab content
4. close alle Firefox main window
5. take a screenshot

Comment 8

[Nick Rishel [:nrishel]]

:Robert anythign present in about:crashes if you let the processes sit until they shutdown?

Comment 9

[Robert Hartmann]

Tested today 2026-08-10 using

• Firefox Nightly (64bit) 155.0a1 (2026-08-10) Build-ID 20260810093015
• Firefox Developer Edition (64 bit) 154.0b8 Build-ID 20260807095657
• Firefox beta (64 bit) 154.0b8 Build-ID 20260807095657
• Firefox release (64 bit) 153.0.3 Build-ID 20260803132010

Behavior from comment 6 and comment 7 doesn't change for my Windows 10 (64 bit). Windows 11 is not possible for this hardware.

Nothing is present in about:crashes.

Comment 10

[Dave Townsend [:mossop]]

Do you know how to launch Firefox with environment variables set? If so capturing a shutdown profile would help us understand what Firefox is doing while it is hanging around.

Comment 11

[Robert Hartmann]

(In reply to Dave Townsend [:mossop] from comment #10)

Do you know how to launch Firefox with environment variables set? If so capturing a shutdown profile would help us understand what Firefox is doing while it is hanging around.

Well, thanks for the link.

Step 1 . Creating a batchfile for setting environment variables and start firefox within this batch from cmd.exe is not a problem for me.
Step 2 . "Start the profiler using the popup, then close Firefox." is not clear.

Which popup?

using this code following for my batch to start Firefox did not create a popup window - at least if some firefox window is open.

@echo off
set MOZ_PROFILER_SHUTDOWN="c:\Firefox.shutdown.log"
"C:\Program Files\Mozilla Firefox\firefox.exe"

Comment 12

[Dave Townsend [:mossop]]

You need to go to https://profiler.firefox.com and click the button to enable the toolbar button.

Comment 13

[Robert Hartmann]

Attachment: Profiler_is_running.png

I managed to start the profiler. See attached PNG. But if I just close the Firefox main window, than no file is created which should upload the needed information.

Comment 14

[Robert Hartmann]

(In reply to Robert Hartmann from comment #13)

Created attachment 9625441 [details]
Profiler_is_running.png

I managed to start the profiler. See attached PNG. But if I just close the Firefox main window, than no file is created which should upload the needed information.

Seems to me, that profiler cannot create the log file directly on "c:"

changing set MOZ_PROFILER_SHUTDOWN="c:\Firefox.shutdown.log" to set "MOZ_PROFILER_SHUTDOWN=c:\tmp\FF_shutdown.log" creates a file . Tested on Win11.
The next day I will test to create the four profile files using the system mentioned in comment 9

(I'm adding “needinfo” as a reminder for myself)

Comment 15

[Nick Rishel [:nrishel]]

Clearing original reporter NI since Robert is following up.

Comment 16

[Robert Hartmann]

Which Profiling setting should I use?
I tried "debugging" , but closing all four Firefox main windows results in "frozen nightly main window" (not reactive) ... waiting for some hours all firefox instances (release, beta, dev, nightly) are shown in process explorer.
Than I wanted to have a view to task manager , therefor pressing strg + alt + enf , but windows show me the german message,

...keine Sicherheits- und Anmeldeoptionen angezeigt werden. Falls Windows nicht reagiert, drücken Sie die ESC-Taste, oder starten Sie den PC mithilfe des Netzschalters neu.

That message means: No security or sign-in options are displayed. If Windows does not respond, press the ESC key or restart the PC using the power button.
(I will wait some more time, so see what happen next. while waiting, suddenly normal Windows Desktop gets visable again and a crashreporter window for firefox release appears.)

So perhaps "debugging" setting in Firefox Profiler in all four instances are to intensive - should I use an other setting?

(keeping NI as reminder for me, until I can upload the profiler output files.)

Comment 17

[Robert Hartmann]

• need to copy crashid
• need to upload profileing files

Comment 18

[Robert Hartmann]

Crashid for shutdown crash of Firefox release while doing shutdown profiling using "debugging" setting in firefox profiler.
bp-fa092243-f3b0-44d5-b76f-270300260812 : Firefox 153.0.3 Crash Report [@ shutdownhang | ZwUserPeekMessage ] ;
same crash signature like bug 1907698 and bug 1324399 - but other (own) stack trace.

While waiting also Firefox beta shows its crashreporter window (firefox dev and firefox nightly are running in background there main windows are closed and hopefully creating a profileing log ...):
bp-e6464792-f135-4873-9396-2d69e0260812 : Firefox 154.0b8 Crash Report [@ shutdownhang | mozilla::FrameDestroyContext::~FrameDestroyContext ] : no related bugs are found in bugzilla for this crashid.

I will let the laptop running until the shutdown profiling run for firefox dev and firefox nighly had ended either with creating the profiling log file or showing up the crashreporter window.

Comment 19

[Robert Hartmann]

Attachment: Firefox-nightly_Firefox-dev_not-finishing-shutdown-profiling_multiple-hours.png

Firefox (dev & nightly) did not finish shutdown profiling even after waiting multiple hours. I prepare myself to let the system doing the "main window closing profiling" until the next morning (that is waiting for next 12 hours for finishing)

Comment 20

[Robert Hartmann]

Attachment: Firefox_dev_nightly_shutdown-profiling-not-stopped-over-night.jpg

After the night I took a screenshot from running ProcessExplorer, which shows that two of four Firefox instances are running in background without visible window. So I assumed that the shutdown profiling for Firefox Develpoer Edition and Firefox nightly had not finished. Waiting 12 hours for finishing for "closing an application" is more than useful. (Firefox beta and Firefox release had crashed while profiling the shutdown as mentioned before.)

Comment 21

[Robert Hartmann]

Attachment: Shutdown-profiling-logfiles_visible_after_forcing_reboot.png

After forcing Windows to do a reboot, I saw that in choosen directory profiling files for all four Firefox instances where stored (see attached screenshot). These files where not visible for me befor the restart of Windows.

Comment 22

[Robert Hartmann]

Should I upload the for profiling files in this bug report as attachement?

The profiling logs are not very small.

For Firefox release (153.0.3) the profiling filesize is about 15 mega byte.
For Firefox beta (154.0) the profiling filesize is about 46 mega byte.
For Firefox dev (154.0) the profiling filesize is about 15 mega byte.
For Firefox nightly (155.0a1) the profiling filesize is about 220 mega byte.

I assume that all of those four files are in some case broken or incomplete, because of two Firefoxes crashed and the other two ran more than 12 hours without finishing.

Comment 23

[Dave Townsend [:mossop]]

If you go to https://profiler.firefox.com/ then there is an option to load the profile from the file after which you can use the button in the top-right to share it with us. Just give us the link it generates.

Comment 24

[Robert Hartmann]

Here comes the profiling URLs:

1. release
2. beta
3. dev
4. nightly

All of those instances I had started yesterday using a batch file.
After all firefox main window where visible I had choosen the debugging setting for profiling.
And than I closed all four main window and waiting until the next morning.
Profiling files showed up in Windows file explorer after rebooting Windows.

crashes while profiling as mentioned yesterday, see comment 18:

• bp-fa092243-f3b0-44d5-b76f-270300260812 : Firefox 153.0.3 Crash Report [@ shutdownhang | ZwUserPeekMessage ]
• bp-e6464792-f135-4873-9396-2d69e0260812 : Firefox 154.0b8 Crash Report [@ shutdownhang | mozilla::FrameDestroyContext::~FrameDestroyContext ]

Anything else I can do?

Comment 25

[Dave Townsend [:mossop]]

(In reply to Robert Hartmann from comment #24)

Here comes the profiling URLs:

1. release
2. beta
3. dev
4. nightly

These links aren't accessible without the files. You need to click the "Share" button in the top-right then "Upload" and give us the link it generates

Comment 26

[Robert Hartmann]

Well, directly on https://profiler.firefox.com/ there are two buttons of type <button type="button" class="homeSectionButton"> available for me:

• "Profil aus Datei laden", which opens a fileexplorer window for uploading a file. This is the variant I used.
• "Profil von URL laden", which is the variant to access a profile which is available on some URL.

Directly on https://profiler.firefox.com/ there is no button for me at the top-right, which names "share" or in German "teilen".

But perhaps you mean an other window state. After using above first variant to upload a file, than in this browser content, there is an button at the top-right:

<button type="button" class="buttonWithPanelButton menuButtonsButton menuButtonsShareButtonButton menuButtonsButton-hasIcon" aria-expanded="true">Teilen …</button>

If I click on that button a option window opens, and ask about information which should be shared from that profile.
Here is the message of that window. The message is written in german, since my Firefox is german.

Leistungsprofil teilen

Laden Sie Ihr Profil hoch und machen Sie es mit dem Link für jeden zugänglich. Standardmäßig werden Ihre persönlichen Daten entfernt.

Zusätzliche Daten einschließen, die möglicherweise identifizierbar sind
[ ] Einschließlich verborgener Threads
[ ] Dauer eingeschlossener verborgener Threads
[ ] Bildschirmfotos einschließen
[ ] URLs und Pfade von Ressourcen einschließen
[ ] Erweiterungsinformationen einschließen

Option one is for including hidden Threads. But what does this mean? Do you need this to be activate?
Option two is for their duration. If you need option one, than perhaps also option two. Right?
Option three mentione screenshots ( = Bildschirmfotos). Is it possible for me to have a look to the screenshots befor sharing?
Option four mentione URL and path ( = Pfade) . Is it possible for me to have a look to the information befor sharing?
Option five is for add-ons ( = Erweiterungen) . Do you need this to be activate?

Comment 27

[Nick Rishel [:nrishel]]

Attachment: shareprofile.png

For reference, this is the button we're referring to.

Comment 28

[Robert Hartmann]

Attachment: share-profile_german-option-window.png

And here is a screenshot of the options. Which options should I activate?

Comment 29

[Dave Townsend [:mossop]]

(In reply to Robert Hartmann from comment #28)

Created attachment 9626440 [details]
share-profile_german-option-window.png

And here is a screenshot of the options. Which options should I activate?

Ideally all of them though screenshots may reveal to us what you were browsing, but since this is during shutdown I would expect those to be empty anyway.

Comment 30

[Robert Hartmann]

• release profiling shutdown permalink https://share.firefox.dev/4g2Gfnm
• beta profiling shutdown permalink https://share.firefox.dev/4xHutpS
• dev profiling shutdown permalink https://share.firefox.dev/45ZpBR1
• nightly profiling shutdown permalink https://share.firefox.dev/3S3Dlad

Just to mention, the captured time length ("Aufzeichnungslänge") did not match with the observation with Processexplorer.
Processes where available in ProcessExplorer for multiple houres and the last two over night at next morging.

But profiling time length is given with following information:

• release 19m11s
• beta 1h15m
• dev 19m56s
• nightly 1h29m

Comment 31

[Robert Hartmann]

Are the profilings from comment 30 usefull for you?

Comment 32

[Dave Townsend [:mossop]]

The nightly profile shows us doing garbage collection for an hour which is pretty crazy.

Comment 33

[Robert Hartmann]

a next profiling idea:
If all Firefox installations (release, beta, dev, nighly) had been configured to do "automatic updates":

• is it possible to do a profiling for these automatic updateing jobs, which I think could start while system, in my case Windows, is (re)booting?
• Is it possible to force "restarting the background update check" without starting the program main window (see question in bug 1968551 https://bugzilla.mozilla.org/show_bug.cgi?id=1968551#c19 ), i.e. for profiling ?

Comment 34

[Dave Townsend [:mossop]]

That would be a question, and probably a bug for the update system

Comment 35

[Jon Coppeard (:jonco)]

(In reply to Dave Townsend [:mossop] from comment #32)

The nightly profile shows us doing garbage collection for an hour which is pretty crazy.

From the profile it looks like the process isn't being scheduled for most of that time.

Robert, how much RAM and page file do you have on your machine? Is there any anti-virus installed?

Comment 36

[Robert Hartmann]

(In reply to Jon Coppeard (:jonco) from comment #35)

(In reply to Dave Townsend [:mossop] from comment #32)

The nightly profile shows us doing garbage collection for an hour which is pretty crazy.

From the profile it looks like the process isn't being scheduled for most of that time.

Robert, how much RAM and page file do you have on your machine? Is there any anti-virus installed?

Well, on my private system (not updatable to Windows 11) on which I did the profiling:

Prozessor Intel(R) Celeron(R) CPU N3060 @ 1.60GHz 1.60 GHz
RAM 4,00 GB
Grafikkarte Intel(R) HD Graphics (114 MB)

File Explorer say (free disc space 217 GB):

pagefile.sys 4.718.592 KB
swapfile.sys 262.144 KB

cmd say:

C:\Users\ich\Desktop>wmic pagefile
AllocatedBaseSize  Caption          CurrentUsage  Description      InstallDate                Name             PeakUsage  Status  TempPageFile
4608               C:\pagefile.sys  420           C:\pagefile.sys  20171205070909.655960+060  C:\pagefile.sys  884                FALSE


C:\Users\ich\Desktop>wmic pagefileset get
Keine Instanzen verfügbar.



C:\Users\ich\Desktop>wmic os get TotalSwapSpaceSize, TotalVirtualMemorySize, TotalVisibleMemorySize, freespaceinpagingfiles, sizestoredinpagingfiles
FreeSpaceInPagingFiles  SizeStoredInPagingFiles  TotalSwapSpaceSize  TotalVirtualMemorySize  TotalVisibleMemorySize
4288232                 4718592                                      8734864                 4016272

Just as side note : Waiting for "program start up" I get used to. But from my point of view all programs which I use on my private system seems to work as soon as the UI inside the main window was loaded, i.e. LibreOffice currently in version 26.2 - which free up itself from memory after closing its window very fast.
But since some versions Firefox and Thunderbird like to freeze the main window ("task not reactive to windows messages") or after closing main window "take some time" for closing all their processes.

Comment 37

[Robert Hartmann]

(In reply to Jon Coppeard (:jonco) from comment #35)

[...] Is there any anti-virus installed?

MS Defender is installed : only the version which comes with Windows and gets updates via normal online updates.

Additionally installed is "Spybot - Search & Destroy" Free Edition (no real time protection active).

Comment 38

[Robert Hartmann]

As written in comment #36 my Windows 10 system has free disc space 217 GB.
Perhaps additional usefull information for your testings could be some more details about the disc.

    OS : Windows 10  [10.0 Build 19045] (x64)
  Date : 2026/09/01 21:42:15

-- Controller Map ----------------------------------------------------------
 + Standardmäßiger SATA AHCI- Controller [ATA]
   - hp DVDRW GUE1N
   - WDC WD10JPVX-60JC3T1
 - Microsoft-Controller für Speicherplätze [SCSI]
 + Virtual CloneDrive [SCSI]
   - ELBY CLONEDRIVE SCSI CdRom Device

-- Disk List ---------------------------------------------------------------
 (01) WDC WD10JPVX-60JC3T1 : 1000,2 GB [0/0/0, pd1]

----------------------------------------------------------------------------
 (01) WDC WD10JPVX-60JC3T1
----------------------------------------------------------------------------
           Model : WDC WD10JPVX-60JC3T1
        Firmware : 02.01A02
       Disk Size : 1000,2 GB (8,4/137,4/1000,2/1000,2)
     Buffer Size : 8192 KB
     Queue Depth : 32
    # of Sectors : 1953525168
   Rotation Rate : 5400 RPM
       Interface : Serial ATA
   Major Version : ACS-2
   Minor Version : ----
   Transfer Mode : SATA/600 | SATA/600
  Power On Hours : 8338 Std.
  Power On Count : 6758 mal
     Temperature : 36 C (96 F)
   Health Status : Gut
        Features : S.M.A.R.T., APM, NCQ
       APM Level : 0080h [ON]
       AAM Level : ----
    Drive Letter : C: D:

Comment 39

[Robert Hartmann]

• see also bug 69946 opened in year 2001 for SeaMonkey ( Mozilla Task doesn't end when closing window by posting WM_CLOSE from another app )
• see also bug 480220 opened in year 2009 for Core ( Infinite, intermittent WM_QUIT loop in nsAppShell )
• see also bug 1264036 opened in year 2016 for Firefox ( Ensure we can do a full flush of all windows during shutdown due to WM_ENDSESSION message from Windows )

Just an idea:
perhaps all child processes of main firefox process can get their own but hidden (invisible) window and a thread which handles the Windows message loop ?

Closing the main window should force that for rest of process livetime the process doesn't get downgraded to background priority.
If "changing to background priority" while having maximised Firefox main window in foreground can occure ( see bug 2069585 )
than perhaps this can also happen after main window has been cosed and isn't visible for user any more.
This could also be an explaination, why "From the profile it looks like the process isn't being scheduled for most of that time." (comment 35)

Comment 40

[Robert Hartmann]

Interesting discussion about low-memory detection : bug 1782178

Comment 41

[Robert Hartmann]

Since processes stay alive after closing the main window, it could be a pointer that the Window message loop is not doing every thing that should be done.

Therefor quoting my self from bug 1323007, which had been closed as RESOLVED WORKSFORME in year 2020:

There is a very old bugreport discussing information about
handling WM_QUERYENDSESSION & WM_ENDSESSION (and WM_CLOSE)
from year 1999 : Bug 14807

just to mention newer requirements for Windows Vista and above
see following linked documents.
From the last one can see that "pre Vista" and "after Vista" has differend
timing constraints to respect while handling WM_QUERYENDSESSION & WM_ENDSESSION.

• "Guidelines for Applications"
  ( https://msdn.microsoft.com/en-us/library/windows/desktop/aa373651(v=vs.85).aspx )
  Quote: Applications running on Windows Vista and Windows Server 2008
  should adhere to there guidelines to ensure that the Restart Manager
  can shut down and restart applications[...]

• "Application Shutdown Changes in Windows Vista"
  ( https://msdn.microsoft.com/en-us/library/ms700677(v=vs.85).aspx )
  Quote: [...] In Windows Vista, if your application must block shutdown, in addition to returning
  FALSE or not responding to WM_QUERYENDSESSION, it should leverage this new UI by using a simple API
  to provide Windows with a reason string explaining why it is blocking shutdown.
  This API is straightforward:
  BOOL ShutdownBlockReasonCreate(HWND hWnd, LPCWSTR pwszReason);
  BOOL ShutdownBlockReasonDestroy(HWND hWnd);
  BOOL ShutdownBlockReasonQuery(HWND hWnd, LPWSTR pwszBuff, DWORD *pcchBuff);

Because the ShutdownBlockReason-API is not available on older Windows I vote for using LoadLibrary + GetProcAddress for determine if these functions are available.

see also bug 1270666 (Revisit handling of WM_*ENDSESSION) opened in year 2016 and still open today.