Freigeben über


Timeouterkennung und -wiederherstellung (TDR)

In diesem Artikel wird die Timeouterkennung und -wiederherstellung (TDR) für Treiberentwickler beschrieben. Weitere Informationen finden Sie unter TDR in Windows 8 und höher.

Übersicht

Eines der häufigsten Stabilitätsprobleme in Grafiken tritt auf, wenn ein Computer scheinbar "hängen" oder vollständig "eingefroren" zu sein scheint, wenn er tatsächlich einen Endbenutzerbefehl oder -vorgang verarbeitet. Viele Benutzer warten einige Sekunden und entscheiden sich dann, den Computer neu zu starten. Das eingefrorene Erscheinungsbild des Computers tritt häufig auf, weil die GPU mit der Verarbeitung intensiver grafischer Vorgänge beschäftigt ist, in der Regel während des Spiels, und daher den Bildschirm nicht aktualisiert. TDRs ermöglichen es dem Betriebssystem zu erkennen, dass die Benutzeroberfläche nicht reagiert.

Die folgende Abbildung zeigt den TDR-Prozess.

Diagramm: Timeouterkennung und -wiederherstellung (TDR) von GPUs über WDDM

Das Betriebssystem versucht, Situationen zu erkennen, in denen Computer scheinbar "eingefroren" sind. Das Betriebssystem versucht dann, die eingefrorenen Situationen dynamisch wiederherzustellen, sodass Desktops wieder reagieren, wodurch die Situation behoben wird, in der Endbenutzer ihre Systeme unnötig neu starten.

Wenn das Betriebssystem erkennt, dass fünf (5) oder mehr GPU hängen (0x117) und nachfolgende Wiederherstellungen innerhalb einer (1) Minute auftreten, wird der Computer auf der nächsten (sechsten oder mehr) GPU vom Betriebssystemfehler überprüft. Weitere Informationen finden Sie unter TdrLimitCount und TdrLimitTime.

Nebenbei tragen Engine-Timeouts (0x141) nicht zur Anzahl der GPU-Hänger bei, obwohl das Betriebssystem ein Engine-Timeout auf eine GPU hängen lässt, wenn das Engine-Timeout nicht erfolgreich ist. Bei Enginetimeouts (0x141) beträgt die maximale Anzahl ein weniger als bei Adaptertimeouts (0x117). Der Prozess zum Zurücksetzen des Moduls blockiert den GPU-Zugriff für den Prozess, der solche Timeouts verursacht, und die Systemprotokolle 0x142 , um diese Tatsache anzugeben. Auf diese Weise überprüft der fehlerhafte Prozess das System nicht.

Timeouterkennung in WDDM

Der GPU-Planer, der Teil des DirectX-Grafikkernsubsystems (Dxgkrnl.sys) ist, erkennt, dass die GPU mehr als die zulässige Zeit in Anspruch nimmt, um eine bestimmte Aufgabe auszuführen. Der GPU-Planer versucht dann, diese bestimmte Aufgabe vorzubesetzen. Der vorzeitige Vorgang weist ein "Wartetimeout" auf, d. h. das tatsächliche TDR-Timeout. Der Standardmäßige Timeoutzeitraum in Windows Vista und höheren Betriebssystemen beträgt 2 Sekunden. Wenn die GPU die aktuelle Aufgabe nicht innerhalb des TDR-Timeoutzeitraums abschließen oder vorzeitig beenden kann, diagnostiziert das Betriebssystem, dass die GPU eingefroren ist.

Um die Timeouterkennung zu verhindern, sollten Hardwarehersteller sicherstellen, dass Grafikvorgänge (d. h. DMA-Puffervervollständigung) in Endbenutzerszenarien wie Produktivität und Spielwiedergabe nicht mehr als 2 Sekunden dauern.

Vorbereitung auf die Wiederherstellung

Der GPU-Planer ruft die DxgkDdiResetFromTimeout-Funktion des Anzeigeminiporttreibers auf, um den Treiber darüber zu informieren, dass das Betriebssystem ein Timeout erkannt hat. Der Treiber muss sich dann selbst neu initialisieren und die GPU zurücksetzen. Darüber hinaus muss der Treiber den Zugriff auf Arbeitsspeicher beenden und sollte nicht auf Hardware zugreifen. Das Betriebssystem und der Treiber sammeln Hardware- und andere Zustandsinformationen, die für die Diagnose nach der Wiederherstellung nützlich sein können.

Weitere Informationen finden Sie unter TDR in Windows 8 und höher.

Desktopwiederherstellung

Das Betriebssystem setzt den entsprechenden Zustand des Grafikstapels zurück. Der Videospeicher-Manager, der ebenfalls Teil vonDxgkrnl.sysist, löscht alle Zuordnungen aus dem Videospeicher. Der Display-Miniporttreiber setzt den GPU-Hardwarezustand zurück. Der Grafikstapel führt die letzten Aktionen aus und stellt den Desktop wieder in den reaktionsfähigen Zustand zurück.

Das einzige sichtbare Artefakt von der Aufhängeerkennung bis zur Wiederherstellung ist ein Bildschirmflimmern. Dieses Flackern ergibt sich, wenn das Betriebssystem einige Teile des Grafikstapels zurücksetzt, was zu einer Bildschirmumstellung führt. Der Display-Miniporttreiber kann diese Neuschreibung beseitigen, wenn er WDDM 1.2 und höher entspricht (siehe Bereitstellen nahtloser Zustandsübergänge in WDDM 1.2 und höher).

Wenn das Betriebssystem den Desktop erfolgreich wiederhergestellt hat, werden die folgenden Aktionen ausgeführt:

  • Zeigt dem Endbenutzer eine Informationsmeldung mit der Meldung "Der Anzeigetreiber reagiert nicht mehr und wurde wiederhergestellt" angezeigt.
  • Protokolliert die obige Meldung in der Ereignisanzeige-Anwendung und sammelt Diagnoseinformationen in Form eines Debugberichts. Wenn sich der Endbenutzer für die Bereitstellung von Feedback angemeldet hat, gibt das Betriebssystem diesen Debugbericht über den OCA-Mechanismus (Online Crash Analysis) an Microsoft zurück.

Einige Legacy-DirectX-Anwendungen werden am Ende dieser Wiederherstellung möglicherweise nur schwarz gerendert, sodass der Endbenutzer diese Anwendungen neu starten muss. Gut geschriebene DirectX 9Ex- und DirectX 10- und höher-Anwendungen, die geräteferne Technologie behandeln, funktionieren weiterhin ordnungsgemäß. Eine Anwendung muss ihr Microsoft Direct3D-Gerät und alle Geräteobjekte freigeben und dann neu erstellen.

Threadsynchronisierung und TDR

Weitere Informationen finden Sie unter Threadsynchronisierung und TDR .

Testen und Debuggen von TDR

Weitere Informationen finden Sie unter Testen und Debuggen von TDR .