Interne Treiberfehler (Direct3D 9)
In Direct3D 9 ermöglicht Direct3D dem Treiber die Rückgabe von Fehlercodes wie E _ OUTOFMEMORY, D3DERR _ OUTOFVIDEOMEMORY und D3DERR UNSUPPORTEDCOLORARG, damit eine Anwendung darauf reagieren _ kann. Manchmal werden die API-Aufrufe, die diese Rückgabetypen generiert haben, jedoch in einen Befehlspuffer geladen und per Batch an die GPU gesendet (siehe Steuern von Laufzeit- und Treiberoptimierungen). In diesem Fall können die Fehler nicht an die Anwendung übermittelt werden, wenn eine Aktion ausgeführt werden muss. Daher wird der Fehlercode von der Laufzeit verwendet, und es wird ein Hinweis auf das Geräteobjekt ausgegeben, dass dies aufgetreten ist. Später, wenn die Anwendung IDirect3DDevice9::P resent aufruft,gibt IDirect3DDevice9::P resent D3DERR _ DRIVERINTERNALERROR zurück. Aus diesem Grund ist der beste Ansatz für eine Anwendung, wenn sie einen D3DERR _ DRIVERINTERNALERROR von IDirect3DDevice9::P resent empfängt, das Gerät zu zerstören und neu zu erstellen.
Wenn Sie versuchen möchten, weiter zu debuggen, finden Sie hier einige Vorschläge, wie Sie herausfinden können, welcher API-Aufruf den Fehler generiert:
Da die Liste der möglichen Rückgabewerte nicht vollständig ist, können Sie versuchen, herauszufinden, welcher Aufruf fehlschlägt, indem Sie jeden API-Aufruf wie den folgenden umhingen:
TRACE ( "Calling DrawPrimitive" ); d3ddev->DrawPrim(...); TRACE ( "done\n" );Der Ausgabedebugstream sollte dann den Aufruf anzeigen, der das Problem verursacht.
Versuchen Sie außerdem zu Debugzwecken, IDirect3DDevice9::ValidateDevice direkt vor jedem IDirect3DDevice9::D rawPrimitive aufrufen, um zu überprüfen, ob ein zusätzliches Problem mit dem Gerätetreiber vor liegt (nicht unterstützter Vorgang, nicht verwendbare Kombination von Texturformaten usw.).
Hinweis
IDirect3DDevice9::ValidateDevice sollte sorgfältig und mit Bedacht verwendet werden, da der Treiber viel Validierungsarbeit zum Zurückgeben einer Antwort ausführen muss.