Aktive Reparaturarbeit
Fortsetzung auf ausdrücklichen Auftrag, das Problem tatsächlich zu beheben. Sichtbare automatische Spielfenster wurden vom Nutzer am 16.09. erneut ausdrücklich freigegeben. Weiter kein bestätigter Fix. Der Nutzer hat inzwischen den vorbereiteten NVIDIA-610.88-Vergleich ausdrücklich freigegeben, ohne Windows-Neustart. Der Treiberwechsel ist erfolgt und unabhängig als aktiv bestätigt; Registry-/BIOS-Änderungen wurden nicht vorgenommen.
Neuer Nutzertest unter aktivem 610.88 fehlgeschlagen
Am 17.09. um 01:29:52.3631892 CEST meldet Windows erneut nvlddmkm 14/153 mit UCodeReset TDR; danach Resetting/Reset/Restarting und ein neuer LiveKernelEvent 117. Der Kernel-Treiber meldet über nvidia-smi KMD 610.88, PnP 32.0.16.1088 / oem227.inf und das gesicherte Player.log ebenfalls 32.0.16.1088. Das bestätigt mehr als eine Installer-Versionsanzeige. Der Bootzeitpunkt bleibt 16.09. 22:40:30.500 CEST: kein Windows-Neustart. OS-Belege mit Ereignisexporten.
Der Nutzer startete den aktuellen Kandidatenbuild Builds/Windows-ForwardCandidate-20260916, GUID 863b7c4dc60d4b53971aa9bc445b51e2, als normale EXE: D3D11, dreimal alps-02 / Low / Rain / Seed 9909140, ohne Forward- oder Isolationsschalter. Das ist ein manueller Nutzertest und kein deckungsgleicher Wiederholungslauf der automatisierten Forward-Vergleiche. Ergebnis: Der Wechsel auf 610.88 behebt diesen beobachteten Spielabsturz nicht. Eine vergleichende Ausfallrate, exklusive Treiberursache oder ein Hardwaredefekt folgt daraus nicht. Installer-Abschlussdialog und Änderungen optionaler Komponenten wurden nicht eigenständig beobachtet und bleiben unbestätigt.
Die nachträgliche schreibgeschützte NVAPI-Prüfung bestätigt die vier zuvor erfassten Überschreibungen in Base und CurrentGlobal unverändert, einschließlich „Maximale Leistung bevorzugen“. Für die abgefragten Rampage-EXE-Namen/Pfade wurde weiterhin kein eigenes Profil gefunden. Das belegt diese konkreten Werte, keinen vollständigen Erhalt sämtlicher NVIDIA-/App-Einstellungen.
Die gleichzeitig neu veröffentlichten älteren WER-Berichte zählen nicht als neue Abstürze: Zwei Meldungen beziehen sich auf den neuen WATCHDOG-20260917-0129.dmp, 50 weitere auf frühere Vorfälle. Geschützte neue Dump-/WER-Inhalte wurden ohne zusätzliche UAC nicht kopiert; nur die zugänglichen Ereignisse wurden gesichert.
Aktueller Inhalt und Unity 6.6: Die alte Rampage66-Kopie entspricht nicht dem heutigen Spielstand. Ihr damaliger Befund schließt ein Upgrade des aktuellen Inhalts nicht aus. Nach dem Treibervergleich wurde eine frische Kopie von 1.116 aktuellen Projektdateien unter Tools/Diagnostics/CurrentContentUnity66-20260917 vorbereitet. Der getrennte 6.6-Port läuft; ein Build- oder Stabilitätsergebnis liegt noch nicht vor.
Neue Abgrenzung
Der erste historische GBV-Überlauf passt zu _EnableLightLayers im globalen HDRP-Puffer und damit möglicherweise zum Compute-Pass Deferred Lighting. Die fehlende PSO-/Shaderzuordnung bleibt offen. Siehe RenderGraph-Recherche und Forward-Pfad.
Implementiert wurden zwei unabhängig nutzbare Diagnoseoptionen, ohne Änderung normaler Starts:
-rampageForwardRendering: nur die Hauptkamera auf Forward; Landschaft und Effekte bleiben erhalten. Garage-Reflexionen sind unabhängig.-rampageNoNativeRenderPasses: der eindeutig registrierte HDRP-RenderGraph nutzt den bisherigen Compiler/Executor. Der Begriff bezeichnet hier die verwaltete RenderGraph-Option, keinen behaupteten nativen D3D11-Renderpass.
Der passive Flugschreiber liest zusätzlich die bereits vorhandenen, aggregierten HDRP-Kameraeinstellungen über HDCamera.TryGet aus. Er erzeugt keine neue Kamera-/History-Instanz. Fehlende interne API liefert „unavailable“, niemals einen erfundenen Forward-Nachweis. Der Launcher verlangt beim Forward-Vergleich echte effektive Forward-Beobachtungen im Rennen.
Die zwei neuen Inhaltsmodi NoBillboardsFullEffects und NativeBillboardsMinimalEffects trennen die bisher vermischten Änderungen. Historische Modi behalten ihre Bedeutung. Beobachtete Runtime-Flags werden gegen die angeforderte Kombination geprüft.
Bisherige neue Läufe
| Lauf | Konfiguration | Ergebnis |
|---|---|---|
| 23:42:39 | NoBillboardsFullEffects, verborgenes Fenster | Bereits in Garage nach 5 s mit 0 Rendercallbacks abgebrochen. 0 Treiberereignisse. Kein GPU-Absturzbefund und kein brauchbarer Grafikvergleich. |
| 23:45:15 | Sichtbar, alps-02 / Low / Kamera 0 / Seed 707000 / Regen; D3D11 direkt, SRP-Batcher aus; nur Billboard-Submission aus | Zieleinlauf nach 82,03 Rennsekunden, 5.242 Renderframes, keine protokollierten Fehler oder Treiberereignisse. 340 Renderer unterdrückt, deren Ressourcen vollständig erhalten. Lauf ist wegen weniger als 120 Fahrsekunden kein bestandener Stabilitätstest. Profile unverändert/wiederhergestellt. |
| 23:51:40 | Volle Grafik, Forward angefordert, aber durch das Asset tatsächlich Deferred | Erneuter NVIDIA-TDR; letzte Berichtsprobe bei 0,725 Rennsekunden / 406 Renderframes. Kein Forwardvergleich: Der neue effektive Kamera-Observer deckt die Überschreibung auf. Profile unverändert/wiederhergestellt. |
| 00:07:09 | Build mit Both-Unterstützung, tatsächlich Forward; alps-02 / Low / Kamera 0 / Seed 707000, D3D11 direkt und SRP-Batcher aus | Zieleinlauf nach 82,15 Rennsekunden, 5.203 Renderframes, keine protokollierten Fehler/Treiberereignisse. Wegen weniger als 120 Fahrsekunden weiterhin unzureichende Dauer. |
| 00:09:29 | Tatsächlich Forward, Blackpine Classic 0, High, normales multithreaded D3D11 mit SRP-Batcher | Bestanden: 137,70 reale Rennsekunden, zwei abgeschlossene Runden einschließlich Wechsel 1 → 2, 8.596 Renderframes, keine Fehler/Treiberereignisse. Dies ist nicht als identische Strecke des Nutzerabsturzes bestätigt. |
| 00:13:03 | Tatsächlich Forward, High, normale D3D11-Submission; 600-s-Übergangstest alps-02/alps-03, Seed 707000 | Fehlgeschlagen mit NVIDIA-TDR: erster OS-Fehler 63,85 s nach Launcherstart in „safe reset drive“ auf alps-03; nur 1/20 Besuche abgeschlossen, spätere Berichtszeit 81,43 s. Alle 38 verfügbaren Kameraproben bestätigen Forward. Produktionsprofile unverändert und QA-Dateien wiederhergestellt. Forward allein ist damit keine bestätigte Reparatur und wird nicht als Standard übernommen. |
| 00:19:52 | Derselbe Übergangstest, zusätzlich HDRP-RenderGraph-Native-Flag aus | Erneut NVIDIA-TDR nach 328,403 s, im alps-02-Countdown des 11. Besuchs; 10/20 abgeschlossen. Alle 199 verfügbaren Beobachtungen bestätigen tatsächlich Forward und genau einen HDRP-Graph mit Flag false. Kein bestätigter Fix; Profile wiederhergestellt. Genauer Vergleich. |
Der zweite Lauf überschreitet den früheren Ausfall bei 26,8 Rennsekunden mit ansonsten entsprechender Konfiguration. Ein einzelner kürzerer Erfolg beweist weder einen exklusiven Baumshaderfehler noch allgemeine Stabilität.
Nächster konkreter Vergleich
Die ursprüngliche Interpretation des Assetwertes 2 war falsch: HDRP definiert ForwardOnly=1, DeferredOnly=2, Both=3. Der alte Build konnte den Kameraoverride deshalb nicht ausführen und hatte benötigte Forward-Varianten entfernt. Dieser Fehler wurde erst durch die Kontrolle der aggregierten Kameradaten sichtbar, nicht durch den angeforderten Schalter.
RampageBuild.Configure setzt jetzt den symbolischen Wert SupportedLitShaderMode.Both; der native Build prüft ihn und schreibt supportedLitShaderModes in sein Manifest. Der Runtime-Forward-Guard beendet inkompatible Starts vor dem Szenenaufbau. Der Launcher prüft die Capability vor Prozessstart und überwacht den tatsächlichen Pfad bereits während der Fahrt.
Neuer Build: Builds/Windows-ForwardCandidate-20260916, erfolgreich mit Both-Unterstützung; Protokoll forward-candidate-build.log, Provenienz forward-build-provenance.json. Die ersten Fahrten waren fehlerfrei, der längere Übergangstest scheiterte jedoch erneut. Normale Kamerastarts bleiben unverändert Deferred.
Der Paarvergleich mit genau einer zusätzlichen Änderung (-rampageNoNativeRenderPasses) ist ebenfalls fehlgeschlagen. Weder Forward noch der ältere RenderGraph-Ausführungspfad werden zum Standard erklärt. Die unterschiedlichen Ausfallzeiten sind kein bewiesener Stabilitätsgewinn. Nächster Schritt ist die gezielte frühe Frame-Aufzeichnung mit Prüfung der tatsächlichen Shader-/Pufferbindungen, nicht ein weiterer langer Schaltervergleich.
Der portable RenderDoc liegt ausschließlich unter Tools/Downloads/RenderDoc-1.46; keine globale Installation/Hook-Aktivierung. Vor der unten beschriebenen Aufzeichnung wurden nur seine API-Hilfen geprüft. RenderDoc 1.46 macht App-Aufrufe von SetEnableGPUBasedValidation wirkungslos; ein RenderDoc-Capture mit Unity-GBV-Flag wäre deshalb kein erneuter GBV-Nachweis. RenderDoc-Quellcode.
Frühe Frame-Aufzeichnung erfolgreich
Am 17.09. um 00:31:52 wurde genau ein früher DX12-Frame von alps-02 / Low / Seed 707000 / effektiv Deferred aufgezeichnet. Aufruf und Profilprüfung: 29,49 s Gesamtdauer, kein OS-GPU-Ereignis im Abfragefenster, ursprüngliche Produktionsprofile unverändert und alle QA-Dateien restauriert, ausschließlich eigene Prozesse beendet. Die 322-MB-RDC-Datei bleibt lokal. Das eingebettete Vorschaubild wurde visuell geprüft: tatsächliches Startfeld mit Fahrern, Strecke, Landschaft und HUD; kein schwarzer Frame.
Die anschließende rein strukturierte Auswertung (CaptureFile.GetStructuredData, kein OpenCapture, kein Replay-Gerät) extrahierte 14.675 API-Chunks einschließlich 46 Compute-PSOs, 62 Grafik-PSOs, 57 Root-Signaturen und 61 direkten Dispatches. Die Aufzeichnung ist kein Stabilitätstest und keine Wiederholung der historischen GBV-Meldung unter aktiver Validierung. Build-/Dateiprovenienz.
Die abgeschlossene Offline-Bindungsanalyse v4 umfasst 10.137 Prüfungen (239 CS, 6.745 VS, 3.153 PS), null erkannte Bereichsverletzungen und null Parser-Abdeckungslücken. Alle geprüften Bindungen sind eingereichten Command-Listen zugeordnet. 192 Prüfungen enthalten dynamische Indizes mit unbekannten Laufzeitwerten; ein allgemeiner Beweis der Speichersicherheit ist das nicht. Elf synthetische Positiv-/Negativfälle prüfen Parser und Zustandszuordnung.
Auch die 29 indirekten Compute-Aufrufe konnten über ihre reine Dispatch-Command-Signatur ausgewertet werden. Sie lesen jeweils cb0[116].w (Bytes 1868–1871), passend zum früheren Verdacht _EnableLightLayers. Im aktuellen Frame liegen diese Bindungen allerdings korrekt in einem 3.840-Byte-Puffer; kein 1.792-/256-Byte-Überlauf wie im historischen Log. Der Kernelname ist nicht erhalten, und eine Zuordnung zum historischen Dispatch 20 ist nicht bewiesen. Details.
Separate GPU-Validierung und CPU-Stacks
Der historische GBV-Fehler vom 14.09. entstand unter NVIDIA 577.00; die nachfolgenden automatisierten Läufe und die hier beschriebene Frame-/GBV-Auswertung erfolgten unter 616.92. Der neue manuelle Nutzertest oben läuft unter 610.88. Der alte GBV-Fehler ist weder ein frischer Reproduktionsnachweis noch ein Beleg für eine ausschließlich neue 616.92-Regression.
- 00:39:54: Die angeforderten Debug-Layer konnten mangels passender app-lokaler DLL nicht starten. Der normale DX12-Pfad erlitt nach rund 17,56 s erneut einen TDR. Kein gültiger GBV-Lauf. Der Launcher erkennt diesen Aktivierungsfehler inzwischen ausdrücklich.
- Die exakt zum vorhandenen Agility Core passende, signierte
d3d12SDKLayers.dll1.618.1.0.20250923.2 wurde ausschließlich aus dem installierten Unity-Editor in den Kandidatenbuild kopiert. Keine Windows-Installation oder globale Grafikeinstellung. Provenienz. - 00:42:30 / 30 s, 00:43:48 / 60 s und 00:50:21 / 180 s: keine Aktivierungsfehler, aber null Kameraframes, nur erster Home-Sample. Daher kein verwertbares GPU-Validierungsergebnis. Die DLL-Modulnachweise bestätigen die Voraussetzungen, nicht jede intern angeforderte Validierungsfunktion. Alle Versuche beendet, eigene Jobs leer, Profile bytegenau restauriert, keine gemeldeten Treiberereignisse in diesen drei Fenstern.
- Kurze nichtinvasive CPU-Stackaufnahmen im 180-s-Lauf zeigen aktive Kompilierung über
UnityPlayer → D3D12SDKLayers → D3D12Core → nvwgf2umx → nvgpucomp64; derselbe Grafikthread verbraucht zwischen den Messungen 78,375 s CPU in 84,109 s Wandzeit. Langsame Vorbereitung gegenüber einem festlaufenden Compilerpfad bleibt offen; kein Beweis der Ursache normaler Renn-TDRs. Auswertung.
Ein zusätzlich recherchierter DX12-Submission-Fix UUM-120711 ist bereits in Unity 6000.6.0f1 enthalten. Korrektur am 17.09.: Der frühere 6.6.0-Lauf verwendete älteren Spielinhalt; sein protokollierter Fehlschlag schließt nicht aus, dass ein Upgrade mit dem aktuellen Inhalt hilft. Der Nutzer berichtet für die alte Rampage66-Kopie keinen Absturz. Ein inhaltsgleicher aktueller Upgrade-Vergleich steht aus. Der Fix ist weiterhin keine bestätigte Erklärung der D3D11-/Vulkan-Ausfälle. Primärquellen und Abgrenzung.
NVIDIA 610.88 WHQL wurde vollständig heruntergeladen und mit gültiger NVIDIA-Authenticode-Signatur geprüft. Der Nutzer genehmigte anschließend die Installation und den Vergleich ohne Neustart; der aktive Treiber und der erneute manuelle GPU-Reset sind oben belegt. Die Paketprüfung dokumentiert den früheren Vorbereitungszeitpunkt, nicht den späteren Installationszustand. Die Fehlerhistorie unter 577.00 bleibt relevant.
Getesteter Kompatibilitätskandidat
Die noch offene Kombination NativeBillboardsMinimalEffects hat zwei begrenzte Tests bestanden, jeweils mit normalem multithreaded DX11, effektiv Deferred und aktivem SRP-Batcher:
- 00:54:55: alps-02/alps-03, High, 1920×1080-Fenster, 613,85 s / 20 Besuche / 21.416 Renderframes, keine protokollierten Grafikfehler oder NVIDIA-Resets. Native HDRP/Unlit-Karten mit Originalatlanten tatsächlich erzeugt.
- 01:06:00: Blackpine, High, 1920×1080-Fenster, 134,75 reale Fahrsekunden / zwei Runden einschließlich 1 → 2 / 8.469 Renderframes, keine protokollierten Grafikfehler oder NVIDIA-Resets. Blackpine nutzt keine alpinen Karten; diese Prüfung bestätigt den langen Rennablauf mit reduzierten Effekten.
Profile wurden in beiden Fällen unverändert bzw. bytegenau wiederhergestellt. Der separate Kompatibilitätsstart startet den geprüften Build als normales interaktives Spiel mit nativen Baumkarten und reduzierten Effekten. Er verändert keine gespeicherten Grafikpräferenzen; normale Spielstände und Anzeigeeinstellungen gelten. Der ursprüngliche EXE-Start bleibt unverändert. Der Hash-Guard verweigert einen abweichenden Assembly-CSharp-Stand.
Dies ist ein getesteter Ausweichkandidat mit sichtbaren Grafikreduktionen, keine vollständige Absturzreparatur. Wetter, Wolken/Nebel, Schatten, Bildschirm- und Nachbearbeitungseffekte einschließlich Kantenglättung sind aus. Der neue Nutzertest oben auf alps-02 / Low / Rain verwendete den normalen EXE-Start ohne diese Isolation und ist deshalb kein weiterer Test dieses Ausweichkandidaten. Anwendung und Grenzen, Vergleichsauswertung.
Ein separat gefundener Generatorfehler wurde konkret behoben: Tools/Art/prepare_fir_billboard_shader.py erhält bei Regeneration jetzt den eigenen Material-Header mit _StemShape und _StemRootWeight. Die vollständige Generierung wurde im Speicher gegen den aktuellen Shader verglichen: identischer Text, Runtime-Asset bytegleich. Deshalb kein neuer Build nötig und kein behaupteter Zusammenhang mit dem aktuellen TDR.
Das 616.92-Rückkehrpaket wurde zusätzlich aus dem NVIDIA-App-Cache in den Workspace kopiert, mit gleichem SHA-256 und erneut gültiger NVIDIA-Signatur. Beide INF-Dateien enthalten die genaue ASUS-Gerätekennung. Die Kopie selbst änderte das System nicht; der danach separat genehmigte Wechsel auf 610.88 ist oben dokumentiert. Eine Rückkehr auf 616.92 wurde nicht durchgeführt. Vergleichsstand, dauerhafte Rückkehrkopie.
Die lokalen Desktop-Screenshotversuche C:/Users/danie/AppData/Local/Temp/codex-shot-2026-09-17_00-10-02.png und C:/Users/danie/AppData/Local/Temp/codex-shot-2026-09-17_00-13-32.png liefern keinen verifizierten Spielinhalt: Das Skript liest Bildschirmrechtecke und der Browser lag vor dem Spiel. Daraus wird insbesondere kein schwarzes Spielbild abgeleitet. Die zweite Aufnahme wurde wegen der bekannten Browserüberdeckung nicht visuell ausgewertet.