SwapBuffers stürzt mein Programm ab!

Question

Ich habe ein OpenGL-Programm, das auf allen meinen Computern außer einem funktioniert. Es ist ein Desktop mit Vista 64 und einer Radeon HD4850. Das Problem scheint in meinem Aufruf von SwapBuffers(hdc) zu liegen.

Es kompiliert gut und gibt mir dann eine Ausnahme:

Unbehandelte Ausnahme bei 0x00000000 in Program.exe: 0xC0000005: Zugriffsverletzung.

Die Verwendung von VC++, um vor dem Aufruf von SwapBuffers zu brechen, zeigt den Wert von hdc als:

0xfe011734 {unused=???} CXX0030: Fehler: Ausdruck kann nicht ausgewertet werden

Hat jemand eine Ahnung, was da los sein könnte? Gibt es irgendetwas an SwapBuffers, das sich von einem PC zum nächsten ändern würde? Ich habe es auf XP32, XP64 und einem (anderen) Vista64 zum Laufen gebracht.

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.
    } 

Die Treiber auf dem problematischen System (HD4850) sind aktuell. Ich habe das Programm auf einem anderen Vista64-System mit einer Radeon HD4870, ebenfalls mit aktuellen Treibern, ausgeführt und geschrieben. Soweit ich weiß, sind die Treiber für diese beiden Karten nahezu identisch, da beide zur HD48xx-Serie gehören. Aus diesem Grund scheint es seltsam, dass die GPU das Problem verursacht.

Wie auch immer, liege ich falsch oder ist das ein Speicherproblem? (Zugriffsverletzung)

Wenn ich außerdem den Aufruf von SwapBuffers(hdc) entferne, läuft das Programm scheinbar gut, obwohl natürlich nichts gezeichnet wird, weil die Framebuffer nie getauscht werden. Aber es läuft zumindest stabil.

Aufruf von Stack (-> ist 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()    

Hier ist der Zusammenbau (-> ist die nächste auszuführende Anweisung):

            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)

Answer 1

Es sieht aus wie Sie Zugriff auf die HDC, nachdem das Fenster zerstört wurde, verschwindet das Problem, wenn Sie aus der Schleife brechen, sobald Sie WM_QUIT erhalten?

Answer 2

Es handelt sich mit ziemlicher Sicherheit um einen Fehler in den Treibern. Der Grund, warum Sie den Wert von hdc nicht sehen können, ist, dass der oberste Stackframe für den Absturz eigentlich in der ATKOGL32.dll liegt, aber da es keine Symbole dafür gibt, zeigt der Debugger Ihren Code an. Soweit ich das beurteilen kann, ist ATKOGL32.dll ein ASUS-Wrapper für den ATI-Treiber, und genau dort tritt der Absturz auf. Vielleicht möchten Sie die Standard-ATI-Treiber von amd.com installieren und sehen, ob der Absturz weiterhin auftritt.

Während der Treiber niemals abstürzen sollte, egal welche Reihe von OpenGL-Aufrufen Sie machen, sind meiner Erfahrung nach die Abstürze normalerweise das Ergebnis einer Art von ungültigem Aufruf, den Ihr Programm macht. Technisch gesehen sollte dies einfach ignoriert und der Fehlerstatus gesetzt werden, aber das ist nicht immer das, was passiert. Sie können für alle ungültigen OpenGL-Aufrufe leicht überprüfen, indem Sie ein Programm wie gDebugger.

Answer 3

Wie auch immer hdc eingestellt ist, es sieht nicht so aus, als wäre es ein richtiger Wert. Wird das Fenster vor diesem Aufruf erstellt? Ist bei dieser Anwendung Multithreading im Spiel, das hdc beeinträchtigen könnte?

Versuchen Sie, die Adresse von hdc selbst zu überwachen, und sehen Sie, wann der Wert an einem ungültigen Ort geändert wird; das könnte Ihnen einen Hinweis darauf geben, wo er sich ändert.