✦ SPIELWELTENMoto Racer - Rampage ↗

RAMPAGE – GPU-Diagnose

Stand: 14. September 2026, nach zwei weiteren Nutzerfehlern um 23:28/23:36 Uhr und gezielter Untersuchung des Blackpine-Starts. Wiederholte Renderstabilität ist nicht bestätigt; die Ursache der GPU-Resets ist offen. Die spätere Nutzeranweisung „Check das mal“ autorisierte die unten dokumentierte kurze Startprüfung. Die früheren Pausen-/Testangaben bleiben als historische Einträge erhalten. Dieser Anhang ergänzt QA-RESULTS.md.

Nutzerabsturz und Einfrieren nach dem Alpen-Build

Der Windows-Build von 23:20 Uhr wurde tatsächlich gestartet; sein Assembly-CSharp.dll-SHA-256 stimmt mit dem Buildnachweis überein (b8260b5eee8c86bcf32dff451f5d7490385999d64e957c7508be11f668a0e783). Das normale Profil und das frühere Aufnahmeprofil standen beide auf High/1920×1080/FOV60. Die alten Aufnahmen stammen aus Fensterläufen; der normale Start verwendet randloses Vollbild. Beide relevanten Player-Logs verwenden Direct3D11, Threaded Rendering und unverändert Treiber 32.0.15.7700. Ein abgeschlossener Treiberwechsel ist damit nicht nachgewiesen.

Die Bedeutung des LiveKernel-Codes117 ist ein nicht rechtzeitig antwortender Grafiktreiber; der Code identifiziert allein keine Anwendungs-, Treiber- oder Hardwareursache. Microsoft TDR117. Das NVIDIA-Capture-Modul war weiterhin geladen; seine bloße Anwesenheit ist unverändert kein Ursachennachweis. Es wurden weder Treiber, Nachtlicht, Registry, TDR-Zeitlimits noch Overlayeinstellungen geändert.

Sichtbare Fehler und gezielte Startprüfung

Der Nutzer-Screenshot zeigte zwei konkrete Projektfehler: Die erste Alpenfassung bildete eine zu nahe, hohe und geschlossene Bergwand; außerdem unterdrückte TMP wegen zu niedriger Textfelder die großen Geschwindigkeits-/Gangziffern. Die Bergkulisse wurde weiter entfernt, reduziert und in vier Massive mit niedrigen Pässen aufgeteilt. Die Instrumentfelder sind ausreichend hoch, verwenden für die großen Ziffern Overflow und lesen weiterhin die tatsächliche Getriebestellung/Geschwindigkeit. Die GANG-Beschriftung liegt getrennt von der Drehzahlskala. Alpenparameter.

Tools/check-startup.ps1 und -rampageTest startup prüfen ausschließlich Schnellstart/Countdown/Startaufstellung. Standard: Blackpine, High, 1920×1080, FullScreenWindow, manuelles Getriebe. Sie erzeugen Countdown-/Startbilder, Sekunden-Telemetrie und eine Abschlussdatei, prüfen Prozess-Exitcode, natives Log und NVIDIA-Windows-Ereignisse. Das Produktionsprofil samt Backup wird vor/nach dem Lauf per SHA-256 und Metadaten verglichen. Das QA-Profil bleibt separat; es findet kein vollständiger Renn-/Controller-/Cup-Test statt. Hauptkamera-Callbacks sind weiterhin kein alleiniger Nachweis einer korrekt präsentierten GPU-Ausgabe; deshalb werden Bilder und Windows-Ereignisse mitbewertet.

Der erste gezielte Lauf um 23:46:32 beendete den Countdown und erreichte 9,51 s Rennzeit: 12,50 s ab race ready, 743 Frames/743 Rendercallbacks, 0 gemeldete Fehler, Exit 0 und 0 NVIDIA-Ereignisse. Ausführungs-/Profilnachweis. Die Bilder bestätigen sichtbare 0/1-Ziffern und freien Himmel. Sie deckten zusätzlich eine noch zu niedrige KM/H-Zeile und starke Gegenlicht-Silhouetten auf. Daraufhin wurde die KM/H-Zeile auf 28 Referenzeinheiten erhöht; nur im Wald wurden Sonnenazimut/-höhe auf 310°/35° und HDRI-Rotation auf 300° gesetzt, bei unveränderter Intensität/Belichtung. Dies ist eine visuelle Korrektur, kein behaupteter GPU-Fix.

Der korrigierte Windows-Build von 23:51:59 ist erfolgreich erstellt (0 Buildfehler). Der abschließende Startlauf um 23:53:13 bestätigt 30,53 s ab race ready, 27,55 s Rennzeit, 1.824 Frames/1.824 Rendercallbacks, Exit 0, 0 Laufzeitfehler und 0 NVIDIA-Ereignisse. Das echte Profil und Backup sind unverändert. Ausführungsnachweis. Die unveränderte Countdownaufnahme bestätigt sichtbare Ziffern samt KM/H/GANG, einen freien Himmel und beleuchtete Felsflächen statt der dunklen Wand. Die Form der Berge bleibt vereinfacht; keine fotorealistische AAA-Abnahme. Der Spieler bleibt in dieser Probe weitgehend am Start stehen, während die Gegner losfahren. Der einzelne kurze Lauf ist keine Langzeit-/Rennstabilitätsfreigabe und kein Nachweis, dass die früheren Resets behoben sind.

Testumgebung und beobachtete Läufe

Unity 6000.3.24f1, HDRP 17.3.0, NVIDIA RTX 4060 Laptop GPU, Treiber 577.00 (32.0.15.7700). Die späteren Waldläufe verwenden, soweit unten nicht abweichend angegeben, 1920 × 1080, Grafik Hoch, vollständige Umgebung und acht Fahrer. Rennzeit und Echtzeit seit Beginn der Rennmessung sind unterschiedliche Messgrößen; die Telemetriezeit beginnt nach dem Laden und ist nicht die gesamte Prozesslaufzeit.

Lauf am 14.09.2026 Konfiguration Beobachtung
18:17:23 DX11, Graphics Jobs aktiv Bereits beim Laden schlagen GPU-Puffererstellungen mit 0x887A0005 fehl; kein erfolgreicher Abschlussbericht.
18:22:20 DX11, Graphics Jobs aus, Scenery aus Log erreicht „race ready“, anschließend beobachteter GPU-Hänger; kein erfolgreicher Abschlussbericht. Windows verweist auf WATCHDOG-20260914-1822.dmp.
19:19:01 DX12, vollständiger Wald Nativer Absturz: Present fehlgeschlagen, Device-Removed-Grund 0x887A0005. Letzte gespeicherte Telemetrie: 100,049 s seit Messbeginn / 97,122 s Rennzeit.
19:29:15 DX12, Async Compute aus Zwei Spielerrunden abgeschlossen: 136,929 s Rennzeit; 59,958 fps Mittel / 58,776 fps 1%-Low; 100 % gemessene Renderabdeckung; 0 gemeldete Laufzeitfehler und 0 Fahrerstürze.
19:35:36 DX12, Async Compute weiterhin aus Erneuter nativer Absturz: Present 0x887A0005, Device-Removed-Grund 0x887A0007. Letzte Telemetrie: 90,222 s seit Messbeginn / 79,749 s Rennzeit.
19:38:05 DX12, Async Compute aus, Debug-Flag angefordert Zwei Spielerrunden abgeschlossen: 136,929 s; 59,972 / 58,964 fps; 100 % Renderabdeckung; 0 gemeldete Laufzeitfehler und 0 Fahrerstürze. Die Debug-Layer wurde jedoch nicht aktiviert.
19:45:09 Vulkan, vollständiger Wald angefordert Initialisierung bleibt bei InitializeOrResetSwapChain 1920x1080 hdr=0 samples=1 hängen, vor dem ersten Frame. Kein Renn-/Abschlussbericht; im Integrationslauf erfasster Prozess-Exitcode -805306369 nach ungefähr sieben Minuten. Kein Vulkan-Leistungsnachweis.
19:52:16 DX12, -force-gfx-direct, Async Compute aus Zwei Spielerrunden abgeschlossen: 136,920 s Rennzeit; 59,865 fps Mittel / 53,895 fps 1%-Low; 100 % Renderabdeckung; 0 gemeldete Laufzeitfehler und 0 Fahrerstürze. Das Log bestätigt kGfxThreadingModeDirect.
19:54:43 DX12, erneut -force-gfx-direct Nativer Absturz mit Device-Removed-Grund 0x887A0007; kein Abschlussbericht. Letzte Telemetrie: 60,076 s seit Messbeginn / 57,121 s Rennzeit, acht Fahrer am Boden, 0 Fahrerstürze. Direct-Threading allein verhindert den Reset nicht.
20:05:41 DX12, passende app-lokale Debug-Layer, Volumetrik an Debug-InfoQueue und DRED verfügbar, trotzdem nativer 0x887A0007. Letzte Telemetrie: 20,007 s seit Messbeginn / 17,071 s Rennzeit; kein Abschlussbericht.
20:06:43 DX12, passende app-lokale Debug-Layer, Volumetrik aus Erneut nativer 0x887A0007, trotz verfügbarer Debug-InfoQueue und DRED. Letzte Telemetrie: 40,050 s seit Messbeginn / 37,118 s Rennzeit; kein Abschlussbericht.
20:08:11 DX12, GPU-basierte Validierung Kein Abschlussbericht; der Integrationsaufruf überschritt seine Fünf-Minuten-Grenze. Das gespeicherte Log enthält 83 GPU-Validierungsfehler ID 961 wegen Konstantenpufferzugriffen außerhalb des verfügbaren Ressourcenbereichs; Details unten. Kein Performance-Nachweis unter dieser Instrumentierung.
20:13:27 DX11 BitBlt, Async Compute und Volumetrik aus Zwei Spielerrunden abgeschlossen: 134,951 s, 1920 × 1080; 59,934 fps Mittel / 58,521 fps 1%-Low, P99 16,986 ms. Alle 7.608 gemessenen Frames gerendert; 0 Laufzeitfehler und 0 Fahrerstürze. Erfolgreicher einzelner Fahr-/Performance-Lauf.
20:16:00 DX11 BitBlt, erneut Async Compute und Volumetrik aus Zwei Spielerrunden abgeschlossen: 134,942 s; gemeldete Endauflösung 2563 × 1444. 57,588 fps Mittel / 11,719 fps 1%-Low, P99 17,003 ms. Alle 7.568 gemessenen Frames gerendert; 0 Laufzeitfehler und 0 Fahrerstürze. Rennabschluss bestanden, gleichmäßige 60-fps-Darstellung nicht bestanden.
20:29:14 DX12, SRP Batcher aus, GPU-basierte Validierung angefordert Nach der auf 210 s begrenzten Wartezeit auf das Laden abgebrochen. Das Log endet bei RAMPAGE_LOAD begin 0; weder „race ready“ noch Telemetrie oder Abschlussbericht vorhanden. 0 gespeicherte Konstantenpuffer-Validierungsfehler, aber kein Nachweis eines erfolgreich geprüften Rennframes: Ergebnis nicht aussagekräftig zur Behebung.
20:33:34 DX12, SRP Batcher aus, normaler Lauf ohne GPU-basierte Validierung Acht Fahrer geladen, „race ready“ erreicht; anschließend nativer GPU-Reset mit Present 0x887A0005, Device-Removed-Grund 0x887A0007. Letzte Telemetrie: 13,798 s seit Messbeginn / 3,485 s Rennzeit, acht Fahrer am Boden, 0 Fahrerstürze. Kein Abschlussbericht. SRP Batcher auszuschalten verhindert den Reset nicht.
20:45:37 DX11 BitBlt, Red Mesa Rush, SRP Batcher an, Async Compute und Volumetrik aus Nach „race ready“ 44 native Puffererstellungsfehler 0x887A0005 und fehlgeschlagene Bildschirmaufnahme. Bericht runStatus=errors, 10,111 s Rennzeit, 419,888 m, 0 Fahrerstürze, finished=false, performanceTargetMet=false. Angeforderter 25-s-Aufnahmelauf, kein vollständiger Performance-Lauf. Auch diese DX11-Konfiguration ist nicht als stabil bestätigt.

Die erfolgreichen Einzelrennen widerlegen den zwischenliegenden Absturz nicht. Gemessen wurden CPU-Bildintervalle mit Bestätigung tatsächlich gerenderter Frames, keine GPU-Timer. Die letzte Telemetrie liegt vor dem jeweiligen Absturz und bestimmt dessen exakten Zeitpunkt nicht.

Windows- und Speicherevidenz

Die schreibgeschützt gelesenen Windows-Ereignisse zeigen am selben Tag, jeweils Ortszeit CEST:

Die Dumpnamen stammen aus den Ereignismeldungen; der Zugriff auf den Kernel-Dumpordner wurde verweigert. Ältere WER-Berichte wurden zugleich erneut protokolliert und zählen nicht als zusätzliche aktuelle Abstürze.

Die NVIDIA-Ereignisdaten nennen einen TDR auf GPUID:100 und die Stufen UCodeReset, Resetting, Reset, Restarting. Windows protokolliert dazu Rampage.exe/UnityPlayer.dll als Application Error 1000 um 19:21:02 und 19:37:14 mit Ausnahme 80000003.

Beide DX12-Absturzlogs melden ausdrücklich keinen lokalen oder nichtlokalen Speichermangel: lokal 883.736.576 B beziehungsweise 955.170.816 B bei 7.538.212.864 B Budget. In sämtlichen gespeicherten numerischen Telemetriewerten dieser beiden Läufe – 1.969 beziehungsweise 1.790 Werte – wurden keine NaN-/Infinity-Werte gefunden. Das prüft die gespeicherte Spieltelemetrie, nicht sämtliche GPU-Ressourcen oder Shaderwerte.

Die begleitende Prüfung mit dem nativen nvidia-smi.exe meldete um 19:39:19 77 °C und 52,85 W, um 19:40:07 78 °C und ungefähr 52 W; thermische und Hardware-Power-Brake-Drosselung waren inaktiv. In den vorangegangenen 30 Minuten fanden sich keine WHEA-/Kernel-Power-Ereignisse. Das sind Momentaufnahmen, keine lückenlose Aufzeichnung während der Resets. Die Befunde belegen GPU-Timeouts/Resets, unterscheiden aber nicht zuverlässig zwischen Anwendungsbefehlen, Engine, Treiber und Hardware als Ursache.

Der Nutzer bestätigt weiterhin ausdrücklich, dass andere Spiele auf diesem Rechner stabil laufen. Das ist eine relevante Nutzerbeobachtung, keine durch diese QA kontrolliert gemessene Vergleichsreihe. Eine allgemeine Hardwareinstabilität ist durch die vorliegenden RAMPAGE-Befunde nicht nachgewiesen.

Grenzen der bisherigen Diagnose

Der frühere Debug-Lauf meldete could not get the debug interface (0x887a002d) und verwies auf „Graphics Tools“. Die daraus zunächst abgeleitete Aussage, die Windows-Systemkomponente fehle und eine Installation mit Administratorrechten sei nötig, war unzutreffend. C:/Windows/System32/d3d12SDKLayers.dll war bereits vorhanden, Version 10.0.26100.9278, mit gültiger Microsoft-Windows-Signatur. Im Build lag dagegen D3D12Core.dll aus Agility 1.618.1, zunächst ohne seine passende app-lokale Debug-Layer. Microsoft dokumentiert, dass Runtime und Debug-Layer dieselbe SDK-Version benötigen. Agility-Spezifikation.

Aus dem offiziellen Microsoft-NuGet-Paket 1.618.1 wurde ausschließlich die x64-Debug-Layer für den Diagnose-Build bereitgestellt und nach Builds/Windows/D3D12/D3D12SDKLayers.dll kopiert: Version 1.618.1.0.20250923.2, 4.930.104 B, Authenticode Valid / Microsoft Corporation, SHA-256 C0730CC70D3250D3DE19C04C17845BA9E70EECAF502D684D1409195EBC5B5959. Die vorhandene Core-DLL stimmt per SHA-256 exakt mit derselben Paketversion überein. Datei- und Signaturnachweis. Keine OS-Installation oder globale Änderung war erforderlich. Die Logs um 20:05:41 und 20:06:43 bestätigen das Laden der app-lokalen SDK-Layer und die nun verfügbare Diagnose. Das korrigiert die Diagnoseeinrichtung, nicht den weiterhin auftretenden GPU-Reset.

Beide dieser Debug-Läufe melden 0 gespeicherte / 0 gefilterte IDXGIInfoQueue-Meldungen, Starting DRED v1.2 und DRED GPU Page Fault VA: 0. Sie enthalten keine auswertbaren Breadcrumbs und enden dennoch mit 0x887A0007. Die lokalen Speicherbelegungen sind 953.999.360 B bei Volumetrik an beziehungsweise 907.796.480 B bei Volumetrik aus, jeweils bei 7.538.212.864 B Budget; beide Logs verneinen lokalen und nichtlokalen Speichermangel. Leere Meldungslisten und eine Fault-Adresse von null identifizieren weder einen fehlerfreien GPU-Befehlspfad noch die Reset-Ursache. Der Vergleich belegt lediglich, dass abgeschaltete Volumetrik in diesem Lauf keine ausreichende Abhilfe war.

HDRP führt die betreffenden Effekte bei deaktiviertem Async Compute synchron aus; die Effekte selbst bleiben erhalten. Der wiederholte Absturz mit Async Compute aus zeigt, dass diese Änderung allein keine belegte Lösung ist. HDRP-Referenz.

Unity UUM-140183 beschreibt einen ähnlichen DX12-Present-Absturz bei RenderGraph, EnableAsyncCompute(true) und UseTexture, auch auf einem NVIDIA-Laptop. Der Fehler ist jedoch seit 6000.3.18f1 behoben; die verwendete Version 6000.3.24f1 enthält diese Korrektur. Eine gemeinsame Ursache ist damit nicht nachgewiesen. Offizieller Unity-Issue.

Die offiziellen NVIDIA-577.00-Release-Notes nennen vier offene, spielspezifische Probleme bei Cyberpunk 2077, Battlefield 2042, World of Warcraft und Counter-Strike 2; sie enthalten keinen passenden Unity-/HDRP-Reset-Eintrag. Die RTX 4060 Laptop GPU ist ausdrücklich unterstützt. Daraus folgt weder eine bestätigte Treiberursache noch deren Ausschluss. NVIDIA-Release-Notes, S. 14–15 und 33.

GPU-basierte Validierung: konkrete Pufferfehler

Das Log des Laufs 20:08:11 enthält bei erneuter Dateiprüfung 83 Zeilen d3d12 validation error, sämtlich Kategorie 9 / ID 961: 61 Vertex-, 19 Compute- und 3 Pixel-Shader-Meldungen. Die geprüfte Datei hat 78.611 B, Änderungszeit 20:13:11,226 CEST und SHA-256 D980617D7F4C0FE7179A51F8D28D5CDBA81BDB4B06090367929F15247E7A0FE2. Eine zwischenzeitlich genannte Zahl von 93 ist durch diese gespeicherte Datei nicht belegt.

Die erste Meldung in Zeile 49 betrifft einen Compute-Dispatch, Root-CBV-Parameter 0, Dispatch 20: höchster gelesener Byteoffset 1871, bei 1792 verbleibenden Bytes ab dem gebundenen Start. Danach folgen Vertex-Zugriffe bei Draw 1209 bis Byte 779, mit nur 256 verbleibenden Bytes, sowie Zugriffe auf 335, 351, 367 und 383. Weitere Compute-Zugriffe lesen Byte 831 bei 256 verbleibenden Bytes. „Verbleibende Bytes“ bezeichnet hier den Rest der zugrunde liegenden Ressource ab dem View-Start, nicht zwingend die deklarierte CBV-Größe. Shaderdateien und Ressourcen sind im Log nicht namentlich aufgelöst.

Die installierte HDRP-Datei ShaderVariablesGlobal.cs.hlsl deklariert einen 3.792-Byte-Globalpuffer an Register b0. Die gemeldeten Offsets passen zu dessen Layout: 335–383 liegen in _ViewProjMatrix, 779 in _WorldSpaceCameraPos_Internal, 831 in _PostProcessScreenSize und 1871 in _EnableLightLayers. Das ist ein konkreter Hinweis auf die gemeinsame Konstantenpufferbindung beziehungsweise deren Bereich oder Lebensdauer. Eine Ursache in Unitys nativer Pufferverwaltung bleibt eine Hypothese: Root-Parameterindex 0 allein beweist die Registerzuordnung nicht, und die Verbindung zwischen diesen Validierungsfehlern und den früheren TDRs ist noch nicht isoliert. Der Projektcode bindet keine eigenen ConstantBuffer/ComputeBuffer; die Fehler betreffen zudem mehrere Shaderstufen und sind daher nicht allein einem instanzierten Mesh zugeordnet.

Der nächstliegende offizielle Unity-Fall ist UUM-104763: DX12 liefert falsche Konstanten bei CommandBuffer.DrawProcedural und DispatchCompute. Die dokumentierte Korrektur verhindert die Wiederverwendung temporären Konstantenpufferspeichers außerhalb des jeweiligen CommandBuffers und ist als 6000.6.0b1 aufgeführt; eine entsprechende 6.3-Korrektur wurde bei dieser Prüfung nicht gefunden. Der Fall beschreibt Farbflackern, nicht exakt RAMPAGEs ID-961-/Reset-Verhalten. Er stützt den zu prüfenden Mechanismus, bestätigt aber keine identische Ursache. Unity-Issue UUM-104763, offizielle Beschreibung der Korrektur.

SRP Batcher aus: Laden ohne Ergebnis und erneuter Reset

Der instrumentierte Lauf 20:29:14 war auf 210 Sekunden Wartezeit begrenzt und erreichte keinen nachgewiesenen Rennstart. Seine 1.639-Byte-Logdatei enthält keine d3d12 validation error-Zeile und endet unmittelbar nach RAMPAGE_LOAD begin 0; auch eine erfolgreiche Aktivierung beziehungsweise vollständige Ausführung der Validierung über die Rennszene ist darin nicht bestätigt. Ohne „race ready“, Telemetrie oder Abschlussbericht ist der Lauf weder eine erfolgreiche Wiederholung noch ein Beleg, dass die früheren ID-961-Zugriffe beseitigt wurden. SHA-256 der geprüften Logdatei: c0464c119c9bc73d21b9908b485e9e6617f22b33a56db33dd474d2f80468f854.

Der anschließende normale Lauf 20:33:34 erreichte mit deaktiviertem SRP Batcher die vollständige Rennszene und endete erneut mit 0x887A0007. Die letzte von zwei Telemetriezeilen meldet Racing, 13,798 s seit Messbeginn und 3,485 s Rennzeit. Alle acht Fahrer sind zu diesem Zeitpunkt auf der Straße und am Boden; Stürze und Trefferereignisse stehen bei null. Der Zeitstempel bestimmt den späteren Resetzeitpunkt nicht. Das Log verneint lokalen und nichtlokalen Speichermangel; die lokale Nutzung beträgt 818.180.096 B bei 7.538.212.864 B Budget. SHA-256 der 19.953-Byte-Logdatei: afc729db872ae537bedce7972db67d996f1d0b7925284147ddd69a82084bd148.

Damit ist SRP Batcher aus als alleinige Abhilfe widerlegt. Der normale Lauf war keine GPU-basierte Validierung und kann die Konstantenpufferfehler weder bestätigen noch ausschließen. Die Verbindung zwischen diesen Fehlern und den Resets sowie die genaue Fehlerursache bleiben offen.

DX11-BitBlt: Laufabschluss und langsame Frames getrennt bewerten

Beide BitBlt-Berichte melden completed, performanceValid=true, vollständige Renderabdeckung und keine Fehler, Stürze oder unerwartete Pause. In der Harness-Version dieser beiden Läufe prüfte performanceValid jedoch nur die Verwendbarkeit der Messung anhand von Fortschritt, Renderabdeckung, Fehlerfreiheit und Stichprobengröße; es erzwang keine 60-fps-Grenze. Der zweite Lauf bleibt deshalb trotz gültiger Messung ein negativer Befund für die gleichmäßige Darstellung. Die anschließend ergänzte Prüfung performanceTargetMet und die Aufzeichnung von Startauflösung, Auflösungswechseln und langen Frames sind in diesen älteren Berichten noch nicht enthalten.

Im Telemetrieintervall von 100,095 bis 110,104 s Echtzeit steigen die Rennsekunden nur von 97,120 auf 102,650: Die Differenz zwischen Echt- und Rennzeit wächst dort um 4,479 s, während die Oberfläche weiter Racing meldet. Andere Zehn-Sekunden-Intervalle dieses Laufs folgen der Rennzeit eng. Die Anwendung begrenzt Time.maximumDeltaTime auf 0,1 s; das Muster ist mit einem oder wenigen langen Frames vereinbar. Der nahe 17-ms-P99-Wert bei zugleich schlechtem Mittel der langsamsten 1 % stützt diese Einordnung. Rohe Frameintervalle mit Zeitstempeln wurden nicht gespeichert; die konkrete Ursache des Ausreißers lässt sich daraus nicht bestimmen.

Zusätzlich speichert der Bericht die Bildschirmgröße erst am Laufende: 2563 × 1444 gegenüber 1920 × 1080 beim ersten BitBlt-Lauf. Zeitpunkt und Ursache einer möglichen Größenänderung fehlen. Daher liegt keine kontrollierte Wiederholung mit nachgewiesen identischer Auflösung über den gesamten Lauf vor. Diese Einschränkung erklärt den langsamen Frame nicht und hebt den gemessenen Einbruch nicht auf.

Erneuter DX11-Fehler und Prüfung des vollständigen Prozesslogs

Das Log um 20:45:37 bestätigt Unity 6000.3.24f1, Direct3D 11, den Threaded-Renderpfad und Treiber 577.00. Nach dem Aufbau aller acht Fahrer steht in Zeile 41 RAMPAGE_LOAD race ready. Zeilen 42–70 enthalten 28 native failed to create buffer-Meldungen und die fehlgeschlagene Bildschirmaufnahme; Zeile 71 enthält bereits den JSON-Bericht. Weitere 16 native Fehler folgen in Zeilen 72–87, bevor Physik und Eingabe regulär heruntergefahren werden. Insgesamt sind es 44 native Fehler, jeweils 0x887A0005, verteilt auf je 22 Meldungen mit target 0x5 und target 0x2. Die geprüfte Datei hat 12.018 B, SHA-256 977E9C87291C97FF05A9908ED638BD74441526BE2ABE79FB1E525E277FB43D3D.

Der HRESULT meldet ein bereits entferntes Grafikgerät; die danach fehlgeschlagenen Allokationen identifizieren weder das ursprünglich auslösende Mesh noch einen bestimmten Konstantenpuffer. Der DX11-Lauf besitzt keine entsprechende CBV-Validierung. Damit belegt er einen weiteren nativen Gerätefehler, aber keine gemeinsame Ursache mit den 83 ID-961-Meldungen des DX12-Laufs 20:08:11. Ebenso lieferte der normale DX12-Lauf 20:33:34 einen Reset und keinen erneuten validierten CBV-Befund. Die drei Beobachtungen dürfen nicht zu einem bewiesenen einzelnen Shader-/Engine-Fehler zusammengezogen werden.

Der neuere DX11-Bericht meldet zwar 100 % Renderabdeckung der 85 gemessenen Frames, aber nur 29,846 s seit Messbeginn / 10,111 s Rennzeit, errors=1, timedOut=true, performanceValid=false und performanceTargetMet=false. Die eine verwaltete Fehlermeldung ist ausschließlich Failed to capture screen shot; die 44 nativen Fehler werden von diesem Zähler nicht erfasst. 33,950 fps Mittel / 0,997 fps 1%-Low beschreiben diese fehlerhafte kurze Aufnahme, keinen gültigen 1080p-Benchmark. Die Auflösung blieb laut Bericht bei 1920 × 1080, alle acht Fahrer waren zuletzt am Boden und ohne Sturz.

qa-log-check.ps1 wird deshalb von den Startskripten für Rennen, Controller-, Ablauf- und Kampftests nach Prozessende auf das vollständige Log angewandt. Der Guard verwirft fehlende/leere Logs, die Geräte-HRESULTs 887A0005/6/7, symbolische DXGI-Fehler, einschlägige Device-/Swapchain-Fehler, native GPU-Validierungsfehler und fehlgeschlagene Aufnahmen. Nichtfatale InfoQueue-Abfragen und eine nicht verfügbare optionale Debug-Schnittstelle gelten allein nicht als Gerätefehler. Die erste Offline-Verifikation bestand 24/24 Werkzeugprüfungen, darunter die echten DX11-/DX12-Fehllogs und drei erfolgreiche Funktionslogs. Die unten beschriebene Ergänzung erhöht die aktuelle Offline-Verifikation auf 30/30 bestanden, 0 fehlgeschlagen; sämtliche historischen Testlogs blieben per Hash unverändert. Das sind Prüfungen der Auswertung, keine zusätzlichen Spiel- oder GPU-Stabilitätstests.

Die ergänzende schreibgeschützte Prüfung zeigte zunächst eine konkrete Lücke: Dieser Guard verwarf das DX11-Log mit 46 passenden Zeilen (44 native Fehler plus Aufnahmetext und dessen JSON-Wiedergabe), akzeptierte aber das DX12-Validierungslog 20:08:11 trotz seiner 83 ID-961-Meldungen. Diese Auswertungslücke ist jetzt korrigiert: Der Guard erkennt Unity-, DirectX- und eigenständige GPU-Validierungsfehlermeldungen, ohne eine bloße Aktivierung der Validierung abzulehnen. Der echte gespeicherte Lauf wird nun abgewiesen; ein separater Test bestätigt seine exakt 83 ID-961-Meldungen. Bloße Abwesenheit eines Reset-HRESULTs bestätigt weiterhin keine gültige Pufferbindung. Diese Korrektur betrifft die Testauswertung, nicht die GPU-Fehlerursache.

Die Startskripte verlangen zusätzlich ein lesbares JSON-Ergebnis und einen Prozess-Exitcode 0; ein fehlender Bericht, syntaktisch abgeschnittenes JSON, ein Abbruch durch die Zeitgrenze oder ein späterer Prozessfehler gelten nicht als Erfolg. Für normale Rennen ist -RequirePerformance wesentlich: Es lehnt einen fehlenden oder falschen performanceTargetMet-Wert ausdrücklich ab. Ohne diesen Schalter ist ein fehlerfreier kurzer duration-limit-Lauf absichtlich zulässig und darf nicht als vollständige Renn-/Performance-Freigabe bezeichnet werden. Der einfache Logscanner allein überprüft weder Berichtsvollständigkeit noch Rennabschluss; die Auswertung muss diese Bedingungen gemeinsam anwenden.

Historischer Unity-6000.6.0f1-Lauf mit älterem Inhalt: Rennen fehlgeschlagen, Minimalprobe bestanden

Korrektur am 17.09.2026: Der Nutzer hat ausdrücklich auf den veralteten Inhalt von Rampage66 hingewiesen und berichtet, dass diese Kopie bei ihm nicht abstürzt. Die unten erhaltenen historischen Logs dokumentieren ihre jeweiligen damaligen Läufe. Sie sind kein inhaltsgleicher A/B-Vergleich mit dem aktuellen Hauptprojekt und schließen eine Verbesserung durch Unity 6.6 mit dem heutigen Inhalt nicht aus.

Der vollständige Windows-Installer stammt aus dem auf der offiziellen Unity-6000.6.0f1-Seite verlinkten Download. Das Downloadprotokoll bestätigt 3.858.564.328 B, den erwarteten MD5 512ff3ded6f28bc5761ed22891b58a6d und SHA-256 6bbbb6f782dba90822495c3bd7a796e7698748aa6aa5ec5a2c3b466083cc86ea. Die Authenticode-Prüfung meldet Valid / Unity Technologies SF. Ein verifizierter Download ist noch kein erfolgreicher Vergleichsbuild.

Die erste Installation unter Tools/Downloads/Unity66/6000.6.0f1 endete laut Integration mit Exitcode 0. Der anschließende isolierte Build scheiterte jedoch an drei unterschiedlichen C#-Fehlern in eingebauten Render-Pipeline-Paketen: fehlender Typ MaterialReferenceChanger sowie fehlende Methoden TryMigrateRenderingLayersToTagManager und ClearMigratedRenderPipelines. Die Integration fand ausgelassene lange Paketdateinamen. Die abgeschlossene Neuinstallation desselben verifizierten Installers unter C:/Unity Editors/6000.6.0f1 und die frische Projektkopie C:/Unity Projects/Rampage66 beseitigten die fehlenden Paketdateien und sämtliche eingebauten Kompilierfehler. Ausschließlich in der Kopie wurden anschließend vier veraltete GetInstanceID()-Verwendungen auf GetEntityId() beziehungsweise dessen Hash für Ganzzahl-Seeds angepasst. Der spätere Spielerbuild wurde ausgeführt; die folgenden Originalberichte und Logs wurden unter Docs/QA/Unity66 in das Hauptprojekt kopiert. Das Hauptprojekt bleibt laut ProjectVersion.txt bei 6000.3.24f1.

Die Vergleichsvorbereitung verwendet Basiscommit 4b849bde67cc3b0d5153f205de5c451512b47c9b und neben der neuen Engine auch HDRP/Core 17.6.0 und uGUI 2.6.0. Weitere tatsächlich aufgelöste Paketversionen müssen aus dem Vergleichsbuild festgehalten werden. Dies ist ein Vergleich des Rendering-Stacks, keine isolierte Prüfung ausschließlich der nativen UUM-104763-Korrektur; die Basis liegt zudem vor den neuesten Grafik-/UI-Änderungen des Hauptprojekts.

Der erste normale Vergleich wurde mit Wald, 180 s Zeitbudget, Qualität Hoch, vollständiger Umgebung, acht Fahrern, 1920 × 1080, DX12, SRP Batcher an, Async Compute und Volumetrik aus, ohne Screenshots angefordert (-Track 0 -Seconds 180 -Quality 2 -NoCapture -RequireFinish -RequirePerformance -GraphicsApi Direct3D12). Gefordert waren Rennabschluss, fehlerfreies vollständiges Prozesslog, Exitcode 0, mindestens 98 % Renderabdeckung, stabile Auflösung sowie mindestens 59 fps Mittel / 50 fps 1%-Low. Die tatsächlichen Ergebnisse sind getrennt zu bewerten:

Lauf Gesicherte Beobachtung Aussagegrenze
21:38:06 – vollständiger Wald Unity 6000.6.0f1, DX12, Treiber 32.0.15.7700. Present 0x887A0005, Device-Removed-Grund 0x887A0007. Lokale Nutzung 904.708.096 B bei 7.538.212.864 B Budget; Log verneint lokalen und nichtlokalen Speichermangel. Letzte Telemetrie: 134,062 s seit Messbeginn / 111,168 s Rennzeit; acht Fahrer am Boden, keiner gestürzt oder fertig. Kein erfolgreicher Abschlussbericht für diesen historischen Projektstand; kein gültiger Vollspiel-Performance-Nachweis. Die Wirkung eines Upgrades des heutigen Inhalts bleibt offen.
21:47:36 – Minimalprobe DX12, 1920 × 1080, 180,010 s, 10.731 Frames, davon 10.730 Renderbestätigungen, 0 gemeldete Fehler, finished=true. Das Prozesslog erreicht RAMPAGE_PROBE_FINISHED minimal und reguläres Herunterfahren. Einfache HDRP-Würfel-/Kugel-Szene ohne RAMPAGE-Anwendung, UI, Audio, Rennphysik oder Weltgenerierung. Der erfolgreiche Einzeltest ist keine Freigabe des vollständigen Spiels und schließt einen intermittierenden Engine-/Treiberfehler nicht aus.
21:51:28 – Beleuchtungsprobe Log erreicht RAMPAGE_PROBE_READY lighting. Um 21:53:49 CEST bewusst beendet, um das vom Nutzer begonnene GeForce-Experience-/Treiberupdate nicht mit GPU-Arbeit zu überlagern; Unterbrechungsnachweis, status=interrupted. Weder erfolgreicher Abschluss noch nachgewiesener GPU-Fehler dieser Probe. Keine Stabilitätswertung aus dem absichtlichen Abbruch.

Die Anwendbarkeit von UUM-104763 auf den aktuellen Inhalt bleibt ungeklärt. Die seit 6000.6.0b1 dokumentierte Konstantenpufferkorrektur war im damaligen Stack enthalten, und der protokollierte historische Waldlauf schlug trotzdem fehl. Wegen des abweichenden Projektstands kann dieser Befund weder den heutigen Fehler derselben Ursache zuordnen noch einen aktuellen Upgrade-Vergleich ersetzen. Neben der Engine unterscheiden sich Render-Pipeline-Pakete und Spielinhalt. Der Minimaltest zeigt lediglich, dass eine einfache HDRP-Szene auf diesem System in diesem 180-s-Lauf erfolgreich renderte.

NVIDIA-Capture-Modul: geladener Fremdcode, Ursache unbewiesen

Die schreibgeschützte Modullistenprüfung durch den World-Agenten (Astra) fand C:/Windows/System32/nvspcap64.dll, Version 3.27.0.120, im 6.3-Absturz 19:19:01 (Zeile 134), im 6.3-Absturz 19:35:36 (Zeile 133) und im 6.6-Absturz 21:38:06 (Zeile 134). Die lokale Dateiprüfung ergab NVIDIA Corporation, Beschreibung NVIDIA Game Proxy, Produkt NVIDIA GeForce Experience, Authenticode Valid. Das ist ein anderer Bestandteil als die Treiber-DLLs mit Version 32.0.15.7700.

Auch der damals laufende Minimalprobenprozess PID 41020 hatte dasselbe nvspcap64.dll sowie nvppex.dll geladen. Diese Live-Abfrage wurde in der Arbeitskommunikation festgehalten, jedoch nicht als separates Rohdatenartefakt gespeichert. Da die Minimalprobe anschließend erfolgreich endete, ist die bloße Anwesenheit des Moduls kein hinreichender Fehlernachweis. Die Momentaufnahme zeigte keine Prozesse mit den Namen NVIDIA Share, NVIDIA GeForce Experience oder NVIDIA Overlay; daraus folgt weder, dass Aufzeichnung sicher inaktiv war, noch dass geladene Hooks unwirksam waren. Im überprüften 6.6-Crashlog wurden keine RTSS-, ReShade-, Discord-, Steam- oder Overwolf-Overlay-Module anhand der gesuchten Modulnamen gefunden. Diese Namenssuche ist kein vollständiger Ausschluss jeglicher Fremdintegration.

NVIDIA-Mitarbeiter erklären, dass die Erkennung durch GeForce Experience keine unterstützte programmatische Opt-out-Schnittstelle pro Anwendung anbietet und die Hook-Erkennung proprietär ist. Als kontrollierter Vergleich kommt daher das bewusste Abschalten des Overlays über dessen Einstellungen mit anschließend neu gestartetem Spieler und erneuter Modullistenprüfung infrage. Eine bloß verborgene Benachrichtigung oder FPS-Anzeige belegt keine entfernten Hooks. Es wurden keine DLLs verändert, Dienste beendet oder undokumentierte Registry-/Umgebungsvariablen gesetzt. NVIDIA-Antwort zur fehlenden API, NVIDIA-Antwort zur Hook-Erkennung.

Der zum Recherchezeitpunkt neueste offiziell verifizierte Game-Ready-Treiber ist 616.92 WHQL vom 9. September 2026. Seine Release-Notes führen die RTX 4060 Laptop GPU ebenfalls als unterstützt auf, enthalten jedoch ebenso wenig wie die 577.00-Notes einen passenden Unity-/HDRP-/CBV-Fix. Ein späterer kontrollierter Treibervergleich ist eine Diagnoseoption, keine bereits belegte Abhilfe. NVIDIA empfiehlt bei Notebooks, die vom Gerätehersteller empfohlenen beziehungsweise zertifizierten Treiber zu berücksichtigen. GeForce Experience ist laut aktueller NVIDIA-FAQ nicht mehr unterstützt; dies beweist keine Ursache des hier geladenen Moduls. 616.92-Veröffentlichung, 616.92-Release-Notes, NVIDIA-FAQ.

Nutzerbeobachtung: Nachtlicht bleibt eingeschaltet, warme Farbdarstellung geht verloren

Der Nutzer hat seine ursprüngliche Beobachtung präzisiert: Der Windows-Schalter bleibt auf Ein, das Bild wird kalt. Nach Spielausführungen fehlt also die angewendete warme Farbdarstellung, obwohl die Nachtlicht-Einstellung weiterhin aktiv angezeigt wird. Das spricht für ein Problem des angewendeten Farbzustands, belegt aber noch nicht dessen Ursache. Die Aussage wird als Nutzerbeobachtung geführt; eine Änderung der gespeicherten OS-Präferenz wurde nicht beobachtet.

Die schreibgeschützte Quell- und Konfigurationsprüfung fand im Hauptprojekt und in C:/Unity Projects/Rampage66 bereits allowHDRDisplaySupport: 0 und useHDRDisplay: 0 (jeweils ProjectSettings/ProjectSettings.asset, Zeilen 162–163). Unity dokumentiert useHDRDisplay als Aufforderung zum Wechsel des Hauptdisplays in den HDR-Modus; diese Aufforderung ist hier deaktiviert. HDRP-interne Beleuchtungsberechnung und HDRI-Texturen bedeuten nicht automatisch HDR-Displayausgabe. Unity-HDR-Display-Einstellung.

RampageApp.ApplyDisplaySettings setzt ausschließlich Auflösung und FullScreenWindow/Windowed; der Buildstandard ist randloses Vollbild, kein Exclusive Fullscreen. Sämtliche überprüften Renn-/Funktions- und Probenstartskripte fordern -screen-fullscreen 0 an. Isolierte QA-Läufe überspringen die Profil-Anzeigeeinstellung, abgesehen von den ausdrücklich vorgesehenen Fenster-/Vollbildprüfungen im Input-Test. In den geprüften Projektquellen und Werkzeugskripten fanden sich keine Night-Light-/Registry-Schreibzugriffe, keine Gamma-Rampen- oder Windows-Farbprofilaufrufe, keine native DisplayConfig-/ChangeDisplaySettings-Verwendung und keine HDROutputSettings-Umschaltung. Damit ist eine direkte Änderung der Nachtmoduspräferenz durch den geprüften Anwendungscode nicht belegt; das Verhalten nativer Engine-/Treiber-/Capture-Komponenten ist dadurch nicht vollständig ausgeschlossen.

Ein Verlust des angewendeten Farbzustands während des beobachteten TDR beziehungsweise der Treiber-Reinitialisierung ist eine Hypothese. Microsoft beschreibt, dass TDR Grafikstack und GPU-Zustand zurücksetzt, und dass Gamma-Rampen bei Anzeigeereignissen zurückgesetzt werden können. Diese allgemeinen Mechanismen beweisen den konkreten Nachtmodusfehler nicht. Ebenso wäre die pauschale Aussage, HDR schalte Nachtmodus grundsätzlich aus, falsch: Microsoft dokumentiert auch deren gleichzeitigen Betrieb und mögliche Übersättigung. Microsoft TDR, Grenzen von Gamma-Rampen, Windows-HDR-Hinweise.

Ein begründeter Projekt-HDR-Fix ergibt sich daraus derzeit nicht, weil beide relevanten Flags schon deaktiviert sind. Die unterstützte Wiederherstellung erfolgt nach dem Nutzerupdate beziehungsweise Neustart über Windows-Einstellungen → System → Anzeige → Nachtmodus; ms-settings:nightlight ist der dokumentierte Einstellungsseiten-Link. Es wurde kein automatischer Registry- oder Gamma-Ersatz eingebaut und keine OS-Präferenz verändert. Microsoft-Nachtmodusanleitung, dokumentierte Settings-URI.

Microsoft dokumentiert Nachtlicht außerdem ausdrücklich als angewendete Gamma-/Farbmatrix über WDDM-Treiberschnittstellen. Beim automatischen Wechsel der anzeigenden Laptop-GPU muss derselbe Nachtlichtwert auf der neuen GPU wieder angewendet werden. Dies belegt die Unterscheidung zwischen aktiver Nutzerpräferenz und angewendetem Farbzustand; ein solcher GPU-Displaywechsel auf diesem Gerät wurde damit nicht nachgewiesen. Der nächste kontrollierte Vergleich soll deshalb auch erfassen, ob die Wärme bereits beim normalen Start/sauberen Beenden oder erst zusammen mit einem protokollierten TDR verloren geht. Eine vom Nutzer ausgeführte einmalige Nachtlicht-Umschaltung Aus → Ein bei unveränderter Stärke kann die Wiederanwendung prüfen; sie ist kein dauerhafter Fix. In den geprüften NVIDIA-Release-Notes 577.00 und 616.92 wurde kein Nachtlicht-Eintrag gefunden. Microsoft zu Nachtlicht beim GPU-Displaywechsel.

Aktueller Diagnosestand

Der Vulkan-Vergleich ist als Initialisierungshänger ohne Rennbericht dokumentiert. Erfolgreiche DX12-Einzelrennen wechseln weiterhin mit nativen Resets; weder Async Compute aus, Direct-Threading, Volumetrik aus noch SRP Batcher aus ist als ausreichende Lösung belegt. Die passende app-lokale Debug-Layer hat funktioniert und GPU-basierte Validierung hat konkrete Konstantenpufferfehler geliefert. Der neue instrumentierte Lauf mit SRP Batcher aus blieb jedoch beim Laden ohne auswertbares Ergebnis; der normale Lauf mit derselben Batcher-Einstellung endete erneut mit einem GPU-Reset.

Der zwischenzeitlich vorbereitete Standard Direct3D 11 mit BitBlt und wieder eingeschaltetem SRP Batcher hat um 20:45:37 ebenfalls native Gerätefehler gezeigt. Die früheren BitBlt-Abschlüsse sind deshalb keine Stabilitätsfreigabe für diese Konfiguration. Der historische separate Unity-6.6-Lauf mit älterem Spielinhalt endete im vollständigen Rennen mit einem Reset; die einfache 180-s-HDRP-Minimalprobe wurde erfolgreich abgeschlossen. Dieser abweichende Inhalt erlaubt keine Aussage darüber, ob ein Upgrade des aktuellen Projekts hilft. Die Beleuchtungsprobe wurde für das Nutzerupdate bewusst unterbrochen. Das Hauptprojekt bleibt auf 6000.3.24f1, und das angestrebte AAA-Grafikniveau ist weiterhin nicht erreicht. Weder eine behobene Ursache noch ein nachgewiesener Engine-, Overlay- oder Treiberdefekt wird behauptet. Die Nutzerbeobachtung, dass andere Spiele stabil laufen, bleibt ausdrücklich berücksichtigt; eine Hardwareursache ist nicht belegt.

Der Nutzer versucht GeForce Experience beziehungsweise den NVIDIA-Treiber zu aktualisieren und berichtet dabei GeForce-Experience-Fehler 0x0003; ein Neustart kann folgen. Das ist der gemeldete Nutzerstatus, keine vom Agenten durchgeführte Installation oder unabhängig diagnostizierte Fehlerursache. Alle GPU-, Spiel- und Unity-Tests bleiben währenddessen angehalten. Nach erneuter Freigabe wäre zunächst eine kontrollierte Beobachtung des Nachtmodus und gegebenenfalls ein Overlayvergleich mit Prüfung der geladenen Module aussagekräftiger als weitere ungezielte Inhaltsänderungen. Falls weiterhin nötig, dokumentiert NVIDIA mit dem Nsight-Aftermath-Monitor eine auf einzelne Anwendungen begrenzbare GPU-Dump-Erfassung ohne Projektintegration; sie wurde hier nicht installiert oder ausgeführt. Offizieller Aftermath-Ablauf.

Für diese Dokumentationsprüfung wurden keine Treiber, OS-Komponenten, Registry-Einträge oder Quelltexte geändert. Keine pauschale Stabilitätsfreigabe und keine bestätigte Fehlerursache werden aus den bisherigen Läufen abgeleitet.