Sorry my friend. If you're computer freezes up, it's beyond my paygrade. What it means is that the game is asking your computer do do something, and when trying to do that something breaks. So it's a system bug, caused by the game code touching it, which not many other applications might do in a similar way, and I have absolutely no idea what it could be. My guess would be java. I ship the game with java, but it's an old version. Since you're on windows, you probably have some java version installed. What you can try is navigating to the installation directory and double click the .jar file (not the .exe) and the game will launch with your java if you have one. I'm 99% this will fix it for you. But you will not be able to launch the game through gog.

Chances are that some update or restart of your PC will fix it as well.

Thanks for the reply and the tips Jake, much appreciated.

Yes I had Java already (reinstalled it as well a couple of times), but that didn't help much.
Tried to remove Java entirely as well in the recent tries - in case it 'clashes' somehow with your built-in shipped version, but had the same result after trying to run via the .exe (and .jre did not work obviously without having a separate Java on).
There were even weird occasions where I installed the game then got the hard crash after trying to run it, and then my system did not even register the game being installed after reboot (even though the installation was successful previously, and the files were still in their directories), so to even be able to reinstall I had to clean up manually first.
This also happened to the Java RTE itself after I tried to run the game via the .jar - my system seemingly forgot the Java RTE is even installed after reboot, so had to manually clean up and reinstall that as well.

Anyway, there was one occasion on this trial session where I actually managed to run the game via the .jar somehow, but there was a lot of screentearing - vsync off I presumed, so I exited and ran the launcher to turn vsync on... after which I got the hard crash again (even after turning vsync back off via the launcher).

So as I did not manage to get enough consistency so far with the crashings, I'm giving up trying for now.
I may come back to it when a later version is out, or when/if I decide to refresh my system.

If something happens to came to mind to try meanwhile, any tips are still appreciated.
Thanks again and good luck with the further development - oh and grats for the Sseth sale boost. :)

Checking in to indicate that I managed to somewhat consistently run the game through the jar file - so via the 'external' java on my system.
I still don't know what the winner combination of environment was exactly - and this is kind of just a workaround anyway - so I'm hesitant to mark the case 'solved' yet.

One downside of running the game this way is that via the .jar run the game doesn't seem to bother about the settings set by the launcher - I was editing the settings file manually anyway, as the launcher is prone to fail -, so I had to figure out how to enable vsync without that, as it's not an option to set from within the game. Luckily it seems to work if it's forced down globally via the NVIDIA settings app.

All in all, thanks again for the tip about the java try, I'll keep an eye out for further updates.

Thought I'd 'finish' my experimentation log, as I narrowed down the case to a predictable stable run pattern.

I have Comodo firewall running on my system. The game is allowed through it and I've even experimented with turning it off, but it does not seem to affect the pattern of successes/crashes.
It does however offer the option of running an app/program in 'container mode' - kinda virtualized/separated from the main system resources to a customizable extent.
When I do that, a rather interesting thing happens: seemingly nothing first, but cheking the processes, the Java RTE launches and eats a sizeable amount of resources (¬10% of CPU) and does something for about 5 minutes, when the launcher actually appears. After that when launching the actual game from the launcher, about another 7 minutes passes with the Java RTE seemingly just chilling in the background, but finally the game launches. All through I'm able to do anything else, no hard freeze this way. After the game launches, it runs without problem, previous saves work.
If I attempt a run without this contained mode, there's a 90+% chance for a hard freeze/crash needing reboot (that's the topic of the thread), the rest ¬10% cases are successful runs where the game launches in a matter of seconds.

So in conclusion I suspect the Java RTE is trying to do - poke as you've put it :) - something in a way that it shouldn't and it messes up my system hard, but in the contained mode it probably cannot mangle things up so it just tries (?) for a while after which it actually ends up running the game correctly.
Since the beginning of my experimentation I've reinstalled the Java RTE many times, so I'm at a loss to further details for root causes, maybe a specific thing to my current setup.

I'm new to the game, don't have big cities yet, so I don't know how this containered virtualization will affect the performance in the long run, but at least it is down to something consistent.

All in all a bit strange. Anyway, in case someone has the same/similar problem, this method may be attempted.

@Yargol

I also use Comodo Firewall (which is actually MUCH more than just a firewall - for anyone else interested).

Depending on what mode you use, it can be incredibly fussy about what it allows / disallows to run. Sometimes it will crash the PC, as a pop-up prompting for an allow/disallow is prevented by the game window itself ALSO trying to work at the same time. Major conflict. Freeze! :) Yes, hard reset required. (However, you can also wait 5-10 minutes, and Windows sorta recovers itself again.) ;)

Personally, I use 'Custom Ruleset', which gives you enormous control over what you want to allow / disallow.

Please check the following:

In the sytem tray, right click on the Comodo icon. Choose Firewall -> Settings. Also check that 'Advanced View' is set too.

Look at File Rating -> File List.

On the far right you'll see a long list of either, Trusted, Unrecognised, Malicious files. Click on the 'Rating' header of that column to sort (bound to be much less unrecognised or malicious files than trusted).

See if there's any 'Unrecognised' or 'Malicious' entries for any of the Songs of Syx or Java files. If there are, just click where it says Unrecognised or Malicious and change it to Trusted!

You can also search using the magnifying glass icon for either a name like 'Syx' or a path where the files are installed.

You can also click on 'Purge' to free up a ton of uninstalled / deleted files that are not affecting anything to make the list considerably shorter if you've never done it or not done it for a while.

Most important!!! Don't just close the window with the X button. You MUST click OK, for the changes to take effect.

Hope this might help a bit?

Thanks for the tips Chrome, I appreciate the helping intent.

I have checked the rulesets as you mentioned, but everything Songs of Syx related was 'Trusted' already.
As I mentioned above, I did manage to run the game a few times the 'normal' way - without the Comodo container - which means that at those times (the first time to be precise) I managed to click through all the Comodo firewall notifications asking for allowing various parts of the game through, without hard crash, and those settings were saved and remembered ever since.

The situation remains a mystery for a while longer I guess - at least I can play the game through the container, even if it's a bit of a hassle.

I did do a big purge though for all the hundreds of obsolete entries in the Comodo ruleset while I was there, so thanks for that hint anyway. :)

Thanks again for the further advice.
There were a couple of files marked as 'Unrecognised', but those were unrelated to both Songs of Syx and Java.
Yes, I always mark the 'Remember' checkbox when I allow stuff through the FW, as it's not nice to go over all that every run for something I trust. :)

I think you've also touched on the solution anyway with your comments on HIPS and heuristics FS being too aggressive, as after your last comment, I have looked at HIPS and the Script Analysis parts of Comodo. HIPS on or off seems to have no effect on my crash, but turning off the Script Analysis (under "Advanced Protection") completely seems to have solved it, as the game launches consistently after that, and crashes consistently every time I turn it back on.

So it was indeed Java and Comodo clashing after all.

This was quite the nice learning experience on top of a solved problem, so thanks again. :)

You're welcome. :)

Glad we got there in the end..