2.79 fails to find Vray and falls back to the default of Blender Internal, and 2.80 falls back to the default of Eevee.

I don't think it's a bug that Blender fails to use the currently active renderer setting if the incoming one is invalid. One could make a case that it might be better to do so of course, but that would be more of an enhancement request (IMHO).

You can always Open it with the "Load UI" option unchecked, and it will come up with the default (usually Solid) viewport mode which ought to be sufficient to prevent overloading Eevee before you have a chance to change the render settings.

The issue with Eevee, from the point of view of large scenes, is that it might simply fail due to the scene complexity, and it's unfortunate that its failure crashes the whole of blender. Falling back to something that isn't intimately tied with the GPU (where resources might well be constrained) seems like a safer strategy.

But do you have a case where Blender is going to crash before you get a chance to simply switch it from Eevee to Cycles? Cycles vs. Eevee should only matter in 3dview Rendered mode (which AFAIK Blender will never have enabled when you load a .blend) or when performing an actual render.

The choice to use Eevee as the ultimate default here seems harmless to me.

I do, but the scene is too large to make a practical reproduction case for the bug tracker. I had complaints for 'too large to be useful' before, so don't want to make that mistake again. The UI is blocked as Eevee is attempting to compile shaders, and I have no way to abort either that process or to change the renderer. The viewport is configured to whatever the fallback is in this case; I'm not actively requesting a render or a render preview in the viewport, and as the UI is blocked, it's impossible to change anyway.

Loading without the UI makes a big difference, but it's not immediately clear that this is associated and could be easily overlooked, resulting in a bad user experience.

Is the file loading in LookDev mode, or what mode is it trying to display in that sends it down the Eevee shader compiling rabbit hole?

No idea - screenshot attached, in case useful. This is during the load; shortly after this, blender just exits silently to desktop

I have no problems, no errors or other things about Linux Blender 2.80-b63f0266a056 (2019-07-23) AMD FX8350, 16GB DDR3, GTX690 2 + 2 GB VRam- driver Nvidia 430.34, only one error for missing VRay engine

IMO an alternative solution to open the old very populated file is to disable the LoadUI option when opening the file, this makes Blender use the Shader Workbench engine instead of vray, instead of internal blender, instead of eevee

@dark999 (dark999) : the test scene attached is small and focussed purely on illustrating the fallback to Eevee rather than Cycles. You won't see any errors from it (or at least should not do). For my larger scenes that were built in 2.79 (often with side-by-side configuration for Cycles and V-ray), loading those set for V-ray will fall back to Eevee in 2.80 rather than Cycles, and Eevee can't handle the amount of data (it seems).

It would be better to fall back to Workbench or Cycles, or allow for the configuration of what to fall back to.

That overlooks the issue of Eevee crashing, though, which is my primary concern here and why I reported the issue. Silently crashing without any guidance to help the user seems like a bad thing. There's zero reason for the user to try 'load UI' when faced with a crash like this. Could the Eevee crash be caught and Workbench invoked as a basic level 'try not to die' mode?

I haven't even gotten as far as trying to render - this is purely about loading an existing scene, and in my production scenes there is a fully valid Cycles setup ready to go - it's just that the scene at load is looking for V-ray as the default render engine, and then jumps to Eevee without trying Cycles at all. Prompting that V-ray isn't available and asking for a render engine might be helpful, for example.

i tried to give you a trick to mitigate eevee's fallback for large scene

In T67594#733867, @dark999 (dark999) wrote:

disable the LoadUI option when opening the file

it work?

In T67594#734256, @dark999 (dark999) wrote:

i tried to give you a trick to mitigate eevee's fallback for large scene

In T67594#733867, @dark999 (dark999) wrote:

disable the LoadUI option when opening the file

it work?

That works, thanks. I thought I mentioned that already (https://developer.blender.org/T67594#733836). However, it's not terribly discoverable and the name doesn't really link it to the root cause (Eevee failing).

I think there are quite a few opportunities to improve Eevee's interaction and progress communication and I'm sure the 2.8x series will get there. For now, this issue seems like one that has workarounds that are acceptable for the 2.80 final release. But thanks for your report and your passion for making Blender better!