topic OpenGL access violation bug in ig75icd32.dll in Graphics

OpenGL access violation bug in ig75icd32.dll

Bond__Simon — Tue, 21 Mar 2017 15:55:28 GMT

System Setup Information:
-----------------------------------------

System Used: Samsung/940X3G
CPU SKU: i7-4500U
GPU SKU: HD4400
Processor Line: -
System BIOS Version: P05ACJ.128.140819.dg
CMOS settings:-
Graphics Driver Version: 20.19.15.4549
GOP/VBIOS Version:-
Operating System: Windows
OS Version: 10
API: opengl
Occurs on non-Intel GPUs?: No

Steps to Reproduce:
-------------------------------

Using driver version 20.19.15.4549 (10/11/2016) or probably any driver since about 2016. The issue does not occur in a very old driver version 10.18.15.4248 (29/06/2015.) Although opengl performance with that old driver is abysmal/unusable.
Install the free akeytsu demo from nukeygara.com which uses OpenGL for its user interface rendering.
Hover your cursor over the UI's minimise/maximise icons, or move input focus elsewhere in the Windows OS and back in again to invoke a redraw of the application.
Intermittent crashes will occur with stack traces similar to the following (Nvidia/AMD have no such problem):

> ig75icd32.dll!053649cc() Unknown
  [Frames below may be incorrect and/or missing, no symbols loaded for ig75icd32.dll]
  ig75icd32.dll!0535e5cb() Unknown
  ig75icd32.dll!052836ce() Unknown
  ig75icd32.dll!05286378() Unknown
  ig75icd32.dll!05292f9d() Unknown
  ig75icd32.dll!05292ca3() Unknown
  ig75icd32.dll!051d052b() Unknown
  mfc140u.dll!01bc828f() Unknown
  mfc140u.dll!01c54f2f() Unknown
  akeytsu.exe!011215ca() Unknown
  mfc140u.dll!01c54f2f() Unknown
  mfc140u.dll!01bc7f54() Unknown
  user32.dll!7635d2b3() Unknown
  user32.dll!7633e88a() Unknown
  user32.dll!7633df17() Unknown
  user32.dll!7635d2b3() Unknown
  user32.dll!7633e88a() Unknown
  user32.dll!7633e1e4() Unknown
  user32.dll!7633dfa0() Unknown
  akeytsu.exe!0100665a() Unknown
  ucrtbase.dll!7664f65c() Unknown
  ucrtbase.dll!766ab756() Unknown
  mfc140u.dll!01c56656() Unknown
  akeytsu.exe!01141ea8() Unknown
  kernel32.dll!76de62c4() Unknown
  ntdll.dll!76fe0fd9() Unknown
  ntdll.dll!76fe0fa4() Unknown

Expected Results:
-------------------------------
No crash.

Actual Results:
-------------------------------
Crash.

Additional Information:
-------------------------------
Numerous repro crash mini dumps are attached. Since akeytsu collects dumps internally they will not be appearing on your WER dashboard.

Hi Simon,

Michael_C_Intel2 — Tue, 21 Mar 2017 16:29:33 GMT

Hi Simon,

I'm afraid no further driver releases are planned for the 15.36 and 15.40 branches that support the HD 4xxx products. If the issue is seen on newer products then we can investigate.

-Michael

Hi Mickael,

Cédric_V_1 — Wed, 22 Mar 2017 08:13:12 GMT

Hi Mickael,

I am Cedric, from Nukeygara, the company developing akeytsu (the 3D animation software Simon is speaking about).

I confirm that we have problems running akeytsu with Intel integrated cards, depending upon the installed driver.

I would be really interested to work with your team to understand/fix this kind of problems.

Who must I contact ?

Regards,

Cedric

[And thank you Simon, to try solving such problems!]

@Michael - FYI, whatever you

Bond__Simon — Wed, 22 Mar 2017 13:14:12 GMT

@Michael - FYI, whatever you're doing in your Atom chip (ig7icd32.dll) does not have this same bug as its desktop ig75icd32.dll equivalent. It would be really great if one of your guys could fire up the minidump in Visual Studio with the necessary .pdb so Cedric can at least get a rough clue as to an underlying cause. Even if they would just copy & paste the resolved symbol function names for each stack trace, that could go a long way.

@Cedric - I'm wondering if this all boils down to a different resource management/upload strategy in the driver. Can you see if perhaps a texture or vertex buffer is being released immediately after opengl calls? i.e. double check all cleanup/release operations are happening after the opengl backbuffer is presented to screen? I'm wholly unfamiliar with the opengl framework having only really ever used direct3d, so am not sure opengl even has a "Present" call equivalent. If GPU upload happens to take place asynchronously in the driver, some kind of flush or resource synchronisation barrier might be needed.