Debug Log
Kritische Systemfehler, Pipeline-Crashes und harte Debug-Fälle
Dokumentiert werden ausschließlich Fehler, die Szenen vollständig zerlegen, Render Pipelines aus der Bahn werfen oder Kernsysteme so hart treffen, dass viele Projekte an genau dieser Stelle abgebrochen würden.
Der Debug Log zeigt, was Dark Continent hinter den Kulissen aushalten muss und wie ich solche Monster-Bugs systematisch zerlege. Nicht als Jammern, sondern als Beweis dafür, dass das Projekt auch dann weiterläuft, wenn es einmal richtig knallt.
Aufgenommen werden nur Bugs, die ganze Level unspielbar machen, Materialien, Shader oder Beleuchtung vollständig zerstören oder zentrale Systeme wie Leiter, Türen, Keys, Kamera oder Interaktionen lahmlegen.
Ziel ist nicht, jedes technische Detail zu dokumentieren, sondern klar zu zeigen, was kaputt war, wie die Ursache eingegrenzt wurde und welche Schritte zur stabilen Lösung geführt haben. Alles andere bleibt auf internen Listen.
Der Debug Log ist die Hall of Fame der ganz großen Crash-Kandidaten.
Debug Log - März 2026
Keine kritischen Fehler im laufenden Arbeitsstand
Kurzfassung
Im März gab es im laufenden Projektstand keine größeren Debug-Eingriffe. Weder beim allgemeinen Projektbetrieb noch bei der Arbeit an den AI- und Enemy-Controllern sind kritische Fehler aufgetreten, die einen eigenen technischen Eingriff oder eine tiefergehende Fehleranalyse erfordert hätten.
Auch im normalen Coding-Alltag gab es aktuell keine nennenswerten Ausfälle oder Instabilitäten. Der Monat verlief in diesem Bereich auffallend ruhig, was gerade im laufenden Entwicklungsstand ein positives Signal ist.
Debug Log – Februar 2026
HDRP Post-Processing State bricht nach Reload
Kurzfassung
Nach einem Reload ist das HDRP Post-Processing in einen defekten internen Zustand geraten. Die Szene lief weiterhin korrekt, Logik, Trigger und Bewegung funktionierten, aber der visuelle Output der Kamera war kaputt. In meinem Fall zeigte die Game View ein schwarz-weißes, flackerndes Bild.
Besonders problematisch war, dass es keinerlei verwertbare Fehlermeldungen gab. Weder im Editor noch im Log ließ sich eindeutig erkennen, was genau schiefgelaufen war. Der Bug ist bekannt, tritt aber je nach System unterschiedlich auf, wodurch viele Forum-Fixes nicht greifen.
Fehlerbild
Die Game View flackerte und war größtenteils schwarz-weiß. Die Szene selbst lief weiter, es gab keine Abstürze, keine Render-Graph-Errors und keine klaren Hinweise in der Console. Der Fehler wirkte wie ein kompletter Rendering-Ausfall ohne erklärbare Ursache.
Eingrenzung, Ursache & Fix
Eingrenzung
Der Fehler trat reproduzierbar nach Reloads auf. Die Szene lief weiter, Eingaben funktionierten, aber das Kamerabild war sichtbar kaputt. Es gab keinerlei verwertbare Fehlermeldungen im Editor oder in der Console. Genau das machte die Eingrenzung schwierig, da alles nach einem Shader-, Pipeline- oder Asset-Problem aussah, ohne dafür belastbare Hinweise zu liefern.
Ursache
Die Ursache lag nicht in Shadern, Materialien oder der Render Pipeline selbst, sondern in einem fehlerhaften Post-Processing-State nach einem Reload. Dieser Bug ist in Unity 6 bekannt und trat in ähnlicher Form bereits in älteren Versionen auf. Die Auswirkungen unterscheiden sich je nach System deutlich, weshalb viele bekannte Fixes aus Foren nicht zuverlässig greifen.
Fix
Post-Processing wurde einmal bewusst deaktiviert und anschließend wieder aktiviert, um den defekten Zustand zu brechen. Danach wurde Unity vollständig neu gestartet, sodass Kamera- und Rendering-States sauber neu initialisiert werden konnten. Der Fehler trat danach nicht mehr auf.
Lerneffekt
Wenn Unity ohne Fehlermeldung visuell komplett aussteigt, muss das Problem nicht im Content liegen. Post-Processing kann nach Reloads in einen defekten Zustand geraten, der weder im Log noch im Editor klar sichtbar wird. In solchen Fällen lohnt es sich, Rendering-States gezielt zu resetten und Unity sauber neu zu starten, statt stundenlang Shader, Materialien oder Pipeline-Einstellungen zu zerlegen.
Debug Log – Januar 2026
Editor-Crash unter hoher Effektlast
Kurzfassung
Unity ist beim Bauen und teilweise bereits während der Arbeit an der Szene abgestürzt, sobald eine hohe Anzahl an Effekten gleichzeitig aktiv war. Der Absturz trat nicht sofort auf, sondern erst dann, wenn die Gesamtauslastung weiter anstieg und Windows keine sinnvolle Speicherreserve mehr bereitstellen konnte.
Im Log sah es zunächst nach einem klassischen D3D12-Problem aus. Die eigentliche Ursache lag jedoch auf Systemebene: Windows konnte keinen ausreichenden virtuellen Speicher mehr reservieren. Nach korrekter Konfiguration des virtuellen Speichers traten die Abstürze nicht mehr auf.
Fehlerbild
Absturz beim Bauen ohne brauchbare Fehlermeldung im Editor. Das Projekt selbst wirkte dabei nicht beschädigt, es gab keine klassischen Asset- oder Script-Fehler im Editor-UI. Kurz vor dem Abbruch tauchten jedoch mehrere D3D12-Meldungen im Editor.log auf.
Was im Log stand
d3d12: CreateCommandList failed (80070057)
GfxDevice was not out of Local memory
GfxDevice was not out of Non Local memory
AvailableForReservation: 0
Crash!!!
Eingrenzung, Ursache & Fix
Eingrenzung
Der Absturz ließ sich zuverlässig provozieren, sobald mehrere schwere Effekte gleichzeitig aktiv waren. Wurde die Effektlast reduziert, wurde das Bauen stabiler oder lief vollständig durch. Das Muster war eindeutig.
Es handelte sich nicht um ein einzelnes defektes Asset oder einen isolierten Fehler, sondern um die Summe mehrerer gleichzeitiger Lastspitzen, die das System an seine Grenze gebracht haben.
Ursache
Der virtuelle Speicher unter Windows war ungünstig eingestellt oder eingeschränkt. Windows verwaltet die Auslagerungsdatei normalerweise automatisch, in diesem Fall war die Konfiguration jedoch nicht mehr sauber oder wurde zuvor manuell verändert.
Unter hoher Last fehlte dadurch die notwendige Reserve. D3D12 meldete sichtbar Fehler, obwohl weder der lokale noch der nicht-lokale Grafikspeicher tatsächlich erschöpft war. Kurz darauf folgte der Editor-Crash.
Fix
Der virtuelle Arbeitsspeicher wurde in den erweiterten Systemeinstellungen so angepasst, dass Windows wieder ausreichend Reserve bereitstellen kann. Die Auslagerungsdatei wurde auf systemverwaltet gesetzt und auf ein geeignetes Laufwerk gelegt.
Anschließend konnten dieselben Szenen mit identischer Effektkombination erneut getestet werden. Der Absturz trat nicht mehr auf. Bauen und Arbeiten im Editor blieben stabil.
Ergebnis
Unity bleibt beim Bauen stabil. Die Abstürze sind verschwunden und die D3D12-Fehlkaskade tritt bei vergleichbarer Last nicht mehr auf. HDRP-Shadows, Volumetrics und Particles können wieder gemeinsam genutzt werden.
Für das zuvor teilweise ruckelige Verhalten des Editors wurden zusätzlich einige Effekte reduziert oder deaktiviert. Das eigentliche Hauptproblem lag jedoch eindeutig in der Speicher- und Reservenkonfiguration des Systems.
Lerneffekt
Wenn Unity beim Bauen abstürzt und im Log D3D12-Command-List-Fehler auftauchen, ist das nicht automatisch ein Projektbug. Zuerst sollten die Systemreserven geprüft werden, insbesondere der virtuelle Speicher.
Content kann sauber sein und die Engine korrekt arbeiten – liefert Windows jedoch keine ausreichende Reserve, endet der Prozess trotzdem im Absturz.
Debug Log – Dezember 2025
Shader, Materialien & Render Pipeline
01.12.2025 – Shader-Update explodiert, halbes Projekt pink
Kurzfassung
Ein Update eines externen Material- und Shader-Pakets hat die komplette Grafikpipeline zerlegt. Ganze Szenen wurden pink, Shader waren defekt, Render-Graph-Fehler häuften sich in der Konsole. Ein Zustand, an dem viele Projekte einfach beendet werden.
Fehlerbild
Zunächst traten Render-Graph-Fehler und Instabilität beim Szenenwechsel auf. Kurz darauf zeigten einzelne Materialien visuelle Artefakte, bis schließlich der komplette Abriss folgte:
- Gebäude erschienen als magenta Blöcke
- Große Teile des Projekts bestanden aus pinken Materialien
- Inspector zeigte
Hidden/InternalErrorShaderstatt regulärer Shader
Es war klar: Hier war nicht nur ein Setting verrutscht, sondern eine komplette Schicht aus Shadern, Materialien und Render-Pipeline gleichzeitig beschädigt.
Eingrenzung & Fix
Schrittweise Isolation von Pipeline, Shadern und Imports
Ich bin nicht direkt auf alles gleichzeitig losgegangen, sondern Schritt für Schritt.
Basis testen
- HDRP Render Pipeline mit einem frischen Pipeline Asset neu aufgesetzt.
- Leere Testszene mit Standard-HDRP-Materialien erstellt.
- Geprüft, ob Render-Graph-Fehler auch ohne externe Assets auftreten.
Ergebnis: Die Pipeline kann wieder stabil laufen. Das Problem sitzt nicht nur in der Engine selbst.
Shader und Materialien in Kombination prüfen
- Nur Standard-HDRP-Shader verwendet. Szenen waren benutzbar und stabil.
- Externe Materialien Stück für Stück wieder zugeschaltet und beobachtet, ab wann Fehler/Artefakte/Crashes zurückkommen.
Ergebnis: Sobald bestimmte Shader und Materials aktiv sind, eskaliert alles wieder.
Importfehler aufspüren
- Konsole bereinigt und gezielt nach Import-Meldungen gesucht.
- Hinweise gefunden, dass Assets beim Anlegen in die Datenbank übersprungen wurden.
- Betroffene Pakete/Materialien geprüft, die danach auf
Hidden/InternalErrorShaderstanden.
An diesem Punkt war klar: Die Render Pipeline selbst läuft wieder. Das eigentliche Problem steckt in kaputten Shaderreferenzen und unvollständigen Imports nach dem Update.
Lösungsschritte
- Fehlerhafte Material- und Shader-Pakete vollständig aus dem Projekt entfernt.
- Sauber neu importiert, damit Unity Shader, Graphs und Metadaten frisch anlegt.
- Projekt neu gestartet, zentrale Szenen geladen, kritische Meshes (Haus, Treppe, Umgebung) kontrolliert.
- Materialzuweisungen korrigiert, bis kein
Hidden/InternalErrorShadermehr im Inspector auftauchte.
Ergebnis: Die Render-Graph-Fehler sind verschwunden. Das Gebäude rendert wieder korrekt mit Ziegeln, Holz, Dach und Schnee. Szenen laufen stabil, ohne Abstürze beim Wechsel. Pipeline, Shader und Materialien greifen wieder sauber ineinander.
Lerneffekt
Große Shader- und Material-Updates mache ich nicht mehr nebenbei, sondern nur noch mit Backup und eigener Testszene.
Wenn Pink Screen und Render-Graph-Fehler gleichzeitig auftreten, stabilisiere ich zuerst die Pipeline und jage erst danach Shader- und Importprobleme.
Importwarnungen in der Konsole sind keine Randnotiz, sondern oft der direkteste Weg zur eigentlichen Ursache.
Solche Monster-Bugs sind kein Game Over, wenn man sie Schicht für Schicht zerlegt und nicht panisch überall gleichzeitig herumdreht.
Dieser Eintrag steht bewusst an einer Stelle, an der viele Projekte sterben würden. Dark Continent läuft danach stabiler weiter als vorher. Pink bleibt ab jetzt wieder da, wo es hingehört, und nicht auf ganzen Leveln.