✦ SPIELWELTENMoto Racer - Rampage ↗

Vulkan-Absturz: erneute Untersuchung am 16.09.2026

Kein bestätigter Stabilitätsfix. Nach der unten dokumentierten Dump-Analyse hat der Nutzer ausdrücklich die aktive Reparatur und sichtbare automatische Testfenster freigegeben. Die fortgesetzten Renderpfad-Vergleiche stehen im aktuellen Reparaturstand. Die folgenden Aussagen zum Ende der Lasttests beschreiben den damaligen Abschluss der Dump-Phase; sie sind keine Aussage über den späteren Arbeitsstand.

Korrektur am 17.09.: Die alte Rampage66-Kopie enthält nicht den aktuellen Spielinhalt. Der Nutzer berichtet, dass sie bei ihm nicht abstürzt. Frühere Logs eines anderen 6.6-Laufs bleiben historische Befunde, sind aber kein inhaltsgleicher A/B-Vergleich und schließen einen Nutzen des Upgrades mit dem heutigen Inhalt nicht aus.

Gesicherte Befunde

Änderungen

  1. RiderRig.SetFirstPerson bindet ein SkinnedMesh nur beim tatsächlichen Ansichtswechsel neu. Die bisherige wiederholte Bindung jedes Cockpitframes war unnötige native Ressourcenarbeit. Sie ist nicht als Absturzursache nachgewiesen; der neue fehlgeschlagene Lauf verwendete die Verfolgerkamera.
  2. Der vorhandene Übergangstest fuhr pro Besuch nur fünf Sekunden auf der Straße. Neu hinzugefügtes ContinuousRace beobachtet eine durchgehende reale KI-Fahrt, Positionsfortschritt, Rennzeit und Rundenwechsel/Zieleinlauf. Keine Fixture-Teleports, Test-Resets, Screenshots oder Zeitbeschleunigung. Akzeptanz verlangt über 120 echte Fahr- und Rennsekunden sowie den nötigen Streckenübergang. Ein vorzeitiger Zieleinlauf ist unzureichende Testabdeckung, kein erfundener GPU-Fehler.
  3. -rampageCrashRecorder schreibt passiv jede Sekunde ein eigenes JSONL mit UTC, Rendercallbacks, Kamera, Wetter, Fahrerphysik und Runden-/Gate-Fortschritt; jede Zeile wird auf die Platte geflusht. CPU-Callbacks beweisen keine GPU-Fertigstellung. Aufzeichnung ist begrenzt und bei normalen Starts ohne Schalter deaktiviert.
  4. -rampageWeatherSeed reproduziert im isolierten QA-Prozess den Wetterplan und seine Phase. Normales Spielen bleibt zufällig.
  5. Der Teststarter sichert ursprüngliche Profildateien vor dem Start zusätzlich auf Platte, damit ein Rechnerhänger die einzige Sicherung nicht mehr vernichtet. Nach einem Neustart erfolgt keine unkontrollierte automatische Profilrücksetzung.
  6. Die native Logprüfung erkennt nun auch Vulkan-Geräteverluste und ausdrückliche Vulkan-Validierungsfehler. 45/45 Offline-Prüfungen bestanden, einschließlich der unveränderten historischen DirektX-Fehlerprotokolle.

Neuer tatsächlicher Lauf

Aufruf/Ereignisse, Rennbericht, dauerhaftes Fahrprotokoll.

Der isolierte neue Build Builds/Windows-CrashProbe-20260916 wurde erfolgreich mit 6000.3.24f1 erstellt. 119 Runtime- und 25 Editor-Dateien kompilierten ohne Warnungen/Fehler. Das ist kein Laufzeit-Stabilitätsnachweis. Buildprovenienz.

Test: alps-02, Low, Verfolgerkamera, Wetterseed 707000 mit tatsächlich aktivem Regen, alle Landschaftselemente/Effekte, acht Fahrer, Direct3D11, direkter Renderbefehlsweg und ausgeschalteter SRP-Batcher. Beide Renderoptionen wurden zur Laufzeit bestätigt. Der Legacy-Wert fullProductionConfiguration im C#-Bericht meint hier nur Landschaft/Effekte; der Aufrufbericht kennzeichnet ausdrücklich rendererPathModified=true und defaultRendererConfiguration=false.

Fehlgeschlagen: Windows meldet um 22:57:49.749 erneut nvlddmkm 14/153 (UCodeReset TDR). Letzte persistierte Probe: 26,798 Rennsekunden, 1.254,63 von 4.024,81 m, Gate 28/90, Racing, kein Zieleinlauf, kein Rundenwechsel, endliche Fahrer-/Kamerawerte und keine bis dahin erfassten verwalteten Fehler. Die Probe entstand 20 ms nach dem ersten OS-Ereignis; sie ist keine garantierte Messung vor dem Reset. Der Wrapper erkannte den Treiberfehler und beendete den verbleibenden Testprozess. Die Kombination aus direktem Rendern und SRP-Batcher aus ist damit ebenfalls keine Lösung.

Maximal erfasst: 2.118/8.188 MiB GPU-Speicher, 65 °C, 57 % GPU-Auslastung; mindestens 48,65 GB physischer Systemspeicher frei. Speicherknappheit oder Überhitzung werden dadurch nicht gestützt. Produktionsprofile unverändert und QA-Dateien erfolgreich wiederhergestellt. Dieser Lauf reproduziert den GPU-Fehlertyp vor jeder Ziel-/Rundengrenze, nicht den konkret gemeldeten Rundenwechsel.

Native Absturzabbilder: ausgewertet

Nach der ausdrücklichen Freigabe des Nutzers wurden alle vier vorhandenen Abbilder lokal kopiert, per SHA-256 geprüft und vollständig mit dem Microsoft-Debugger analysiert. Keine Änderung an Treibern, Registry, Diensten, BIOS oder Quellberechtigungen; keine Dumps hochgeladen und kein weiterer GPU-Lasttest. Vollständige Auswertung, Originalprotokolle und Grenzen.

Damit ist ein Ausfall im NVIDIA-/Windows-Grafikpfad belegt, über mehrere APIs und auch vor jeder Zielgrenze. Der auslösende Spielinhalt/Renderbefehl ist weiterhin offen. Weder ein allgemeiner Hardwaredefekt noch ein konkreter NVIDIA- oder Unity-Softwarefehler ist durch diese Abbilder bewiesen. Die funktionierenden anderen Spiele passen weiterhin zu einem spezifischen problematischen Rendering-Workload.

Die zusätzliche Auswertung mit dem exakt passenden lokalen NVIDIA-Treiber-Image legt beim älteren Bluescreen eine längere NVIDIA-Interrupt-/DPC-Kette frei. Sie liefert weiterhin keine Zuordnung zu einem Unity-Draw. Der nächste gezielte Ansatz ist daher die Zuordnung der historischen GPU-Constant-Buffer-Fehler zum ersten betroffenen Compute-Pass und ein sauberer Inhaltsvergleich, der Baum-Zeichenbefehle von Kameraeffekten trennt. Die bisherigen Vergleiche vermischen diese beiden Änderungen; der konkrete fehlende Vergleich und seine Grenzen sind im nativen Analysebericht festgehalten. Kein neuer Lasttest und kein bestätigter reparierter Build.