This issue may have been fixed in recent commits to master. Are you able to test with the latest Blender 2.90.0 build? http://builder.blender.org/

In T77346#947448, @Alaska (Alaska) wrote:

This issue may have been fixed in recent commits to master. Are you able to test with the latest Blender 2.90.0 build? http://builder.blender.org/

Today I checked using latest build but still the problem remains. My drivers are up to date. last week it was fine but suddenly this problem popped up.
I have checked changing color in grease pencil and there it works fine.

In T77346#944287, @Alaska (Alaska) wrote:

The recent builds of 2.90.0 have been quite unstable based on my personal experience. However, I'm unable to reproduce this issue on Linux with a GTX 1050Ti.

I was able to reproduce this on a computer I was using earlier today with Intel UHD Graphics 630 on Windows 10. But I won't have access to this computer for another 20 or so hours, so I can't confirm this case.

Are you able to try to things:

1. Make sure your Intel GPU drivers are up to date.
2. Are you able to navigate to the Blender installation directory and run it with the file blender_debug_log.cmd then get Blender to crash. A file explorer should open with two text files, upload those two files to here.

here attached debug logs.

In T77346#951942, @Germano Cavalcante (mano-wii) wrote:

@pattamp, you forgot to include information about a version of Blender that works.
Did you try 2.83 or 2.82?

yes I have used 2.83 and its working fine without any issue.

@pattamp Could you re-trigger bug and upload crash.txt file mentioned at the end of blender_debug_output.txt?

Should be C:\Users\xx\AppData\Local\Temp\blender.crash.txt in your case.

My drivers are up to date.

https://downloadcenter.intel.com/download/29616/Intel-Graphics-Windows-10-DCH-Drivers?product=126789
This page says that latest drivers are 27.x, not 23.x

In T77346#964197, @Ankit Meel (ankitm) wrote:

My drivers are up to date.

https://downloadcenter.intel.com/download/29616/Intel-Graphics-Windows-10-DCH-Drivers?product=126789
This page says that latest drivers are 27.x, not 23.x

I have tried installing this version 27.x but it is not validated for my system

my current driver version is updated to

attached crash report

In T77346#964197, @Ankit Meel (ankitm) wrote:

My drivers are up to date.

https://downloadcenter.intel.com/download/29616/Intel-Graphics-Windows-10-DCH-Drivers?product=126789
This page says that latest drivers are 27.x, not 23.x

BTW earlier attached blender_system_info.txt file already shows ver 26.x for driver.
Ver 23 was when i first noticed the crash, later updated the driver to ver 26 and still had the crash.

In T77346#964197, @Ankit Meel (ankitm) wrote:

My drivers are up to date.

https://downloadcenter.intel.com/download/29616/Intel-Graphics-Windows-10-DCH-Drivers?product=126789
This page says that latest drivers are 27.x, not 23.x

For Intel drivers on Windows, only pay attention to the last 4 digits.

https://www.intel.com/content/www/us/en/support/articles/000005654/graphics.html

I was able to reproduce this one. Strange enough you don't need to have EEVEE active.

I confirm on mac (macbook pro 13 "2019) I am using version 2.83.1 and it is truly a disaster, the 2.82 was much better in terms of stability. The program crashes even in the transition from solid mode to material preview. times I don't understand why they are much longer and even in the transition from uv editing to shading the program crashes. Obviously I'm talking about light files that normally in my pc have never given problems.

blender.exe         :0x00007FF6C83E1880  bli_windows_system_backtrace_stack_thread C:\blender-git\blender\source\blender\blenlib\intern\system_win32.c:233
blender.exe         :0x00007FF6C83E0900  BLI_windows_system_backtrace_stack C:\blender-git\blender\source\blender\blenlib\intern\system_win32.c:320
blender.exe         :0x00007FF6C83E02B0  BLI_system_backtrace C:\blender-git\blender\source\blender\blenlib\intern\system_win32.c:383
blender.exe         :0x00007FF6C720E0A0  EEVEE_material_get C:\blender-git\blender\source\blender\draw\engines\eevee\eevee_shaders.c:761
blender.exe         :0x00007FF6C71D4F70  EEVEE_lightprobes_cache_init C:\blender-git\blender\source\blender\draw\engines\eevee\eevee_lightprobes.c:341
blender.exe         :0x00007FF6C71E4990  EEVEE_render_cache_init C:\blender-git\blender\source\blender\draw\engines\eevee\eevee_render.c:180
blender.exe         :0x00007FF6C71BA370  eevee_render_to_image C:\blender-git\blender\source\blender\draw\engines\eevee\eevee_engine.c:521
blender.exe         :0x00007FF6C7150EA0  DRW_render_to_image C:\blender-git\blender\source\blender\draw\intern\draw_manager.c:1827
blender.exe         :0x00007FF6C8263BE0  RE_engine_render C:\blender-git\blender\source\blender\render\intern\source\external_engine.c:880
blender.exe         :0x00007FF6C8279010  do_render_3d C:\blender-git\blender\source\blender\render\intern\source\pipeline.c:1138
blender.exe         :0x00007FF6C8273830  RE_PreviewRender C:\blender-git\blender\source\blender\render\intern\source\pipeline.c:2687
blender.exe         :0x00007FF6C818FF20  shader_preview_render C:\blender-git\blender\source\blender\editors\render\render_preview.c:911
blender.exe         :0x00007FF6C81904B0  shader_preview_startjob C:\blender-git\blender\source\blender\editors\render\render_preview.c:949
blender.exe         :0x00007FF6C818D7F0  icon_preview_startjob C:\blender-git\blender\source\blender\editors\render\render_preview.c:1169
blender.exe         :0x00007FF6C818C640  common_preview_startjob C:\blender-git\blender\source\blender\editors\render\render_preview.c:1188
blender.exe         :0x00007FF6C818DDB0  icon_preview_startjob_all_sizes C:\blender-git\blender\source\blender\editors\render\render_preview.c:1274
blender.exe         :0x00007FF6C697CE80  do_job_thread C:\blender-git\blender\source\blender\windowmanager\intern\wm_jobs.c:398
blender.exe         :0x00007FF6C83E40B0  tslot_thread_start C:\blender-git\blender\source\blender\blenlib\intern\threads.c:222
blender.exe         :0x00007FF6C86CF120  _ptw32_threadStart
ucrtbased.dll       :0x00007FF8A8F95340  register_onexit_function
KERNEL32.DLL        :0x00007FF8C8074020  BaseThreadInitThunk
ntdll.dll           :0x00007FF8CA2A3670  RtlUserThreadStart

During the rendering of the material preview it crashes. The GLSL shader must be in compiled state, but is in queued state.

Issue is related to a work around that we added for this specific configuration. GG.context_local_shaders_workaround. The work around would always use the main thread for loading shaders. When doing preview renders the compilation happens in the caller thread, but is stored in a binary. This binary is loaded as a shader when the caller is part of the main thread.

Due to recent refactorings it is assumed that the caller always returns a valid shader so its interface can be introspected, what isn't the case.

I tested by disabling the workaround and it seems to be working (perhaps it got fixed in the driver in the mean time). But as the work around is also activated for other IGPUs on Windows it is hard to say that all platforms are currently working.

Regression introduced by {b18c2a3c413b7741b2a854b7bd25721352be2589}

@Clément Foucault (fclem): any advice how to fix this? Issue is that the shaders are needed for the interface, but the shader is stored in binary form. and the default shader is loaded, which also is loaded in binary form. Issue can be reproduced by

diff --git a/source/blender/gpu/intern/gpu_extensions.c b/source/blender/gpu/intern/gpu_extensions.c
index 335dabdcb01..8948aef20e3 100644
--- a/source/blender/gpu/intern/gpu_extensions.c
+++ b/source/blender/gpu/intern/gpu_extensions.c
@@ -224,7 +224,7 @@ bool GPU_unused_fb_slot_workaround(void)
 
 bool GPU_context_local_shaders_workaround(void)
 {
-  return GG.context_local_shaders_workaround;
+  return true;  // GG.context_local_shaders_workaround;
 }
 
 bool GPU_texture_copy_workaround(void)

We could change that workarround to simply compile the shaders in single thread.
Even in multithreaded, the interface remains locked during the compilation of shaders on these GPUs and it is possible that internally the driver already compiles in multithreaded.

Can this be somehow related with issues in T77944 ?
In my case Blender 2.9 also crashes.

@Jeroen Bakker (jbakker) I'm ok with removing this workaround only for intel HD6xx.

diff --git a/source/blender/gpu/intern/gpu_extensions.c b/source/blender/gpu/intern/gpu_extensions.c
index ab55fcfb1e0..2a9e9072d2a 100644
--- a/source/blender/gpu/intern/gpu_extensions.c
+++ b/source/blender/gpu/intern/gpu_extensions.c
@@ -326,7 +326,6 @@ void gpu_extensions_init(void)
     GG.depth_blitting_workaround = true;
     GG.unused_fb_slot_workaround = true;
     GG.texture_copy_workaround = true;
-    GG.context_local_shaders_workaround = GLEW_ARB_get_program_binary;
   }
 
   /* Special fix for theses specific GPUs.
@@ -334,7 +333,6 @@ void gpu_extensions_init(void)
   if (GPU_type_matches(GPU_DEVICE_INTEL, GPU_OS_WIN, GPU_DRIVER_OFFICIAL) &&
       (strstr(renderer, "HD Graphics 620") || strstr(renderer, "HD Graphics 630"))) {
     GG.mip_render_workaround = true;
-    GG.context_local_shaders_workaround = GLEW_ARB_get_program_binary;
   }
 
   /* df/dy calculation factors, those are dependent on driver */

Any objection?

@Clément Foucault (fclem). we can remove it from 620/630, and temporarily remove it from the --gpu-enable-workarounds but still we need to fix the workaround for the other iGPUs.

What a good solution, actually there are many of us who did not try the experience of version 2.90.0 again because of the fact that the application closes immediately when we do the steps mentioned above, all of you are making a very big effort and I congratulate you everyone at heart, I never regret having Blender. God bless you all.

Hello! I wanted to tell you that I am Juan Binafa (Binafa) and change the user Mubinafa, the fact is that I follow this thread, and I wanted to tell you that in this version "blender-2.90.0-afcb41a0aaaf-windows64" with graphics card "Intel (R) HD Graphics 620 updated "is working well on" fails to modify the properties of the material ", both in" EEVEE "which was where the problem occurred when starting the default application, until now this Alpha version" blender-2.90.0- afcb41a0aaaf-windows64 "works super well for problem" fails to modify material properties ". Thank you very much and it makes me very happy because you are working hard and you listen to us all when we see a problem in the software. Blessings.