Ergebnis: Der vorhandene Unity-6.6-Standalone-Build kann mit diesem Argument keinen Aftermath-Dump erzeugen. Der installierte 6.6-Editor unterstützt es. Prüfung ausschließlich offline; kein Unity-/Spielstart, keine DLL-Kopie und keine System- oder Projektänderung.

Die offizielle Unity-6.6-Diagnoseseite schließt GPU-Dumps in Player-Builds ausdrücklich aus. Im Editor aktiviert -force-d3d12-nvidia-aftermath die Erfassung. Dumps landen im Projektverzeichnis, hier C:\Unity Projects\Rampage66. Sie enthalten begrenzte Informationen wie Eventmarker; Unity unterstützt dabei keine Shader-Debuginformationen. Die beiden Flags -force-d3d12-debug und -force-d3d12-debug-gbv dürfen nicht gleichzeitig verwendet werden. Initialisierungsfehler erscheinen im Editorlog.

Die lokale Binärprüfung bestätigt die Abgrenzung; vollständige SHA256-/Import-/Stringbelege stehen in aftermath-support-check.json:

Die DLL ist bereits beim Editor vorhanden. Ihr bloßes Kopieren in den Player würde die fehlende Integration nicht ergänzen. NVIDIA unterscheidet die direkte SDK-Integration von der separaten Monitor-/Treiberkonfiguration; für die integrierte Erfassung muss die Anwendung das SDK vor Erzeugung des Grafikgeräts aktivieren. Diese Prüfung aktiviert weder einen Monitor noch globale Treibereinstellungen. NVIDIA-SDK, NVIDIA-Erfassungswege.

Die alte 6.6-Projektkopie besitzt einen brauchbaren Laufzeit-Renntest nach Eintritt in Play, aber keinen gefundenen fertigen Editor-Start-/Stop-Wrapper:

• RampageApp.cs:75 initialisiert nach Szenenstart die Anwendung; Zeile 111 hängt RuntimeQA an. Das funktioniert laut Quellpfad auch im Editor-Playmode.
• RuntimeQA.cs:100 wählt Track und Qualität, startet das Rennen und übernimmt den Fahrer per KI. Die Zeitbegrenzung beginnt nach dem Laden; report.json und rider-telemetry.jsonl werden geschrieben. -rampageNoCapture unterdrückt Screenshots.
• -rampageTest race aktiviert den getrennten Profilpfad qa-profile.json, nicht rider.json. Die alte Implementierung lädt/speichert diese QA-Datei einschließlich .bak/.tmp; sie sichert und restauriert vorhandene QA-Dateien nicht selbst.
• RuntimeQA.cs:192 endet mit Application.Quit. Dieser Aufruf wird im Editor ignoriert, daher begrenzen 180 Testsekunden nicht die Lebensdauer des Editor-/GPU-Prozesses. Play/Stop bzw. Editorende müssen gesondert kontrolliert werden. Unity-API.
• Die vorhandenen Tools/playtest.ps1 und Tools/render-probe.ps1 starten ausschließlich den Standalone-Player. GpuRenderProbe, nicht HdrpProbeQA, ist der tatsächliche Klassenname. Der Probe-Pfad überspringt Anwendung, UI, Eingabe, Rennphysik und Profilzugriffe und wäre kein Vollrennen.

Nicht ausgeführter Editor-Aufrufentwurf für die bestehende Vergleichskopie; anschließend wäre einmalig Play erforderlich, sofern kein separater Editor-Wrapper hinzukommt:

"C:\Unity Editors\6000.6.0f1\Editor\Unity.exe"
  -projectPath "C:\Unity Projects\Rampage66"
  -openfile "C:\Unity Projects\Rampage66\Assets\Rampage\Scenes\Bootstrap.unity"
  -force-d3d12 -force-d3d12-nvidia-aftermath
  -rampageTest race -rampageTrack 0 -rampageQuality 2
  -rampageSeconds 180 -rampageNoCapture
  -rampageReport "C:\Unity Projects\MotoRacer - Rampage\Docs\QA\20260916-crash-followup\editor-aftermath-planned"
  -logFile "C:\Unity Projects\MotoRacer - Rampage\Docs\QA\20260916-crash-followup\editor-aftermath-planned.log"

Die öffentliche Methode EditorApplication.EnterPlaymode() könnte ein Editor-Wrapper aufrufen; eine direkte -executeMethod UnityEditor.EditorApplication.EnterPlaymode-Kombination wurde nicht erprobt und ersetzt keine zuverlässige Stop-/Timeout-Verwaltung. Game-View-Auflösung und Editor-Overhead sind ebenfalls keine nachgewiesenen Entsprechungen zum Standalone-Lauf. Ein Editor-Capture benötigt keinen neuen Player-Build, ist aber bislang nur vorbereitetes Diagnosekonzept, kein durchgeführter Test oder garantierter Dump.