I investigated a reproducible Blender 3.6.23 crash on Windows 10 with Intel HD Graphics 4000 and driver 10.18.10.5161. I know this is legacy hardware below the requirements of current Blender releases, but the failure may still be useful because Blender crashes after a shader compile error instead of failing gracefully.
What fails
Blender reaches the 3D viewport, fails to compile the motion-path point shader, and then terminates with EXCEPTION_ACCESS_VIOLATION while accessing the unavailable shader interface.
The generated GLSL expression that fails is:
(flag & MOTIONPATH_VERT_KEY) != 0u
On this old Intel Windows GLSL compiler, MOTIONPATH_VERT_KEY appears to be treated as a Boolean in that expression. Blender’s --debug-gpu-force-workarounds option did not prevent the same failure.
Diagnostic experiment
For diagnosis only, I tested a separate copy of the executable with the embedded expression changed to the equivalent unsigned literal:
(flag & 2u) != 0u
The original executable was kept unchanged, and no modified Blender binary is being distributed.
With that one-expression change, the same Blender build remained responsive for more than seven minutes, loaded the actual user configuration and enabled add-on, returned the default scene through the local bridge, generated a real 1128 × 574 viewport capture, and produced no shader error or crash report.
Reports and evidence
- Official Blender issue: https://projects.blender.org/blender/blender/issues/161728
- Full investigation, hashes, and notes: https://github.com/giri256/blender-hd4000-crash-report
I am posting this mainly so the exact failure and workaround are searchable for anyone maintaining an older machine, and so others can confirm whether the same shader/compiler behavior appears on similar Ivy Bridge-era Intel hardware.