Don't know if it still has to get narrowed down to what causes it, but it still worked in:

even though changing render engine to cycles, back to eevee and then clicking material properties doesn't cause crash; viewport shading: material immediately does.

Thank you for looking ito this!
Of course I‘m glad to provide any information helpful to solve the issue.
You are able to reproduce the issue aren’t you?

But someone has to answer questions, provide logs and then later test if the issue is resolved or not. I assume that you are able to do it, so I picked up the details from there.

I can also confirm the crash.
The shader is e_data.postprocess_sh in eevee_renderpasses.c.

ACTUALLY, that was not the issue, ( as the render bug presisted ), instead, it was bandicam fps counter bugging the eevee final render out and stoping it for whatever reason, i turned off bandicam while rendering eevee, and it was fine!

I still can't reproduce the problem.
But by the image, there is really something strange there.

I just send Feedback Assistant.app to Apple https://developer.apple.com/

@Kent Davis (mac4kent) :

Model Name:	iMac
Model Identifier:	iMac18,3
Processor Name:	Quad-Core Intel Core i5
Processor Speed:	3.5 GHz
Number of Processors:	1
Total Number of Cores:	4
L2 Cache (per Core):	256 KB
L3 Cache:	6 MB
Memory:	16 GB
Boot ROM Version:	180.0.0.0.0
SMC Version (system):	2.41f2
Serial Number (system):	D25WC0D6J1GP
Hardware UUID:	E2E4C74A-7218-56CD-8FEA-7FBD6409C225

Oh it's fixed now? Cool! By the way I discovered today that the "sheen" value in the Principled BSDF also affects the result, this is probably not a bug but I still would like to know why. Could anyone expain that for me?

I have trouble shoot the problem i belive, after trial and error, from blender settings though internet searches, i finally went to nvidia panel, to the ''3D settings'' tab, there was '' use 3D application settings '', checked, i decided to un check it, then check it again and save the ''changes'', and now Eevee final render works fine...i will see if this is a permanent fix / and or a repetable fix if needed, but for now, it seems to have fixed the problem i had !

Cannot reproduce on Mojave 10.14.6.
Will not crash with Radeon Pro 560X on 2019 15" i9.
Used Version 2.83 (2.83 2020-02-27).

No, just a bug :-) Might also be the result of the color management changes, but will take a look at it.

It probably did not happen all the time, because the memory was zero initialized without RNA_enum_item_end.

Likely caused by rBSbe2bc97eba49
@Jeroen Bakker (jbakker), is this a Known Limitation?

@Dalai Felinto (dfelinto), investigating this right now. One moment.

Same situation. Blender not crashing on debug mode. But only on normal.
Here is a logs. But without crashes, in case they can be useful.

@Jacques Lucke (JacquesLucke) can you bisect it?

I can reproduce a crash on Windows 10 with AMD Radeon RX 5700 ATI Technologies Inc. 4.5.13572 Core Profile Context 19.11.3 26.20.13031.18002:

In T74227#881299, @Brecht Van Lommel (brecht) wrote:

Does running blender_debug_log.cmd crash?

Nope.

Does running blender_debug_log.cmd crash?

For me running blender_debug_gpu.cmd does not produce a crash. It does crash in regular mode.

Please:

• Mention operating system and exact Blender version tested.
• On Windows, run blender_debug_gpu.cmd, make Blender crash, then attach the resulting logs here.

Not fixed for 2/4x GTX1080ti

We received a laptop that allows us to replicate the issue. I will do some performance measurements to see what part of the drawing is causing this issue. Using the Debug value 22 the draw manager measures extreme performance issues in the Background part.

Still crashing here with a GTX 1050 TI, only when enabling Ambient Occlusion.

I could render the cube too, with the given file. System info:

The .blend is working fine on my PC, I've got a GTX 780 3Gb on linux...

I'm using old type of laptop that doesn't even have such Nvidia graphic. And I use blender 2.81
I tried different ways to solve this issue and deleting that file was solution for me and I thought this solution could help some others.

That opengl32.dll shouldn't have been there in the first place.
So it's not a fix.
Somehow it appeared there.