3

Some days ago I set up my computer and installed a new copy of Windows 8 because of some hardware changes. Among others I changed the video card from Radeon HD 7870 to Nvidia GTX 660.

After setting up Visual Studio 11 again, I downloaded my last OpenGL project from Github and rebuilt the whole project. I ran the application out of Visual Studio and it crashed because of nvoglv32.dll.

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

In the old environment the application worked as expected. I didn't changed anything of the project or source code. The only difference was the language of the Visual Studio installtion which is English now and was German before. Therefore I created a new project and adopted all settings, but the error remains.

In order to locate the crash, I noticed that all initialization (window, shaders, ...) succeeded and the error is at the draw call glDrawElements() which referrs to the gemoetry pass of my deferred renderer.

After some reseach I found out that nvoglv32.dll is from Nvidia and is about a services called Compatible OpenGL ICD. Does that somehow mean that my application runs in a compatible mode? That sounds like a mode to support older applications and I want mine to run in a regular mode! By the way I installed the lastest stable drivers for my video card.

To be honest, I have no clue how to approach fixing this crash. What could cause it and how to fix it?

Update: I found a post on Geforce Forums about my issue. Although there was no reply, the autor could fix the problem by changing the order of two OpenGL calls.

Hi all,

After poking around with my application source code for a few hours, I found that calling the functions...

glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, #)
glBindVertexArray(#)

...in that order causes the crash in nvoglv64.dll. Reversing the order of these calls to...

glBindVertexArray(#)
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, #)

...prevents the crash and appears to be well-behaved.

Cheers, Robert Graf

Since I do not use vertex arrays I cannot simple do this fix but there might be a similar issue. I will report my progress.

Update: I have absolutely no clue how to solve my problem. I tried different video driver versions but it makes no difference. I completely rewrote the renderer using minimal shaders and simple forward rendering. But the crash sill occurs at the first draw call.

danijar
  • 32,406
  • 45
  • 166
  • 297

2 Answers2

4

In order to locate the crash, I noticed that all initialization (window, shaders, ...) succeeded and the error is at the draw call glDrawElements().

Most likely you had a out-of-bounds access in your code all the time, but the AMD Radeon Catalyst drivers did reserve more address space, or caught them beforehand. And now your NVidia GeForce driver's don't.

Either you're passing glDrawElements a too large number for count elements to draw, or your index buffer contains values that index beyond the range of your vertex arrays. If it's the later, then you're probably using client side vertex arrays, as VBOs usually catch out-of-bounds accesses; also those wouldn't crash your client side program, but just render garbage.

datenwolf
  • 159,371
  • 13
  • 185
  • 298
  • 1
    I want to find that out-of-bounds access if it exists, but I don't know where it could come from. I exclusively use VBOs for my meshes. In the early days of development I faced the problem you described and the was no crash but it just rendered garbage, but that problem should be solved some time ago. Today I calculate the number of elements to draw every frame using this line. `int count; glGetBufferParameteriv(GL_ELEMENT_ARRAY_BUFFER, GL_BUFFER_SIZE, &count); glDrawElements(GL_TRIANGLES, count/sizeof(GLuint), GL_UNSIGNED_INT, 0);` – danijar Feb 23 '13 at 14:12
  • @sharethis: Could you please check, that you actually have a GL_ELEMENT_ARRAY_BUFFER bound, when doing this. Also I'd initialize `count` to 0, and check the value `glGetBufferParameters` sets it to. Also check for OpenGL errors at each step (remember, that you must call glGetError in a loop until it returns GL_NO_ERROR). – My hunch is, that the Radeon drivers were a bit sloppy with buffer bindings and would return something usefull, even it they shouldn't at that situation. – datenwolf Feb 23 '13 at 14:17
  • The array buffer is bound, `count` is set to 144, there are no OpenGL errors. My the way, here is the [related source code](https://github.com/ComputerGame/GraphicsApplication/blob/master/Application/renderer.cpp#L305). – danijar Feb 23 '13 at 14:23
  • @sharethis: This is really curious. Too bad I've got no Windows 8/NVidia machine available right now to reproduce this. One last suggestion, then I'm out of suggestions for the moment, and this is rather desperate: How about you call `glewInit()` everytime you enter your render function? – datenwolf Feb 23 '13 at 14:29
  • @sharethis: Also remember that you may have a OOB access somewhere else in your code and calling glDrawElements just triggers the collapse. – datenwolf Feb 23 '13 at 14:31
  • I rebuilt all all dependencies and the error remains. Initializing GLEW every time I enter the render function is successful even though I enter the function only once because of the crash. In addition I tried to start SFML's OpenGL example application but it closes immediately. So maybe the error lies in SFML or the driver? Other OpenGL application such as Minecraft have to issues. I also want to mention that the draw call writes into the G-buffer since I am using deferred rendering. – danijar Feb 23 '13 at 15:19
  • @sharethis: There's no way we can help you by just suggesting random things. You need to do some actual debugging. In all likelihood, this is not a driver issue; it's a problem in your code that the AMD driver didn't trigger. So you need to do some work in your codebase to track it down. – Nicol Bolas Feb 23 '13 at 23:37
  • @NicolBolas. I hope the problem is in my code. At the moment I do not know how to debug it further. I already located the function call causing the crash. What can I try next? – danijar Feb 24 '13 at 00:05
  • 1
    @sharethis: The usual approach is by disabling single codepaths, one at a time, until the error disappears. Proprocessor `#ifdef` statements are your friend here. Once you located the codepath responsible, single-step debug every step it does. Also I'd riddle it with tons of debug logging of each and every variable and calculation involved to a file in unbuffered write access. – datenwolf Feb 24 '13 at 00:37
  • Thanks, I tried debugging the whole day and decided to write a new renderer. The crash stays! I pasted the related code at the end of my question, maybe someone has the time to review it. There are no OpenGL errors and the shaders compile without warnings. – danijar Feb 24 '13 at 17:33
  • I have the exact same issue in my engine. Disabling "Threaded Optimization" inside the Nvidia driver settings makes the error disappear. My bet is that it's a driver bug. – Tara May 31 '15 at 22:52
  • @Dudeson: Quite possible, but then you can validate that by using a different OpenGL implementation, or maybe even try using some software implementation like Mesa, to see if it crashes there as well. – datenwolf Jun 01 '15 at 07:35
  • @Datenwolf: I only have this problem on SOME Nvidia cards. It runs fine on ATI and Intel cards. I tried to isolate the problem, but I don't see anything that should be causing it. – Tara Jun 02 '15 at 10:16
1

Finally I came up with a solution to fix the crash.

The SFML framework I use to create the window and more provides a function to reset the OpenGL state of the context. I called it right after window creation.

Even though I can't explain why, removing that function call solved the crash. Maybe it is because GLEW or something else isn't yet initialized that moment.

sf::RenderWindow window;
window.create(VideoMode(1024, 768), "Window Title");
window.resetGLStates(); // removing this line fixed the crash
window.setVerticalSyncEnabled(true);
danijar
  • 32,406
  • 45
  • 166
  • 297