Native Auswertung der vier Absturzabbilder

Stand: 16.09.2026, nach der ausdrücklich genehmigten einmaligen Windows-Administratorabfrage. Alle Uhrzeiten unten sind Ortszeit Wien (UTC+02:00).

Ergebnis

Die Abbilder bestätigen einen Ausfall im NVIDIA-Grafikpfad über mehrere Grafik-APIs. Sie identifizieren noch keinen fehlerhaften Unity-Renderbefehl und keinen bewiesenen Hardwaredefekt. Der manuelle Vulkan-Vorfall und der kontrollierte Direct3D11-Vergleich haben denselben Windows-TDR-Bucket. Auch der ältere tatsächliche Bluescreen enthält NVIDIA-Treibercode im unterbrochenen Interrupt-Stack. Ein weiterer ungezielter GPU-Lasttest wurde für diese Auswertung nicht gestartet.

Die Dump-Zeit ist der Erfassungszeitpunkt, nicht zwingend der Beginn des Hängers. Die beiden jüngeren NVIDIA-Ereignisse beginnen laut Ereignisprotokoll bereits um 22:39:29 beziehungsweise 22:57:49.749. Der Kernel-Dump des älteren Bluescreens wurde um 20:12:43 erfasst; spätere WER-/Neustartzeitpunkte dürfen diesen Vorfall nicht dem manuellen 22:39-Test zuordnen.

Was die Stacks zeigen

Beide 0x117-Stacks laufen über dxgmms2!VidSchiCheckHwProgress und VidSchiReportHwHang in dxgkrnl!TdrIsRecoveryRequired / TdrCollectDbgInfoStage1. Das ist die Windows-Erkennung eines GPU-Hängers. Der identische NVIDIA-Offset ist der Modul-/Owner-Zeiger aus Parameter 2, nicht automatisch der gerade ausgeführte Shader oder eine identische ursächliche Instruktion. Die Treibermodule haben in beiden Dumps denselben Zeitstempel, dieselbe Image-Größe und Prüfsumme. Die gesicherten Systemdaten nennen NVIDIA 32.0.16.1692 / 616.92 auf einer RTX 4060 Laptop GPU.

Beim 0x133 ist NVIDIA-Code tatsächlich im unterbrochenen Interrupt-Stack sichtbar; !analyze -v ordnet den Bucket entsprechend zu. Parameter 1 = 1 bezeichnet jedoch ein kumulatives Zeitproblem. Microsoft weist ausdrücklich darauf hin, dass die angehaltene Stelle in diesem Fall nicht zwingend die verursachende Stelle ist. In der Warteschlange stehen unter anderem DPCs von dxgkrnl und NVIDIA; eine Warteschlange beweist keine individuelle Laufzeitüberschreitung.

Die zusätzliche Analyse mit der exakt passenden lokal vorhandenen nvlddmkm.sys verbessert den zuvor unvollständigen Stack deutlich. PE-Zeitstempel 6A9B4070, Image-Größe 06D3E000, Prüfsumme 06CB1A9C und Version 32.0.16.1692 stimmen überein. Jetzt lässt sich die Kette über zahlreiche NVIDIA-Frames bis zu dxgkrnl!DpiFdoMessageInterruptRoutine zurückverfolgen; darunter befindet sich eine weitere NVIDIA-DPC-Kette aus nt!KiExecuteAllDpcs. Der Offset +0xead63 erscheint in beiden unterbrochenen NVIDIA-Ketten. Das konkretisiert den Interrupt-/DPC-Kontext, liefert ohne private Treibersymbole aber weiterhin keinen Spiel-Draw und keinen bewiesenen Endlosloop. Erweiterter Stack mit passendem Treiber-Image.

Die vorhandene PNP-Blackbox enthält einen Display-Eintrag mit Problemcode 24 und Zeit 19:42:20.662, rund 30 Minuten vor dem Bluescreen. Dieser ältere Eintrag beweist keinen zeitgleichen Display-Abbruch oder dessen Ursächlichkeit. Die Boot-Blackbox meldet für den Erfassungszustand keinen laufenden Schlaf- oder Herunterfahrvorgang. Es wurde keine Gerätekonfiguration geändert.

0x193 bezeichnet ebenfalls einen Live-Dump. Die öffentliche Microsoft-Dokumentation erklärt den hier erfassten internen Reason 0x810 nicht. ProcessDeadlockThread ist deshalb keine hinreichende Grundlage für die Aussage, Windows selbst sei defekt oder ein bestimmter Benutzerprozess habe den Deadlock verursacht.

Grenzen und Konsequenz für das Spiel

• Der Ausfall ist nicht auf Vulkan beschränkt. Ein API-Wechsel oder das erneute Abschalten des SRP-Batchers ist deshalb kein belegter Fix.
• Der kontrollierte Direct3D11-Lauf scheiterte bei etwa 26,8 Rennsekunden weit vor dem Ziel. Eine Rundenwechselroutine ist für diesen Fehlertyp nicht erforderlich. Das widerlegt nicht die Nutzerbeobachtung beim Wechsel Runde 1 → 2; die konkrete Rundstrecke bleibt zu klären.
• Ein von unserem Spiel ausgelöster Render-/Ressourcenfehler bleibt möglich. Dass andere Spiele stabil laufen, passt zu einem bestimmten problematischen Rendering-Workload und begründet keinen pauschalen Hardwarevorwurf.
• Die Abbilder enthalten keinen Unity-User-Mode-Stack, keine Zuordnung zum fehlgeschlagenen Draw/Dispatch und keinen vollständigen GPU-Befehlsverlauf. Öffentliche NVIDIA-Funktionssymbole fehlen. Die internen Typen dxgkrnl!_TDR_RECOVERY_CONTEXT und nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK waren im verwendeten öffentlichen Symbolsatz nicht verfügbar; entsprechende Zusatzabfragen wurden protokolliert und liefern keine weiteren belastbaren Felder.
• Die vorhandene Telemetrie stützt weder GPU-Speichermangel noch Überhitzung. Sie schließt andere Hardware-/Firmware-/Treiberinteraktionen nicht aus.
• Unity 6000.3.24f1 mit HDRP 17.3.0 ist der aktuelle geprüfte 6.3-LTS-Stand. Der frühere vollständige 6.6-Spielvergleich scheiterte ebenfalls. Die offizielle Unity-Recherche liefert keinen nachgewiesenen Upgrade-Fix.

Damit sind zwei Ursachenebenen getrennt: nachgewiesen ist ein stockender NVIDIA-/Windows-Grafikpfad; offen ist der Auslöser zwischen Spielinhalt, Engine, Treiber und Gerätekonfiguration. Aus dem Modulnamen allein folgt weder ein NVIDIA-Softwarefehler noch ein defektes Gerät.

Nächster gezielter Vergleich

Die unabhängige erneute Codeprüfung ergibt keinen weiteren belegten Crash-Fix. Ein konkreter Ansatz bleibt das historische Direct3D12-Protokoll mit 83 GPU-Validierungsfehlern bei Constant-Buffer-Zugriffen. Der erste Fehler betrifft Compute Dispatch 20, nicht nachweislich eine Baumzeichnung. Der Runtime-Code bindet keine eigenen ConstantBuffer; die Zuordnung zum HDRP-/Engine-Pass fehlt noch. Root-Parameter 0 ist dabei nicht automatisch Shader-Register b0.

Die vorhandene Testmatrix trennt Bäume und Kameraeffekte noch nicht vollständig: Unterdrückte Billboards mit reduzierten Effekten bestanden, native Ersatz-Billboards mit vollständigen Effekten scheiterten. Der Wrapper koppelt NoBillboardShader derzeit zusätzlich an -rampageGpuMinimalEffects. Daraus darf man keine ausschließliche Schuld des eigenen Baumshaders ableiten.

Ein aussagekräftiger nächster Inhaltstest würde bei identischem Build, alps-02, Low, Kamera 0 und Wetterseed 707000 nur die Baum-Zeichenbefehle unterdrücken, Ressourcenaufbau und volle Kameraeffekte beibehalten und die tatsächlich aktiven Pfade protokollieren. Vorher muss die bestehende Wrapper-Kopplung ausdrücklich getrennt und der Bericht entsprechend präzisiert werden. Der ergänzende Gegenpunkt wäre native Ersatz-Billboards mit reduzierten Effekten. Diese Vergleiche sind nicht ausgeführt und keine Stabilitätsfreigabe. Für eine endgültige Engine-Korrektur braucht es die Zuordnung des ersten ungültigen Draw/Dispatch zu Shader und Ressourcenbindung in einem verkleinerten Repro; ein weiterer bloßer API- oder Versionswechsel liefert diese Zuordnung nicht.

Sicherung und reproduzierbare Analyse

Das freigegebene Kopierskript lief erfolgreich am 16.09.2026 um 23:21:22. Es kopierte die vier Fälle und prüfte die Inhalte gegen SHA-256. Die ursprünglichen WATCHDOG-Pfade waren inzwischen nicht mehr vorhanden; die zugeordneten WER-Queue-Verzeichnisse enthielten die Abbilder weiterhin. Beim älteren Kernel-Dump stimmen direkte Minidump- und WER-Kopie überein. Manifest: protected-dumps/copy-20260916-232122-93de250112c44eb581c241de7de20217.json.

Die Auswertung erfolgte mit dem portablen, von Microsoft signierten CDB 10.0.29617.1000, explizit mit -z <lokale Dump-Datei>, Microsoft-Symbolserver und lokalem Symbolcache. Keine Live-Prozessanbindung und keine Aktivierung von Kernel-Debugging. Nach Ergänzung einer fehlenden signierten Analyse-DLL liefen alle vier vollständigen !analyze -v-Aufrufe erfolgreich. Microsoft-Symbole wurden heruntergeladen; die Abbilder wurden nicht hochgeladen. Keine Änderungen an Treibern, Registry, Diensten, BIOS oder Quellberechtigungen.

Maßgebliche vollständige Ausgaben:

• Vulkan 22:39
• Grafik-Deadlock-Erfassung 22:40
• Direct3D11 22:57
• Älterer Bluescreen 20:12

Frühe windbg-analysis.txt-/Setup-Protokolle enthalten noch Symbol-/Abhängigkeitsprobleme und ersetzen diese vollständigen Ausgaben nicht. Raw-Dumps und WER-Metadaten sind im lokalen Unterordner von Git ausgeschlossen.

Primärquellen zur Interpretation

• Microsoft: 0x117 VIDEO_TDR_TIMEOUT_DETECTED
• Microsoft: 0x133 DPC_WATCHDOG_VIOLATION, insbesondere Parameter 1 = 1
• Microsoft: 0x193 VIDEO_DXGKRNL_LIVEDUMP