Ein kompletter Systemabsturz ist etwas, was die meisten Anwender kaum noch zu Gesicht bekommen. Das ist auch gut so, denn neben dem Datenverlust erzeugt ein Komplett-Crash auch einen Vertrauensverlust. Umso wichtiger ist es, einer Kernel Panic auf den Grund zu gehen, damit diese ein seltenes Ereignis bleibt. Das „Panic Log“ ist sozusagen der Flugschreiber von macOS – es speichert die letzten Mitteilungen vor dem Crash. Beim darauffolgenden Neustart erscheint der Hinweis, dass der Mac unerwartet beendet wurde. Tippt man auf „Bericht“, zeigt ein Fenster diese macOS-Flugschreiberinformationen. Man muss sie markieren und kopieren, um dann TextEdit zu öffnen und diese dort einzufügen, um sie zu erhalten.


Die resultierende Datei sichert man am besten geräteunabhängig, beispielsweise auf iCloud Drive, Nextcloud, Dropbox oder einem NAS-Laufwerk. Der Dateiname sollte Datum, Uhrzeit und Gerätebezeichnung enthalten. Sodann geht es an die Analyse. In seinem Blog-Beitrag zur Kernel-Log-Analyse gibt der versierte Mac-Nutzer Howard Oakley Hinweise, worauf man achten sollte. Die erste Zeile erläutert den Ort, an dem ein Fehler auftrat, und benennt dabei spezifische CPU- oder andere Rechenkerne. Nach einem Doppelpunkt erscheint der Auslöser. Bestimmte Meldungen seien dabei laut Oakley zu unspezifisch: „cannot find [Kernelextension-name]“, „Kernel trap at“ oder „Kernel data abort“ helfen kaum bei der Fehleranalyse.

Panic im Secure Element oder Leck im Speicher
Steht nach dem Doppelpunkt „SEP Panic“, sei eine Ursache allerdings im Secure Element verortet. Dies führe zu einem „Boot Loop“, bei dem der Neustart wiederholt scheitert und von vorn beginnt. Das komme glücklicherweise extrem selten vor – Oakley kennt nur einen dokumentierten Fall. Eine Ursachenbeschreibung in der Form „zalloc: zone map exhausted while allocating from zone kalloc.12345, likely due to memory leak in zone […]“ weist hingegen auf ein Speicherleck hin: Offenbar beansprucht ein Programm immer mehr Arbeitsspeicher und gibt ihn nicht mehr frei, bis andere Apps oder Systemkomponenten keine Möglichkeit mehr finden, selbst RAM zu reservieren.

Systemdetails weiter unten
Nach der deskriptiven Überschrift folgt ein Block mit tabellenartigen Informationen, welche Mac-Administratoren auf Anhieb wenig verraten. Weiter unten erscheinen dann wieder entzifferbare Details: Betriebssystemdetails wie OS-Version sowie iBoot können Relevanz haben, ebenso die „free size“ titulierte Spalte in der Speichertabelle. Die mit „Panicked Task“ beginnende Zeile einen Hinweis darauf, was den Absturz verursacht hat. Aufmerksamkeit verdient auch die Liste geladener Kernel-Erweiterungen; diese sollte man von unten nach oben lesen. macOS lädt Drittanbieter-Extensions zuletzt, sie stellen die wahrscheinlichste Ursache einer Kernel-Panik dar. Unter macOS 15 (Sequoia) sind Kernel-Erweiterungen standardmäßig untersagt; durch Deaktivieren der System Integrity Protection kann man sein System jedoch dazu bringen, diese doch noch zu installieren. Langfristig empfiehlt es sich, sämtliche Altlasten an Drittanbieter-Extensions zu entfernen.