Nvidia driver crash at draw call

[sharethis]

Recently I changed my video card from ATI HD 7870 to NVIDIA GTX 660. From this moment on the OpenGL 3.3 application I am developing crashes at the draw call "glDrawElements" with the following error.

Unhandled exception at 0x5D9F74E3 (nvoglv32.dll) in Application.exe: 0xC0000005: Access violation reading location 0x00000000.

I already rewrote the renderer and ensured that there are no invalid pointers which could lead to an access violation. There are no OpenGL errors at runtime and no warnings from my Visual Studio 11 compiler running under Windows 8 64. Also I tried different old driver versions but since that didn't make things better, I installed the latest stable one again.

It is unlikely that there is a driver bug but my C++ shouldn't crash the driver, should it? Is there a known issue, could it be a hardware defect or do you need source code to find the reason for the crash?

[Dark Photon]

...Access violation reading location 0x00000000.

Looks like a null pointer dereference to me.

Often what this means is that you have provided a bogus client array pointer for a vertex attribute or the index list.

You'd expect to see this if you are "trying" to render with VBOs, but you don't happen to have a VBO bound to the GL_ARRAY_BUFFER when you register a vertex attribute or don't have a VBO bound to the GL_ELEMENT_ARRAY_BUFFER when you issue the draw call. Reason is you'd often provide a "NULL pointer" in this case to indicate 0 offset into the bound VBO.

But if a VBO isn't bound properly, it just ends up being a NULL CPU pointer which you'd expect to generate the above error.

my C++ shouldn't crash the driver

Errant pointers passed into the driver can easily crash the driver. This isn't Python or even PASCAL where there are "guard rails" to avoid the programmer shooting themselves in the foot. You get the benefit of higher potential performance, but you do have to be careful.

It is possible it's a driver bug, but given my experience with their driver stability, I'd wager that to be very unlikely. Post source code if you can't figure it out, with printouts of the vtx attrib and index bindings just before the draw call that you're seeing this with.

[sharethis]

Thanks for your reply, I found the reason for the application to crash.

The SFML framework I am using to create the window among other things provides a function to reset the OpenGL state of the context. I called that function right after window creation. Removing that call solves my problem. Somehow the ATI driver handled that and the NVIDIA driver not.