[gsvelto]

Could you open a bug on our tracker, and point to those crash reports? I'm very interested in analyzing real-world scenarios where this happens to figure out where those committed areas are coming from. Our best guess is that they come from the graphics stack because we account all the memory we commit in Firefox and there's nothing missing, so wherever this is coming from it's outside of our direct control.

[LoganDark]

I actually did open up about:memory a few hours ago and now, and it looks like some growth is coming from "heap-unclassified" in the main process.

As for opening a bug on your tracker, meh but I can give you a list of report IDs:

    bp-e6392a4b-44e8-4013-a80e-1027b0221109  
    bp-dae0a056-3c6a-43ea-ad3f-5fe1a0221006  
    bp-0be1e0f7-0eca-4744-a05c-ce2030220927  
    bp-65c63eea-fb45-419d-a58a-82ef20220915  
    bp-061b6131-5ae3-4de1-a7ba-0c4950220830  
    bp-32f879a0-f76f-4a5b-bef9-f013f0220820

[gsvelto]

From the looks of it you have a minuscule page file (16MiB), that's why you're running out of commit space. I suggest setting it to auto-resize (the Windows default) which should provide a much better experience even with other applications, unless you need to keep it small because of storage concerns. Generally speaking Windows behaves very poorly with small swap files because of its inability to overcommit memory.