Thanks, but unfortunately that does not crash for me (using the GPlates 2.3 Windows public release build).
The fact that this happens without first having loaded any data is very unusual. Especially since I’m using the exact same GPlates build with the same dependency DLLs (in same directory as gplates.exe) and observing different behaviour.
It makes me wonder if a different dependency DLL (like qt5) is somehow being used, as mentioned in this post. For example, you may have previously loaded another application (since booting up your computer) that also uses the same qt5 DLL names, but the DLL versions are different, and then GPlates might then use those wrong-version DLLs (due to the statement mentioned in that post: “If a DLL with the same module name is already loaded in memory, the system uses the loaded DLL”).
One option to verify that might be to use DLL redirection. If you’re keen then you could give that a try. I’ve not tried it myself, but essentially it seems to amount to running the Registry Editor application, setting a new registry key, restarting your computer, creating an empty file called gplates.exe.local and placing it in the same directory as gplates.exe (probably easiest to do this with the beta.4 build you tried, so that you don’t need admin privileges).
At the moment I can’t really think of anything else (other than a DLL issue) that could cause this problem.