I have an OpenGL program that works on all of my computers but one. It's a desktop with Vista 64 and a Radeon HD4850. The problem seems to be in my call to SwapBuffers(hdc).
It compiles fine and then gives me an exception:
Unhandled exception at 0x00000000 in Program.exe: 0xC0000005: Acces violation.
Using VC++ to break before the call to SwapBuffers shows hdc's value to be:
0xfe011734 {unused=???}
CXX0030: Error: expression cannot be evaluated
Anyone have a clue what could be happening? Is there something about SwapBuffers that would change from one PC to the next? I've gotten it to work on XP32, XP64 and a (different) Vista64.
while (!quit)
{
if (PeekMessage(&msg, NULL, NULL, NULL, PM_REMOVE))
{
if (msg.message == WM_QUIT)
quit = true;
TranslateMessage(&msg);
DispatchMessage(&msg);
}
renderFrame(); //draws the scene
SwapBuffers(hdc);
if (GetAsyncKeyState(VK_ESCAPE))
shutdown();
think(); //calculates object positions, etc.
}
The drivers on the problematic system (HD4850) are up-to-date. I've run, and wrote, the program on another Vista64 system with a Radeon HD4870, also with up-to-date drivers. As far as I know, the drivers for these two cards are nearly identical as both are in the HD48xx series. For that reason it seems odd that the GPU is causing the problem.
Anyway, am I wrong or is this a memory issue? (Access violation)
Also, if I remove the call to SwapBuffers(hdc), the program runs seemingly well, although nothing is drawn, of course, because the framebuffers are never swapped. But it is at least stable.
Call stack (-> is stack ptr):
ATKOGL32.dll!6aef27bc()
opengl32.dll!665edb2d()
opengl32.dll!665f80d1()
gdi32.dll!75e14104()
-> MyProg.exe!WinMain(HINSTANCE__ * hinstance=0x009a0000, HINSTANCE__ * hprevinstance=0x00000000, char * lpcmdline=0x003b4a51, int nshowcmd=1) Line 259 + 0xe bytes
MyProg.exe!__tmainCRTStartup() Line 578 + 0x35 bytes
MyProg.exe!WinMainCRTStartup() Line 400
kernel32.dll!7641e3f3()
ntdll.dll!777dcfed()
ntdll.dll!777dd1ff()
Heres the assembly (-> is the next instruction to be executed):
SwapBuffers(hdc);
009B1B5C mov esi,esp
009B1B5E mov eax,dword ptr [hdc (9BF874h)]
009B1B63 push eax
009B1B64 call dword ptr [__imp__SwapBuffers#4 (0E1040Ch)]
-> 009B1B6A cmp esi,esp
009B1B6C call #ILT+780(__RTC_CheckEsp) (9B1311h)
It looks like you could be accessing the HDC after the window has been destroyed, does the problem disappear if you break out of the loop as soon as you get WM_QUIT ?
This is almost definitely a bug in the drivers. The reason why you can't see the value of hdc is because the top stackframe for the crash is actually inside ATKOGL32.dll but since there are no symbols for that the debugger shows you your code. As far as I can tell ATKOGL32.dll is actually an ASUS wrapper for the ATI driver and that's where the crash happens. You might want to install stock ATI drivers from amd.com and see if the crash still persists.
While the driver should never crash no matter what series of OpenGL calls you make, in my experience usually the crashes are the result of some kind of invalid call that your program makes. Technically this should just be ignored and the error state set but thats not always what happens. You can check for any invalid OpenGL calls easily by using a program like gDebugger.
Whatever hdc is set to, it doesn't look to be a proper value. Is the window created before this call? Is there any multithreading involved with this application that could hurt hdc?
Try creating a watch on the address of hdc itself, and see when the value is changed to be an invalid location, that might give you a hint as to where it changes.
We had the same (or at least very similar) issue. It turns out the Dell Nahimic service and Asus Sonic Suite use some weird injection code.
For us the problem solved itself after disabling these services.
Source: https://github.com/glfw/glfw/issues/1682
Related
Good afternoon to all! I am writing a game engine using OpenGL + Win32 / GLFW. Therefore, I will say the project is large, but I have a problem that has led me to a dead end and I can't understand what the problem is. The problem is that I have a shared_ptr<Context> in the 'windows' class (it is platform-based) that is responsible for the context (GL, D3D). And everything works fine when I launch the application, everything is drawn normally, but when I start entering the cursor into the window, a crash occurs when any function calls from context, in my case is:
context->swapBuffers();
Here a crash:
std::shared_ptr<Context>::operator-><Context,0>(...)->**** was 0xFFFFFFFFFFFFFFE7.
Then I got into the callstack and saw that the context-> itself is non-zero, so the function should be called.
Then I searched for a long time for the problem and found that when I remove the Win32 message processing code, and when I remove it, errors do not occur when calling a function from context->. I removed everything unnecessary from the loop and left only the basic functions and tried to run it like this, because I thought that some other functions inside were causing this problem, but no.
while (PeekMessageW(&msg, NULL, NULL, NULL, PM_REMOVE) > 0) {
TranslateMessage(&msg);
DispatchMessageW(&msg);
}
That is, when I delete TranslateMessage() and DispatchMessage(), the error goes away. And then I finally got confused i.e I don't understand what is happening. And then I thought that maybe somehow the operating system itself affects that pointer, prohibits reading or something like that.
And then I paid attention to __vtptr in the call stack, and noticed that it is nullptr, and moreover it has the void** type. And also the strangest thing is that in the error I have ->**** was 0xffffffffffffffc7 as many as four consecutive pointers. What is it?
I understand I practically didn't throw off the code, because I have a big project and I think it doesn't make sense to throw everything, so I tried to explain the problem by roughly showing what is happening in my code. I will be grateful to everyone who will help :)
Every time I compile my simple SDL1.2 code it's compiled successfully
but when I try to run it via terminal (alt+t in Ubuntu):
./game
Segmentation fault (core dumped)
I get this error. Can you help please? This is the code:
#include<SDL/SDL.h>
int main(int argc,char args)
{
SDL_Init( SDL_INIT_EVERYTHING);
SDL_Surface* screen;
screen=SDL_SetVideoMode(640,480,32,SDL_HWSURFACE);
SDL_Flip(screen) ![problem running the program][1];
SDL_Delay(5000);
SDL_FreeSurface(screen);
SDL_Quit();
}
SDL_SetVideoMode returns NULL on error which you do not check for.
Since you're running this via a terminal, I suspect you may have forgotten to tell Xorg to allow running from it. In fact, if this is really the problem it'll prevent any program from running when started that way.
To fix the problem, enter this into the terminal (this only needs to be done once per session):
xhost +
You should get a message that it was successful. I cannot recall the exact message, but it is something like this:
Clients are now allowed to connect from any host.
What was happening (assuming that I was correct regarding xhost) was that the SDL_SetVideoMode() call was failing and returning NULL, because Xorg rejected the connection. Since you're not checking for that, SDL_Flip() ended dereferencing a NULL pointer --- hence the segfault.
SIDE-NOTE: There is an error in your code, however --- namely, you should not call SDL_FreeSurface(screen);; that particular surface is special, and is freed by SDL_Quit(); automatically. Source (see "Return Value" section): http://www.libsdl.org/release/SDL-1.2.15/docs/html/sdlsetvideomode.html
Check if SDL_SetVideoMode() failed!
screen = SDL_SetVideoMode(640, 480, 32, SDL_HWSURFACE);
if (screen == NULL) /* error */;
Run it under valgrind. Or GDB. Or some other debugger of your choice.
You should probably be successfully allocating memory for screen.
After successfully building a trampoline and learning more about process memory space, I tested the trampoline on MessageBoxA. It worked perfectly so I decided to finally put the code to the use it was supposed to be for in the first place, hiding a process by hooking NtQuerySystemInformation. The redirect function should work fine, but the code I used to write the jmp instruction now causes the task manager to crash every time.
BYTE tmpJMP[5] = {0xE9,0x00,0x00,0x00,0x00}; //jmp,A,D,D,R
memcpy(JMP,tmpJMP,5);
DWORD Addr = ((DWORD)func - ((DWORD)oNtQuerySystemInformation + 0x5));
for (int i=0;i<4;++i)
JMP[i+1] = ((BYTE*)&Addr)[i];
if (VirtualProtect((LPVOID)oNtQuerySystemInformation,5,PAGE_EXECUTE_READWRITE,&oldProtect) == FALSE)
MessageBox(NULL,L"Error unprotecting memory",L"",MB_OK);
memcpy(oldBytes,(LPVOID)oNtQuerySystemInformation,5);
if (!WriteProcessMemory(GetCurrentProcess(),(LPVOID)oNtQuerySystemInformation,(LPCVOID)JMP,5,NULL))
MessageBox(NULL,L"Unable to write to process memory space",L"",MB_OK);
VirtualProtect((LPVOID)oNtQuerySystemInformation,5,oldProtect,NULL);
FlushInstructionCache(GetCurrentProcess(),NULL,NULL);
I'm writing to the memory as such. I can't seem to find a problem with the code. I was thinking that maybe the memory changes from API to API but I was told that's incorrect, making me all out confused. Is there anything wrong that you all see? Please be descriptive. I love to learn o3o
I've got some code to create a new desktop and launch a process into that desktop.
One a few select Windows XP machines, when this code runs, I can see it switch to the new desktop and start the process, but almost immediately, the desktop switches back to the normal desktop.
This code works fine on about 98% of machines, and I can't seem to isolate any reason for this not working on the others.
Should SwitchDesktop be reliable? Can I hook calls to SwitchDesktop that might be called from another application?
My code:
int DLL_EXP_IMP WINAPI Process_Desktop(char *szDesktopName, char *szPath)
{
HDESK hOriginalThread;
HDESK hOriginalInput;
HDESK hNewDesktop;
int procSuccess;
// Save original ...
hOriginalThread = GetThreadDesktop(GetCurrentThreadId());
hOriginalInput = OpenInputDesktop(0, FALSE, DESKTOP_SWITCHDESKTOP);
// Create a new Desktop and switch to it
hNewDesktop = CreateDesktop(szDesktopName, NULL, NULL, DF_ALLOWOTHERACCOUNTHOOK, GENERIC_ALL, NULL);
SetThreadDesktop(hNewDesktop);
SwitchDesktop(hNewDesktop);
// This call blocks until the process exits, and is confirmed to work on the affected machines
procSuccess = StartProcess(szDesktopName, szPath);
// Restore original ...
SwitchDesktop(hOriginalInput);
SetThreadDesktop(hOriginalThread);
// Close the Desktop
CloseDesktop(hNewDesktop);
if (procSuccess != 0)
{
return procSuccess;
}
else
{
return 0;
}
}
My guess is that SetThreadDesktop() fails.
From MSDN:
"The SetThreadDesktop function will fail if the calling thread has any windows or hooks on its current desktop (unless the hDesktop parameter is a handle to the current desktop)."
You mentioned that StartProcess() blocks until the process terminated.
So then there is nobody referencing the new desktop and thus the desktop will go away.
You may want to consider wrapping fallible system calls in C++
-- throwing an exception in case of they fail.
And certainly the pair CreateDesktop/CloseDesktop belongs into a C++ resource wrapper.
This is 2013!
Either SwitchDesktop is failing (most of the time is access denies, or error 170 because of existing handles in another desktop), or there is another program that switches back to the default desktop.
I know for a fact that Yahoo toolbar did this (versions 5-6-7, perhaps they fixed now); KABE4.exe (I don't know what this is), an Acronis program (backup scheduler, AFAIK), and more. All of these are calling SwitchDesktop without any user intervention (a big no-no).
I proved this for Yahoo toolbar; hooking the SwitchDesktop by injecting another dll into yt.dll (loaded by IE) and returning FALSE from the hooked call solved my problem.
The proof of concept sent almost 2 years ago to Yahoo remained unanswered to this day.
In your posted code, there is that part:
// Create a new Desktop and switch to it
hNewDesktop = CreateDesktop(szDesktopName, NULL, NULL, DF_ALLOWOTHERACCOUNTHOOK, GENERIC_ALL, NULL);
SetThreadDesktop(hNewDesktop);
SwitchDesktop(hNewDesktop);
// This call blocks until the process exits, and is confirmed to work on the affected machines
procSuccess = StartProcess(szDesktopName, szPath);
// Restore original ...
SwitchDesktop(hOriginalInput);
SetThreadDesktop(hOriginalThread);
Your call to StartProcess function is between two calls to SwitchDesktop.
No function in this code stop (pause) or delay the running code, thread or process, so as you switch to hNewDesktop, you immediately switch back to hOriginalInput. You should add a while loop with end condition, after the call to StartProcess, and before the second call to SwitchDesktop. I don't know what will be the end condition for the while loop, but you do know, you will choose, after all it is your program.
For example you can use either GetKeyState or GetAsyncKeyState function to check which key is pressed on the keyboard, and make it as the end condition for the while loop, so when you will press that key, you will return immediately to your original desktop!
I'm currently doing some tests using Cairo to replace some existing GDI/GDI+
code in Visual C++ 2010 and it seems to be working fine, but I'm getting
an error message each time I close down my application :
"First-chance exception at 0x68e629dc in CairoTest.exe: 0xC0000005:
Access violation reading location 0xabababa7"
This error only happens if I've called cairo_paint(cr) while the
application is running - if I comment this line out, it disappears. The
only Cairo code in my application so far is :
CChildView::CChildView()
{
testsurface = cairo_image_surface_create_from_png("BlackShinyBackground.png");
}
CChildView::~CChildView()
{
cairo_surface_destroy(testsurface);
}
void CChildView::OnPaint()
{
CPaintDC dc(this);
cairo_surface_t *surface = cairo_win32_surface_create(dc.m_hDC);
cairo_t *cr = cairo_create (surface);
cairo_set_source_surface(cr, testsurface, 0, 0);
cairo_paint(cr);
cairo_destroy (cr);
cairo_surface_destroy (surface);
}
Can anybody point me in the direction of what I'm doing wrong?
Like I said, the code appearsto be working fine, but I don't like just ploughing on regardless when I can see errors.
A first chance exception doesn't necessarily mean much -- they're a routine part of Windows' memory management. Basically, any time you access something that's in virtual memory (e.g., on the paging file) a first chance exception is created. The OS handles it by paging in the required data into physical memory, then your code can continue executing.
If/when you see a second-chance exception, it means the OS didn't handle the exception, so unless you have a handler for it in your code, chances are pretty good that is signals a real problem.