Hello DevGurus,
I'm facing the problem of windows driver crashes by executing only a few lines of OpenGL code.
All I have to do is to draw a line and a triangle meeting following conditions:
1. line stippling has to be enabled and set.
2. line width has to be greater than 1.
3. on drawing the triangle at least one of the edge flags has to be set to false.
Then the OpenGL application freezes and the windows driver crashes with the message: "Display driver stopped responding and has recovered."
Feel free to give it a try and put the following code snippet to your render loop function:
//------------------------------------------------------------
// 1. enable line stipple
glEnable(GL_LINE_STIPPLE);
glLineStipple(2, 0x1111);
// 2. increase width
glLineWidth(3.0f);
// 3. drawing the line
glBegin(GL_LINES);
glVertex3d(15.000000, -48.000999, 26.000000);
glVertex3d(-15.000000, -48.000999, 26.000000);
glEnd();
// 4. switching the polygon mode
glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);
// 5. drawing a triangle with edge flag
glBegin(GL_TRIANGLES);
glEdgeFlag(GL_TRUE);
glVertex3d(0, 0, 0);
glEdgeFlag(GL_FALSE);
glVertex3d(0, 50, 0);
glEdgeFlag(GL_TRUE);
glVertex3d(50, 50, 0);
glEnd();
// swap buffers, e.g.
glutSwapBuffers();
//-----------------------------------------
I was able to reproduce the crash on following systems:
AMD Radeon R7 200 Series
AMD FirePro W2100
AMD FirePro W4100
Catalyst Pro 15.301.2601
Crimson 16.6.2 and earlier
Windows 10 64 bit
Windows 7 64 bit
Any suggestions/ideas?
Thanks in advance
Solved! Go to Solution.
Supplement:
The issue was fixed in the latest drivers (Adrenalin 17.12.2 and Radeon Pro 17.Q4.1).
Thanks a lot for your help!
Thank you for your report. Can you share the project with us, so we can have a look at the source code?
We're unable to reproduce the issue. Can you try downloading the latest driver from Desktop and see if there's any improvement?
I'm surprized to hear that.
Of course the drivers I'm testing are always up-to-date.
But please consider that the driver problems occur not on every AMD chip set.
We've got crash reports on almost daily basis from our customers with (until today) only following graphics adapters:
FirePro W2100
FirePro W4100
Radeon R7 200 Series
Radeon HD 8240
Radeon HD 7800
I've retested the sample code I provided you and personally watched the following chip sets crashing a few minutes ago on following system:
Windows 10 Pro 64 bit
Radeon R7 200 Series with Crimson 16.7.2
and
FirePro W2100 with Catalyst Pro 15.301.2601
Please let your driver developers take another closer look at the problem. I'm sure they couldn't miss it on the hardware mentioned above.
Thank you in advance.
Hi mksrksh
Is the above image you tried to test?
And what's the compiler you use? I tried to compile but I need to change the order of header files to compile, I am using VS2013,
this is the header files I modify.
#include "stdafx.h"
#include <stdlib.h>
#include <stdio.h>
#include <gl/glut.h>
#include <string.h>
Thanks!
Hello pierretsai,
Thank you for prompt reply.
Well, that's exactly the test image I'm trying to reproduce.
Unfortunately It is not possible for me on particular amd chip sets.
What system configuration did you use for producing that image?
I'm also using VS2013. Your header files order modification compiles fine.
I commented out the include of atdafx.h since I'm not using precompiled headers.
Driver still crashes.
[Note]
In case you are testing on a laptop, please make sure the amd graphics adapter is involved in rendering the test application and not the on-board integrated chip set (e.g. intel graphics).
[Supplement]
I've just received a call from a customer complaining driver crashes on:
Radeon HD 7700
Hi mksrksh,
Sorry about that, I have used HD7700 and R7 200, win 10 to test it and it work fine here.
Can you do me a favor, find the PlaysTV and Raptr, and uninstall them, sometimes it can
solve some weird bugs, thanks!
Hi pierretsai,
the issues with PlaysTV and Raptr are well known to us and thus we don't install them at all.
Thanks for your help so far.
There must be something I overlook.
Would you mind sharing your project with me so we'd be able to analyze the same code basis with the same compiler settings?
Thanks.
Hi pierretsai,
I suppose you are using the original GLUT library. With this library your project does not crash on our test machines either.
Would you mind linking your project to freeglut (freeglut.sourceforge.net)? I have used the version 2.8.1 since it has visual studio projects and thus you'll be able to build the binaries quickly.
With freeglut library linked, your project produces crashes on my machine.
You might say, it is a freeglut problem. But there might be something more, e.g. a slightly different opengl initalization process only you as driver developer are able to see.
By the way our products do not use neither glut nor freeglut at all and produce crashes. So I suppose our opengl initialization process is more like the one in freeglut and not like the one in glut.
Thanks
[Supplement]
Hi pierretsai,
I did a little research on opengl contexts created by glut and freeglut using your visual studio project to examine the differences and to find explanations for the different behaviours.
By using freeglut I get a higher number for pixel format (freeglut = 119, glut = 8).
But I think the crucial difference is the number of samples used for multisampling (freeglut = 4 and glut = 0!).
I tried to force glut to create an opengl context with the same properties like the ones created by freeglut. For this purpose I tried calling glutInitDisplayString with different combinations of parameters, e.g. "samples~4" and "win32pfd=119". Unfortionatly glut didn't let me do that complaining: "pixel format with necessary capabilities not found".
So I suppose, if you manage to force glut to create a real multisampled context with numer of samples greater than 0, you'll be able to reproduce the driver crashes too.
But I still think the fastest way is to link your project to freeglut...
Hi pierretsai,
have you been able to take a closer look at the issue as you intended?
Are there some new insights you would like to share with us?
Thank you for your efforts
Hi mksrksh,
Sorry for late reply, do you link your project by freeglut? I found a work around right now, if you can add
opengl32.lib
glut32.lib
glu32.lib
to the linker-> input, this bug will be disappear. I need to take more time to figure out what happen, let me know whether
it is work for you, thanks!
Hi pierretsai,
thank you for your reply.
Well, in deed, as I mentioned earlier glut does not produce the crashes in contrast to freeglut.
That's the reason why I asked you to link your test project to freeglut so you can reproduce the crash.
The workaround you suggest is not an option for us since we do not use neither glut nor freeglut in our products at all. I used freeglut only in the test project to demonstrate the issue by means of a minimal example without bothering about window creation and pixel format choosing.
I still suppose there is a bug in the current Crimson driver as well as in the current Catalyst Pro driver.
Since you are already able to definitely reproduce the crash I kindly ask you to take a deeper look at the reason for it.
Of course all of the DevGurus are welcome to do it either 😉
Please keep me informed about your progress - I need a statement for our customers owning amd graphics adapters.
Thank you and best regards
Supplement:
The issue was fixed in the latest drivers (Adrenalin 17.12.2 and Radeon Pro 17.Q4.1).
Thanks a lot for your help!