I've been developing a hack for an older game adding shaders. The dll intercepts opengl calls and then modifies the rendering pipeline as needed. I use glew to load extension functions. For the first time, I am testing compiling and using the .dll on a computer different than the one I primarily developed on.
I've had a previous build of this dll that did work previously on this new machine, but now, when I've compiled the dll from a working source on this machine and attempt to use it, i receive access violations on many gl* function calls (glGenTextures, glBindTexture), that looks like:
Unhandled exception at 0x0C941CA3 in Game.exe: 0xC0000005: Access violation reading location 0xD8EBE92C. occurred
To initialize glew, I call glewInit when I intercept the first glSwapBuffers call. AFAIK this tells me the context already exists, and the gl calls are being called after this init step. I have attempted this with glewExperimental enabled as well. When i receive these errors, I have no indication that glew is not initializing correctly (glewInit() == GLEW_OK)
Am I missing something about OpenGL/glew availability between machines?
The primary development machine which it was working correctly on has a Nvidia Geforce GTX 660ti, running on Windows 10, compiling with VS2015
The secondary development machine which it is failing on, has a "AMD FirePro M6100 FireGL V", running on Windows 7, compiling with VS2017
Related
This is a strange one for me. I'm currently pulling a project from an old repo of mine that I've recently migrated to VS2015. The solution still builds and the executable works, but when running in visual studio I get an access violation in the call to clGetPlatformIDs() trying to read from 0x000008E0.
I honestly have no clue what it could be as it's very strange: the builds work themselves but not from VS. Debugging through I can confirm all the parameters are as expected but the function still fails. I updated the OpenCL implementation to Intel's OpenCL SDK version 6.3 but that didn't fix the problem and I don't have the symbols to dig any deeper into the function.
Code is simple, but I've posted it below anyway.
//Get Platforms
cl_platform_id * platforms = new cl_platform_id[6];
cl_uint numPlatforms = 0;
cl_uint numPlatformsToCheck = 6;
error = clGetPlatformIDs(numPlatformsToCheck, platforms, &numPlatforms);
printCLError( "Getting Platforms", error );
So I just had the same issue: I got an access violation exception on any OpenCL function. Fresh install of the Intel OpenCL SDK, all drivers up-to-date. Only happens when ran inside of Visual Studio.
I found a solution.
There would be an access violation in igdrcl64.dll, causing the exception. This library is part of the IntelHD Graphics drivers and there apparently used to be a bug in the DLL. But I don't have this driver installed (using NVIDIA graphics card), also the bug is supposedly fixed by now. It turns out the IntelHD driver's uninstaller does not remove all it's DLL's, so the buggy DLL's were left on my machine and not updated.
Fix: Remove the DLL's manually (only if you don't use IntelHD graphics!)
On 64-bit version of Windows OS:
C:\Windows\System32\igdbcl64.dll
C:\Windows\System32\igdfcl64.dll
C:\Windows\System32\igdrcl64.dll
C:\Windows\SysWOW64\igdbcl32.dll
C:\Windows\SysWOW64\igdfcl32.dll
C:\Windows\SysWOW64\igdrcl32.dll
On 32-bit version of Windows OS:
C:\Windows\System32\igdbcl32.dll
C:\Windows\System32\igdfcl32.dll
C:\Windows\System32\igdrcl32.dll
I hope this will help someone.
I think you are using clGetPlatformIDs wrong. First, call clGetPlatformIDs(numPlatformsToCheck, NULL, &numPlatforms);
Then:
cl_platform_id * platforms = new cl_platform_id[numPlatforms];
Finally: error = clGetPlatformIDs(numPlatformsToCheck, platforms, NULL);
printCLError( "Getting Platforms", error );
In general OpenCL query commands are:
Query to get number of items in a list
Allocate the memory for the list
Populate list
The issue is probably that it is either trying to find 6 platforms where there are not 6 platforms or something is funky in the library when all parameters are entered.
I am wanting to use Visual Studio's Graphics Diagnostics to debug some shader code, but when I try to "Start Diagnostics", I get an immediate access violation in dxgi.dll. This access violation appears to occur before my program's main function is even entered. I tried adding a Sleep just inside my WinMain function so I could attach a separate debugger, but this code was never hit. I opened one of the DirectX SDK sample programs with the same installation of VS2013 and the Graphics Diagnostics worked fine. I also tried using Graphics Diagnostics on my program on two separate PCs and they both threw the same access violation.
I suspect maybe it has something to do with my project configuration? It seems to be failing to establish a connection between the Graphics Diagnostics debugger and my program before the entry point of my program is called.
Any ideas are much appreciated!
I have a basic application which runs just fine, uses OpenGL 4.3 core profile & GLEW 1.11.0.
However, when I run it through GPU PerfStudio, it crashes right on glewInit, yielding an error saying "Missing GL version".
The context is created before glewInit is called, of course (and as mentioned it runs perfectly fine on its own).
How can this problem be solved?
Update:
Win32 binaries work perfectly fine - this only happens with x64.
My system is Win 8.1 64-bit and using VS2013 Express. I can verify my video cards support the latest OpenGL and OpenCL. I used the latest code and media files from authors github and site: https://github.com/openglsuperbible/sb6code and http://www.openglsuperbible.com/example-code/ respectively.
I am able to make debug and release builds of the project(s) successfully but cannot correctly run it either via debug mode or the .exe in the bin folder. A white window will show up and then exit. I was able to step through and found that glfwOpenWindow will return false causing the exit but I cannot step further and see why it is returning so. I found some solutions that suggested changing
glfwOpenWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
to
glfwOpenWindowHint(GLFW_OPENGL_PROFILE, 0);
but this does not change my results. I can verify also that major version is 4 and minor is 3 for the book code. I have found a few other people having the same problem but no resolution. Another possible solution (but to a different problem it seems) was changing the project subsystem to Console from Windows but this throws an error regarding main and so it may not be what I'm looking for.
For reference, this book is using glfw version 2.7.6 when (currently) the latest is 3.0.4. I tried swapping this too but it understandably blew up due to all of the changes.
Any further ideas would be great and very helpful!
I have discovered that while my GPU does support the latest OpenGL, my computer was instead using the integrated Intel HD 4600! By switching my computer to use the dedicated GPU by default, I am able to run the latest OpenGL.
If it successfully compiled, then please do following:
Ensure that you do have the latest graphic card drivers installed (eg. if you have nVIDIA card, go to www.nvidia.com and get newest drivers).
Ensure that files which these examples are trying to load (I guess jpg/tga/png files, maybe some obj/fbx/3ds files for geometry, whatever else these examples need) are present at expected path (relative path to exe).
Run it as a debug, place breakpoints in app initialization, see that OpenGL is initialized correctly and that required files are loaded. I think you will find that required files are not in expected path(s).
P.S.
I think the best practice for learning OpenGL is not to rely on some library to open window and initalize OpenGL for you - it's better you learn it all step by step - how to open an application window, how to initialize gl render context associated with device context etc. You'd also avoid things like this when you don't know where the problem could be.
I'm having a difficult time trying to debug my GLSL shaders.
I have installed the 64-bit version of NVIDIA's Nsight but this causes problems.
Without running Nsight I now get the following error when trying to exit my application.
Unhandled exception at 0x77dd15de (ntdll.dll) in My.exe: 0xC0000005: Access violation reading location 0x6f637869.
I did not get errors of this type before installing Nsight. If I remove Nsight from my system then the errors no longer occur.
When I try and debug my .exe using Nsight in VS2010 (Nsight -> Start Graphics Debugging) then R6010 - abort() is called.
I'm running an 64-bit computer so I have to install the 64-bit version but I'm using 32-bit libraries for my OpenGL application.
As an alternative I have tried glslDevil.
The problem is with that is it gets stuck in an endless loop of wglGetExtensionsStringEXT() when I use Jump to next draw call (F7)
Can anyone help solve what might be the problem with either software solution, or possibly suggest an alternative? I would like to use either if possible but I have hit a brick wall with both.