The x86 (32-bit) version crashes when resource usage (RAM, CPU, etc.) is high

[tanquang]

I checked the chrome.exe file of the x86 (32-bit) CentBrowser version using the "dumpbin" command and found that the "LARGEADDRESSAWARE" flag was enabled. However:

- When opening a heavy website (like Facebook), which uses only about 1.5 GB of memory, it immediately crashes with an "Error code: Out of Memory" error.

- When the CPU usage of the Dev Tools tab is high (~100%), after a few seconds, it crashes as shown in the attached image below.

As can be seen, it encountered an error very early on, even though it was still far from the limit of a typical 32-bit process. The "LARGEADDRESSAWARE" flag therefore did not function.

[S8F8ry]

Is your system 32-bit or 64-bit? If it is a 32-bit system, /LARGEADDRESSAWARE does not work directly, you need to use BCDEdit to set the increaseuserva option, see: Memory Related Settings. If it is a 64-bit system, it may have encountered a very bad situation in which one of the libraries used by the program expected a low memory address (below 0x8000000) and actually allocated a higher memory address, causing it to think this is a serious exception.

[tanquang]

Is your system 32-bit or 64-bit? If it is a 32-bit system, /LARGEADDRESSAWARE does not work directly, you need to use BCDEdit to set the increaseuserva option, see: Memory Related Settings. If it is a 64-bit system, it may have encountered a very bad situation in which one of the libraries used by the program expected a low memory address (below 0x8000000) and actually allocated a higher memory address, causing it to think this is a serious exception.

My operating system is 64-bit, CentBrowser is x86 (32-bit). The /LARGEADDRESSAWARE flag that I checked and found to be enabled is also in the chrome.exe file of the x86 (32-bit) version of CentBrowser.

As you said, this issue stems from CentBrowser (and related libraries) incorrectly handling memory addresses starting from 0x80000000 (due to using a signed int data type instead of an unsigned int). Will this be fixed in the next update?