I have a similar problem. It’s with Glut, but I think the may be related. My system es an Athlon 600 width Diamond Viper II. Sometimes after recompiling (VC++) my application throws an exception, or doesn’t redraw the OpenGL window. What i do is to change the resolution of the screen (sometimes a couple of times). It seems to reset some internal values, because after doing it the app works ok.
I have ScottManDeath’s problem, on an Athlon, GeForce 2MX, Win ME(Aaaargh). Any OpenGL app I’ve written will fail on ChoosePixelFormat the second time its run, unless UT was run previously. The ChoosePixelFormat call just seems to completely freeze the system, so I have to hit the reset switch, Ctrl-Alt-Del doesn’t even work.
I am seeing the exact same problem that kliston describes on WinNT4SP5 with both ATI FireGL 8800 and nVIDIA Quadro4 XGL/900. I see wglCreateContext() return a NULL HGLRC and give one of the two windows errors: “Operation succeeded” or “Entry point not found”. I am certain that the PFD has been chosen correctly; indeed I can manually go through all the pixel formats on both cards and all of the accelerated ones fail in exactly the same manner. Unaccelerated PFD work, although at software rendering speed.
The conditions for bringing this failure about are as yet unknown, and not simple. A simple application succeeds fine, whereas a more complex application does not, even though both get the very same PFD.
Did anyone here ever come up with a satisfactory explanation of this problem, or even some hard facts surrounding it?
One quick note, which might be helpful, but probably isn’t. One of the first bugs I looked at after starting to work at NVIDIA involved one of our GeForce3 demos crashing on exit on Win98, after which all OpenGL programs would crash 100% of the time.
This turned out to be a bug in the DX8.0 DirectSound implementation – our DirectDraw driver was being unloaded incorrectly by DDHELP.EXE when it was cleaning up sound buffer resources. But the rest of the run-time didn’t get the word, so it called our entry points at their old addresses thinking the DLL was still loaded. No crash in DX7.0. I think it might be fixed with DX8.1, but I’m not sure. Explicitly freeing the DirectSound buffers on exit eliminated this problem (though that won’t help you if you crash for other reasons).