Lifecycle-Prüfung des Nutzerabsturzes mit Treiber 610.88

Stand: 17.09.2026. Ausschließlich Quelltext- und Logprüfung; keine Codeänderung, kein Player-/Editorstart, kein GPU-Test. Geprüft wurden der aktuelle Projektquelltext und die lokalen HDRP/Core-Pakete 17.3 sowie der unten begrenzte Vergleich mit 17.6. Das Nutzerlog enthält keine Flight-Recorder-Daten und identifiziert nicht den verursachenden GPU-Pass.

Ergebnis

Kein belegter vorzeitiger Release durch GarageReflectionResources, GeneratedWorldResources oder SceneLighting. Die vorhandenen CopyTexture-Meldungen reichen nicht als Nachweis dafür. Der unmittelbar vorher protokollierte Geräteverlust erklärt bereits, warum anschließend Texturobjekte fehlen. Eine auffällige Kombination von Ressourcengrößen passt dagegen konkret zum HDRP-Himmels-/Umgebungslichtpfad, der auch ohne Garagen-Probe läuft. Das identifiziert einen möglichen betroffenen Folgepfad, noch nicht den Auslöser des Geräteverlusts.

Im Nutzerlog stehen Unity 6000.3.24f1, Direct3D 11 und Treiber 32.0.16.1088 (Zeilen 6–14). Nach dem dritten Laden von alps-02 folgen:

0x887A0005 ist der Geräteverlust (DXGI_ERROR_DEVICE_REMOVED). Es gibt hier keine Zeitstempel/Stacks, die eine frühere Freigabe, den Rundenwechsel oder eine bestimmte Compute-Dispatch als Ursache belegen. Auch die spätere normale Shutdown-Sequenz macht aus dem Lauf keinen erfolgreichen Lauf.

Garagen-Probe und erzeugte Weltressourcen

• GarageReflectionResources.cs, Zeilen 12–23, gibt ausschließlich die beiden RTHandles dieser Probe in OnDestroy frei. Identische Farb-/Tiefenhandles werden nur einmal freigegeben. Es gibt keinen Timer und keinen Rundenwechsel-Aufruf.
• SceneLighting.cs, Zeilen 174–182, erzeugt die Probe ausschließlich in der Garage, mit Realtime/OnDemand. Die Rennstrecke erzeugt dort keine Reflexionsprobe.
• HDRP HDProbe.cs, Zeilen 1115–1137, registriert in OnEnable und deregistriert in OnDisable. HDProbeSystem.cs, Zeilen 226–230, entfernt die Probe aus allen drei Registrierungslisten. Die Freigabe in HDProbe.OnDestroy, Zeilen 1178–1181, liegt selbst im Editor-Kompilierungszweig; sie ersetzt keinen nachgewiesenen Player-Cleanup.
• HDRP HDRenderPipeline.cs, Zeilen 1959–1963 und 2136–2141, markiert Probe-Renderrequests zum Aufräumen und setzt danach camera.targetTexture = null. Der Kommentar nennt ausdrücklich das spätere Zerstören der Textur vor der gecachten Kamera. Requests werden innerhalb des Render-Aufrufs gesammelt und abgearbeitet. Der ProbeCameraCache erzeugt inaktive Kameras und entfernt unbenutzte Einträge.
• Core RTHandle.cs, Zeilen 222–230, entfernt den Handle aus seinem Owner, zerstört das eigene Texture-Objekt und nullt es. CoreUtils.Destroy verwendet im Player Object.Destroy (Zeilen 1325–1336). Keine konkrete doppelte native Freigabe ist hier sichtbar.
• RampageApp.cs, Zeilen 168–185, deaktiviert die Hauptkamera, zerstört Garage/alte Rennwelt und wartet einen weiteren Frame vor dem Neuaufbau. ClearRace zerstört Welt/Rider; ein normaler Wechsel Runde 1 → 2 ruft diese Funktion nicht auf.
• GeneratedWorldResources, Zeilen 306–319, hält ein deduplizierendes HashSet<Object>. Sämtliche sieben aktuellen Own-Aufrufstellen übernehmen frisch erzeugte/geklonte Meshes bzw. Materialien. Keine dieser Stellen übernimmt RTHandles, RenderTextures, importierte Cubemaps oder Profile. Insbesondere erzeugen ChapterTerrain Zeilen 254–266/294–295 und RegionalForestCanopy Zeilen 145–147 eigene Kopien.

Das ist eine Prüfung des sichtbaren C#-Lebenszyklus, kein Beweis für die Korrektheit der nativen GPU-Synchronisation. Eine zusätzliche Wartezeit oder das Entfernen des Cleanup ist daraus nicht begründbar. Der ältere NoGarageProbe-Vergleich protokolliert zudem einen GPU-Reset; sein Playerlog, Zeile 29, bestätigt noGarageProbeEffective=True. Trotz anderer Build-/Testsituation widerlegt das die notwendige Beteiligung der Garagen-Probe an sämtlichen beobachteten Resets.

SceneLighting und passender HDRP-Folgepfad

SceneLighting.ReleaseOwnedProfile (Zeilen 134–145) löst den Volume-Verweis vor dem Zerstören selbst erzeugter Komponenten/Profiles. Importierte Sky-Cubemaps werden geladen, nicht freigegeben. HDRP verwaltet seine Himmels-RTs selbst. SkyManager.ReleaseCachedContext (Zeilen 1062–1079) reduziert Referenzen und ruft bei null CachedSkyContext.Reset auf; dieser behält die Rendering-Ressourcen zur Wiederverwendung. Ein gewöhnlicher Wetterhash-/Profilwechsel bedeutet damit nicht automatisch eine sofortige Freigabe aller Sky-RTs.

Die zusammenhängende Ressourcensignatur in SkyManager.cs ist überprüfbar:

Die Größen und sechs Kopien passen zum Log. Native Format-/Target-Zahlen wurden nicht als eindeutige Passkennung interpretiert. Der frühere Geräteverlust kann diesen Pfad lediglich getroffen haben.

SceneLighting.ConfigureWeather, Zeilen 62–74, aktiviert im Rennen unabhängig von der Garagen-Probe die Himmelsbeleuchtungsaktualisierung mit Realtime, Periode 1 Sekunde. SkyManager.UpdateEnvironment, Zeilen 1204–1227, führt bei Aktualisierung Wolken-Ambient-Probe, Sky-Cubemap, gegebenenfalls dynamische Ambient-Probe und GGX-Convolution aus. Die Sonne hat außerdem auch auf Low reguläre Schatten (SceneLighting Zeile 129). Ein Engine-Sky-/Ambient-/Shadow-Problem ist deshalb ohne Garage grundsätzlich möglich; die vorliegende Größenkombination belegt keinen Fehler im Schattenpfad.

Lokaler Vergleich HDRP 17.3 → 17.6

Verglichen mit C:/Unity Editors/6000.6.0f1/Editor/Data/Resources/PackageManager/BuiltInPackages/com.unity.render-pipelines.high-definition, Paketversion 17.6.0:

• SkyRenderingContext.cs, SkyUpdateContext.cs, AmbientProbeConvolution.compute sind nach Normalisierung der Zeilenenden identisch.
• Sämtliche sechs Quelltextdateien in Runtime/Material/GGXConvolution sind ebenso identisch: BuildProbabilityTables.compute, ComputeGgxIblSampleData.compute, GGXConvolution.cs, GGXConvolution.cs.hlsl, GGXConvolve.shader, IBLFilterGGX.cs.
• SkyManager ändert an den genannten Compute-/Convolution-Pässen vor allem Callback-Lambdas auf static und TextureHandle-Parameter auf in. Größen, Scratchbuffer, Kopien und Sky-Cache-Lebensdauer bleiben dort gleich. Eine funktionale Änderung aktualisiert zusätzlich visualSky, falls dieser vom lightingSky abweicht (17.6 Zeilen 1266–1270). Hinzu kommen statische Verwaltungs-/Editor-Änderungen.

Hieraus folgt kein identifizierter Convolution-/Lifetime-Fix in 17.6. Ein Enginevergleich bleibt sinnvoll, weil dieser eng begrenzte C#-/Shadervergleich andere RenderGraph-, native Engine- oder Treiberinteraktionen nicht abdeckt.

Minimaler weiterer Isolationsversuch, falls der 6.6-Vergleich scheitert

Nur als opt-in Diagnose könnte SceneLighting.ConfigureWeather für die Rennprofile EnvironmentUpdateMode.OnDemand statt Realtime setzen. HDRP initialisiert einen ungültigen Sky-Kontext weiterhin; sobald er gültig ist, bricht UpdateEnvironment ohne explizite Aktualisierungsanforderung vor der erneuten Hash-/Compute-/Convolution-Arbeit ab (17.3 Zeilen 1173–1189). Die sichtbaren Wettereffekte, Regenpartikel, nassen Materialien, Sonnenanimation und regulären Schatten bleiben dabei konfiguriert. Die indirekte Himmelsbeleuchtung/reflektierte Umgebung folgt späteren Wetteränderungen dann bewusst nicht kontinuierlich.

Für einen aussagekräftigen Vergleich: derselbe Build, API, Treiber, alps-02, Low/Rain, Kamera, Wetterseed und Fahr-/Ladeablauf; ausschließlich diese Option variieren. Die tatsächliche aggregierte Sky-Update-Einstellung und reguläre Rennfortschritte protokollieren. Initialberechnung bzw. Neuerzeugung nach einem Streckenwechsel bleiben möglich; OnDemand bedeutet keine vollständige Abschaltung aller Sky-Pässe. Kein NoGarageProbe, MinimalEffects, Shadow-Off oder weiterer gleichzeitiger Eingriff. Dieser Versuch wäre eine gezielte Eingrenzung wiederholter Sky-Updates und noch keine Reparatur. Er wurde hier weder implementiert noch ausgeführt.