As I've had a couple of question on this, mainly due to the new LUT Generation capability up to 256^3 and beyond, it's probably worth defining what's happening with 'silent' crashes..

When the PC running ColourSpace runs out of resources, the PC itself will cause ColourSpace to crash.
As the crash is outside of ColourSpace, the crash will be 'silent', without any error message generated.

Trying to 'catch' such crashes within ColourSpace (or any other software for that matter) is extremely difficult...

However, we are, and have always been, working on a solution.
Presently ColourSpace is a 32bit program.
It has always been designed to be 64bit.
And with 64bit programs the accessible PC resources are far greater, and will greatly reduce such silent crashing.

And no, we are not providing any timescales on this - we never provide timescales on ongoing development work.

Steve

This is what a lot of us have seen in ColourSpace when we push big LUTs. When you reach 256³ (or stacking ops), you're basically at the top of the 32-bit address space, and the OS just shuts down. The app can't report anything because it never gets control back.

For now, the only real fixes are practical ones: close anything that uses a lot of memory, don't run multiple LUT jobs at the same time, and don't expect miracles from machines with limited RAM, even if it "should" be enough. The explanation about 64-bit makes perfect sense, and I appreciate the openness. Silent crashes are bad, but this isn't a mystery bug; it's just physics.

A compromise exists which might be worth testing, increasing the limit from 2 to 4 GB, while keeping the app 32-bit.

https://learn.microsoft.com/en-us/cpp/build/reference/largeaddressaware-handle-large-addresses?view=msvc-170

That will not work.
There are too many external dependencies due to the 3rd party hardware integration.

Steve