Hi,
Since driver version about 290.36 (don’t rememeber exactly) any OpenGL app I have crashes at the start. Some of them I cannot debug (i.e. RenderMonkey). But debugging my own one I discovered that there is a memory problem about some of the basic functions in OpenGL (I get an info from VS2008 debugger like in the screenshot attached). Is there an issue concerning improper behaviour of OpenGL function like ‘IsProgram’, ‘IsEnabled’ or ‘GetInteger’?
The error merely suggests that you’re trying to write to a protected area of memory. This can mean you’re trying to access memory via a null pointer(function pointer or pointer to data). I assume you don’t get proper function pointers for your GL functions anymore, which can happen, for instance, if you can’t create a valid GL context. You can verify that easily when using GLEW and trying to access some arbitrary GL functions loaded by GLEW after glewInit(). If it crashes, chances are that you didn’t a valid (and current) GL context at the time glewInit() was called. This would also explain why other GL apps don’t run - because they can’t.
You might just have screwed up your driver installation - although I’m not sure how this still happens under newer version of Windows (it’s quite easy to do Linux).
If there was a problem with functions pointers none of the calls would succeed, right? But in my case a subsequent call to a certain routine causes the problem described here. I.e. I have a call to ‘glIsEnabled’ in the rendering loop. First time it executes well, but second causes the mentioned error. It seems that something bad happens within the driver code. Is it possible that some kind of OS failure (not directly related to graphics) can lead eventually to GL driver error? Or can that be a hardware problem (hope not)?
This strongly suggests that the driver causes the crash - that doesn’t necessarily mean that it’s a bug in the driver but that you’re doing something that is illegal in the current state. It would be more interesting to see which GL functions provokes this.
You’re getting a lot of “INVALID HEAP ARGUMENT to RtlFreeHeap” from UxTheme.dll - one likely diagnosis is that the theme was always buggy but the older drivers used to swallow the bugs more gracefully. Another is that this particular theme has exposed some bug in the driver that wasn’t there before. Either way I’d suggest running without the theme and seeing if it reproduces.
You’re getting a lot of “INVALID HEAP ARGUMENT to RtlFreeHeap” from UxTheme.dll - one likely diagnosis is that the theme was always buggy but the older drivers used to swallow the bugs more gracefully. Another is that this particular theme has exposed some bug in the driver that wasn’t there before. Either way I’d suggest running without the theme and seeing if it reproduces.
When I changed theme to ‘Windows classic’ nothing changed - error still occures…