Thank you for using gDEBugger.
Could you share some information about your app and the platforms that you're trying to run on?
Which Operating system and Catalyst version are you using? How is OpenCL\OpenGL used in your app? Are you using gDEBugger standalone application or the Visual Studio plug-in?
Have you tried adding a gDEBugger breakpoint to occur when an API call is performed (such as clEnqueueNDRangeKernel) before you ran the application?
Can you successfully debug the APP SDK samples using gDEBugger on these platforms?
Advanced Micro Devices
The information presented in this document is for informational purposes only and may contain technical inaccuracies, omissions and typographical errors. Links to third party sites are for convenience only, and no endorsement is implied.
We finally solved copying the gDebugger opengl32.DLL in the app folder. We don't understand why on some machines this is necessary, while on others is not.
The opengl32.dll and OpenCL.dll files provided with gDEBugger are the OpenGL and OpenCL debugging servers, which are made to replace the system's OpenGL and OpenCL modules by setting the PATH environment variable.
In some configurations, such as managed (.NET) applications, this is not enough, and copying the server into the application folder is required.
It would seem that Microsoft change the way the dynamic loader works in Windows 8, which is why on that machine you did not need to copy the file over.
Please keep these two considerations in mind:
1. If you are updating to a newer gDEBugger version, or another debugger that uses DLL replacement, the file in the folder takes precedence over the file in the PATH, so make sure to overwrite the file in the folder or remove it before continuing.
2. If you want to run the application from that location without using gDEBugger, you must move or rename the file before trying to do so.
In either case (unless upgrading to another gDEBugger version and running the app inside that new version), the OpenGL or OpenCL servers would either:
* Look for their dependent modules and fail to load, which would prevent the application from loading (static link) or fail the ::LoadLibrary() function (dynamic loading)
* Successfully load the dependent modules somehow, at which point they will open a dialog box saying that gDEBugger was run without the client application - pressing OK on that dialog will terminate the application.
This is to alert the user they have left the server module in their application directory.