8.5 macOS – Prozesse, Dienste, Protokolle, Ressourcen und Speicher analysieren

Diese Seite beschreibt die systematische Fehleranalyse auf macOS. Im Mittelpunkt stehen Prozesse, launchd-Dienste, Protokolle, CPU, Arbeitsspeicher, APFS-Datenträger, Dateiberechtigungen, Datenschutzfreigaben und Startprobleme.

8.5.1 Ziel und Abgrenzung

Nach dieser Seite soll beurteilt werden können:

ob eine Störung nur eine App, einen Benutzer oder das gesamte System betrifft;
ob ein Prozess ausgeführt wird, blockiert ist, abstürzt oder ungewöhnlich viele Ressourcen verbraucht;
ob ein Dienst im richtigen launchd-Bereich registriert ist;
ob Protokolle, Absturzberichte oder Systemdiagnosen eine Ursache belegen;
ob CPU, Arbeitsspeicher, Datenträger oder Dateisystem den Engpass bilden;
ob Unix-Berechtigungen, ACLs oder macOS-Datenschutzfreigaben den Zugriff verhindern;
ob Anmeldeobjekte, Hintergrunddienste oder Systemerweiterungen beteiligt sind;
ob ein Software-, Konfigurations- oder Hardwareproblem vorliegt.

Eine laufende App, ein vorhandener Prozess oder ein registrierter Dienst beweist noch nicht, dass die ursprüngliche Benutzerfunktion funktioniert.

8.5.2 Besonderheiten der macOS-Systemarchitektur

Für die Fehleranalyse sind insbesondere folgende Komponenten wichtig:

Komponente	Aufgabe	Bedeutung für die Diagnose
Kernel	Verwaltet Hardware, Speicher, Prozesse und Systemressourcen	Kernel-Panics, Treiber- oder Hardwareprobleme können das gesamte System betreffen
`launchd`	Startet und verwaltet Dienste, Agents und XPC-Dienste	Ein Dienst kann dauerhaft oder nur bei Bedarf gestartet werden
LaunchDaemon	Systemweiter Hintergrunddienst	Wird gewöhnlich im `system`-Bereich verwaltet
LaunchAgent	Benutzerbezogener Hintergrunddienst	Wird gewöhnlich im `gui/<UID>`-Bereich verwaltet
Unified Logging	Zentrales Protokollsystem von macOS	Wird über „Konsole“ oder den Befehl `log` ausgewertet
APFS	Standarddateisystem moderner macOS-Systeme	Container, Volumes, Snapshots und gemeinsam genutzter Speicher müssen unterschieden werden
TCC	Datenschutz- und Zugriffssteuerung	Kann Zugriffe trotz korrekter Unix-Berechtigungen verhindern
Systemerweiterungen	Erweiterungen für Netzwerk, Sicherheit, Treiber und andere Funktionen	Fehlerhafte Erweiterungen können systemweite Auswirkungen verursachen
Aktivitätsanzeige	Grafische Prozess- und Ressourcenanalyse	Zeigt CPU, Speicher, Energie, Datenträger und Netzwerkaktivität

launchd-Dienste können bedarfsgesteuert arbeiten. Ein registrierter Dienst ohne aktuelle PID ist deshalb nicht automatisch fehlerhaft.

8.5.3 Typische Symptome

Eine App startet nicht oder beendet sich sofort.
Eine App reagiert nicht mehr.
Ein Hintergrunddienst funktioniert nach der Anmeldung oder einem Neustart nicht.
Das System ist dauerhaft oder zeitweise langsam.
Der Lüfter läuft stark oder der Energieverbrauch ist ungewöhnlich hoch.
Der Speicherdruck steigt auf Gelb oder Rot.
Der verfügbare Datenträgerspeicher nimmt unerwartet ab.
Ein Prozess verursacht dauerhaft hohe CPU- oder Datenträgeraktivität.
Eine App kann bestimmte Dateien, Ordner, Geräte oder Netzwerkziele nicht verwenden.
Eine Funktion arbeitet nur unter einem bestimmten Benutzerkonto.
Der Fehler verschwindet im sicheren Modus.
Der Mac startet wiederholt neu oder meldet einen Kernel-Panic.
Ein externes Speichermedium wird nicht oder nur schreibgeschützt eingebunden.
Eine App funktioniert nach einem macOS- oder App-Update nicht mehr.

8.5.4 Kennzeichnung der Befehle

Kennzeichnung	Bedeutung
`[LESEND]`	Liest Informationen aus und verändert normalerweise keine Konfiguration
`[LIVE]`	Beobachtet laufende Ereignisse bis zum Abbruch
`[PRIVILEGIERT]`	Benötigt möglicherweise `sudo` oder Administratorrechte
`[BELASTEND]`	Kann CPU, Datenträger oder Protokollsystem zusätzlich belasten
`[VERÄNDERND]`	Verändert einen Prozess, Dienst oder eine Systemeinstellung
`[NEUSTART]`	Unterbricht laufende Sitzungen oder Funktionen

Vor verändernden Maßnahmen müssen Befund, Konfiguration und Rückweg dokumentiert werden.

8.5.5 Sicherheits- und Betriebswarnungen

Flüchtige Informationen müssen vor dem Beenden einer App oder vor einem Neustart gesichert werden.
kill -9, erzwungenes Ausschalten und erzwungenes Aushängen eines Datenträgers können zu Datenverlust führen.
Apple-Systemdienste dürfen nicht versuchsweise deaktiviert oder aus /System/Library entfernt werden.
SIP, Gatekeeper, FileVault und Datenschutzfunktionen dürfen nicht als dauerhafte Fehlerlösung deaktiviert werden.
Protokolle, Systemberichte und sysdiagnose-Archive können Benutzernamen, Pfade, Seriennummern, Netzwerkdaten und andere vertrauliche Informationen enthalten.
diskutil besitzt sowohl lesende als auch destruktive Unterbefehle. Datenträgerkennung und Unterbefehl müssen vor der Ausführung kontrolliert werden.
Eine Dateisystemreparatur ersetzt kein Backup.
Das manuelle Löschen unbekannter Dateien aus /Library, /System, /private oder APFS-Systembereichen ist keine sichere Standardmaßnahme.
Bei verwalteten Macs können MDM-Richtlinien Einstellungen absichtlich erzwingen.
Befehlsoptionen können sich zwischen macOS-Versionen ändern. Maßgeblich ist die lokale Manpage der tatsächlich installierten Version.

Beispiel:

man launchctl
man log
man diskutil

8.5.6 Benötigte Informationen

Vor der Diagnose sollten mindestens folgende Angaben erfasst werden:

genaue macOS-Version und Buildnummer;
Apple-Chip oder Intel-Prozessor;
Zeitpunkt und Häufigkeit der Störung;
betroffene App, Funktion, Benutzer und Geräte;
letzte Updates, Installationen oder Konfigurationsänderungen;
angemeldeter Benutzer und vorhandene Administratorrechte;
MDM- oder Unternehmensverwaltung;
angeschlossene Datenträger, Docks und USB-Geräte;
freier Speicherplatz;
genaue Fehlermeldung;
Verhalten nach Ab- und Anmeldung oder Neustart;
Verhalten unter einem anderen Benutzerkonto;
Verhalten im sicheren Modus;
vorhandene Absturz-, Spin- oder Panic-Berichte.

8.5.7 Systemzustand und Basisdaten sichern

Die folgenden Befehle sind lesend. Systeminformationen können Seriennummern und andere vertrauliche Daten enthalten und müssen vor einer Weitergabe geprüft werden.

date
sw_vers
uname -a
uname -m
uptime
who
last reboot | head -n 10
system_profiler SPHardwareDataType SPSoftwareDataType

Wichtige Fragen:

Stimmt die Systemzeit?
Welche macOS-Version und welcher Build sind installiert?
Wurde das System kurz vor der Störung neu gestartet?
Betrifft das Problem einen Mac mit Apple-Chip oder einen Intel-Mac?
Ist die problematische App für die vorhandene Prozessorarchitektur geeignet?
Trat der Fehler unmittelbar nach einem Update auf?

Die Installationshistorie kann ergänzend geprüft werden:

system_profiler SPInstallHistoryDataType

Die zeitliche Übereinstimmung zwischen einer Installation und dem Beginn der Störung ist ein Hinweis, aber noch kein Ursachenbeweis.

8.5.8 Ungefährliche Schnellprüfung

df -h
df -ih
diskutil list
vm_stat
sysctl vm.swapusage
ps -axo pid,ppid,user,state,%cpu,%mem,etime,command | head -n 30
log show --last 15m --style compact \
  --predicate 'messageType == error OR messageType == fault'

Zusätzlich in der grafischen Oberfläche prüfen:

„Aktivitätsanzeige“ öffnen.
CPU, Speicher, Energie, Festplatte und Netzwerk kontrollieren.
Nach ungewöhnlich belastenden oder nicht reagierenden Prozessen suchen.
„Konsole“ öffnen und den Fehlerzeitraum untersuchen.
Unter „Systemeinstellungen → Allgemein → Speicher“ den verfügbaren Speicher prüfen.
Unter „Systemeinstellungen → Allgemein → Anmeldeobjekte & Erweiterungen“ auffällige Hintergrundobjekte erfassen.
Unter „Datenschutz & Sicherheit“ prüfen, ob die betroffene App die tatsächlich benötigten Freigaben besitzt.

Noch keine Prozesse beenden, Dienste neu starten oder Dateien löschen.

8.5.9 Prozesse systematisch untersuchen

Prozesse können über die Aktivitätsanzeige oder das Terminal untersucht werden.

Alle Prozesse anzeigen:

ps -axo pid,ppid,user,state,%cpu,%mem,etime,command

Mehrere Messungen der aktiven Prozesse durchführen:

top -l 3 -s 2 -o cpu \
  -stats pid,command,cpu,mem,threads,state,time

Nach einem Prozess suchen:

pgrep -fl "BeispielApp"

Einen bestimmten Prozess untersuchen, wobei 1234 durch die tatsächliche PID ersetzt wird:

ps -p 1234 \
  -o pid,ppid,user,state,%cpu,%mem,etime,command

Geöffnete Dateien und Verbindungen des Prozesses anzeigen:

lsof -nP -p 1234 | head -n 100

Einen Prozess für zehn Sekunden analysieren:

sample 1234 10 -file "$HOME/Desktop/BeispielApp-sample.txt"

Alternativ kann in der Aktivitätsanzeige ein Prozess ausgewählt und über „Mehr → Prozess analysieren“ untersucht werden.

Zu prüfen sind:

Elternprozess;
ausführender Benutzer;
Laufzeit;
CPU- und Speicherverbrauch;
geöffnete Dateien;
Netzwerkverbindungen;
wiederholte Neustarts;
nicht reagierende Threads;
zugehörige Protokoll- und Absturzmeldungen.

Ein hoher Messwert während eines kurzen Startvorgangs kann normal sein. Aussagekräftiger ist eine wiederholte oder dauerhaft hohe Auslastung im Fehlerzeitraum.

8.5.10 Prozesse kontrolliert beenden

Zuerst sollte die App regulär beendet werden. Reagiert sie nicht, kann die Aktivitätsanzeige verwendet werden.

Ein Prozess kann im Terminal zunächst mit SIGTERM zum geordneten Beenden aufgefordert werden:

kill -TERM 1234

Kennzeichnung: [VERÄNDERND]

Risiken:

nicht gespeicherte Daten können verloren gehen;
verbundene Anwendungen können ihre Verbindung verlieren;
ein von launchd verwalteter Prozess kann automatisch erneut gestartet werden.

SIGKILL beziehungsweise kill -9 beendet einen Prozess ohne geordnetes Aufräumen und ist nur die letzte Eskalationsstufe:

kill -KILL 1234

Kennzeichnung: [VERÄNDERND] [HOHES RISIKO]

Vorher müssen PID, Prozessname, Benutzer und Auswirkungen eindeutig geprüft werden.

8.5.11 Dienste und Agents mit launchd analysieren

Systemweite Dienste und benutzerbezogene Agents liegen in unterschiedlichen launchd-Bereichen.

Bereich	Typische Verwendung
`system`	Systemweite Daemons
`user/<UID>`	Benutzerbereich ohne zwingenden Bezug zur grafischen Anmeldung
`gui/<UID>`	Grafische Anmeldesitzung eines Benutzers

Systembereich anzeigen:

launchctl print system

Bereich des aktuell angemeldeten Benutzers anzeigen:

launchctl print gui/$(id -u)

Einen konkreten systemweiten Dienst prüfen:

launchctl print system/com.example.service

Einen konkreten Benutzer-Agent prüfen:

launchctl print gui/$(id -u)/com.example.agent

Deaktivierungszustände anzeigen:

launchctl print-disabled system
launchctl print-disabled gui/$(id -u)

Typische Speicherorte:

~/Library/LaunchAgents
/Library/LaunchAgents
/Library/LaunchDaemons
/System/Library/LaunchAgents
/System/Library/LaunchDaemons

Eine Drittanbieter-Property-List syntaktisch prüfen:

plutil -lint "/Library/LaunchDaemons/com.example.service.plist"

Zu untersuchen sind:

korrekter launchd-Bereich;
exaktes Dienstlabel;
Programmpfad und Argumente;
ausführender Benutzer;
letzte Exit-Codes;
Startbedingungen;
Standardausgabe und Fehlerausgabe;
Dateiberechtigungen der Property-List;
Existenz und Ausführbarkeit des hinterlegten Programms;
Abhängigkeiten und benötigte Dateien.

Ein nicht laufender On-Demand-Dienst kann sich im Normalzustand befinden. Entscheidend ist, ob der vorgesehene Auslöser den Dienst startet und die Benutzerfunktion anschließend funktioniert.

8.5.12 Dienst kontrolliert neu starten

Ein eindeutig identifizierter Drittanbieterdienst kann zu Diagnosezwecken neu gestartet werden.

Systemweiter Dienst:

sudo launchctl kickstart -k system/com.example.service

Benutzer-Agent:

launchctl kickstart -k gui/$(id -u)/com.example.agent

Kennzeichnung: [VERÄNDERND]

Vorher dokumentieren:

Dienstlabel;
aktueller Status;
PID;
offene Verbindungen;
aktuelle Protokollmeldungen;
mögliche Benutzerunterbrechung;
erwartetes Ergebnis.

Ein erfolgreicher Neustart beweist nur, dass der Dienst erneut gestartet werden konnte. Danach muss die ursprüngliche Funktion getestet werden.

8.5.13 Unified Logging und Konsole

Die App „Konsole“ und der Befehl log greifen auf das zentrale macOS-Protokollsystem zu.

Fehler und Fault-Meldungen der letzten 30 Minuten:

log show --last 30m --style compact \
  --predicate 'messageType == error OR messageType == fault'

Meldungen eines bestimmten Prozesses:

log show --last 30m --style compact \
  --predicate 'process == "BeispielApp"'

Bestimmten Zeitraum untersuchen:

log show \
  --start "2026-08-02 13:00:00" \
  --end "2026-08-02 13:30:00" \
  --style compact

Protokollmeldungen live verfolgen:

log stream --style compact --level info \
  --predicate 'process == "BeispielApp"'

Kennzeichnung: [LIVE]

Die Live-Ausgabe wird mit Ctrl-C beendet.

Ein Protokollarchiv der letzten 30 Minuten erstellen:

sudo log collect --last 30m \
  --output "$HOME/Desktop/macOS-30m.logarchive"

Kennzeichnung: [PRIVILEGIERT] [DATENSCHUTZRELEVANT]

Bei der Auswertung beachten:

Fehlerzeitpunkt möglichst genau eingrenzen;
Prozess, Subsystem und Kategorie berücksichtigen;
erste Fehlermeldung einer Fehlerkette suchen;
wiederholte Folgefehler nicht automatisch als Ursache interpretieren;
Meldungen vor und nach dem Fehler vergleichen;
normale Warnungen von reproduzierbaren Fehlern unterscheiden;
fehlende Protokollmeldungen sind kein Beweis für Fehlerfreiheit;
Info- und Debug-Meldungen werden nicht immer dauerhaft gespeichert.

8.5.14 Absturz-, Spin- und Diagnoseberichte

Die App „Konsole“ zeigt unter anderem:

Absturzberichte mit der Erweiterung .ips;
Spin-Berichte nicht reagierender Prozesse;
Protokollberichte;
Diagnoseberichte;
ältere Einträge aus system.log;
System- und Benutzerberichte.

Benutzerbezogene Diagnoseberichte können zusätzlich in folgendem Verzeichnis liegen:

ls -lt "$HOME/Library/Logs/DiagnosticReports" | head -n 20

Systemweite Diagnoseberichte:

sudo ls -lt "/Library/Logs/DiagnosticReports" | head -n 20

Wichtige Inhalte eines Absturzberichts:

betroffener Prozess und Version;
Zeitpunkt;
Prozessorarchitektur;
Exception Type;
Termination Reason;
auslösender Thread;
verwendete Bibliotheken;
wiederkehrende Funktionsnamen oder Module;
Übereinstimmung mit dem tatsächlichen Fehlerzeitpunkt.

Ein einzelner Absturzbericht beweist nicht automatisch einen dauerhaften Defekt. Entscheidend sind Reproduzierbarkeit, Häufigkeit und Übereinstimmung mit der beobachteten Störung.

8.5.15 CPU-Auslastung analysieren

Grafisch:

Aktivitätsanzeige öffnen.
Bereich „CPU“ auswählen.
Nach % CPU sortieren.
Messung während der Störung beobachten.
Prozess analysieren oder Spindump erstellen.

Im Terminal:

top -l 5 -s 2 -o cpu \
  -stats pid,command,cpu,mem,threads,state,time

Mögliche Befunde:

Befund	Mögliche Bedeutung
Ein Prozess dauerhaft stark ausgelastet	Endlosschleife, fehlerhafte Verarbeitung oder außergewöhnliche Arbeitslast
Viele Prozesse gleichzeitig ausgelastet	Systemweite Last, Indizierung, Update oder konkurrierende Aufgaben
Hohe CPU mit normaler Benutzerfunktion	Möglicherweise erwartete Verarbeitung
Niedrige CPU bei langsamer App	Warten auf Datenträger, Netzwerk, Sperre oder externen Dienst
App reagiert nicht und CPU ist nahezu null	Blockierter Thread oder Warten auf eine Ressource
Wiederkehrende kurze Lastspitzen	Regelmäßiger Agent, Synchronisation oder geplanter Hintergrundprozess

Die CPU-Auslastung muss immer zusammen mit Prozesszustand, Benutzerfunktion, Protokollen und I/O-Aktivität bewertet werden.

8.5.16 Arbeitsspeicher analysieren

Apple empfiehlt, den Speicherdruck und nicht nur den freien Arbeitsspeicher zu bewerten.

Grafisch:

Aktivitätsanzeige öffnen.
Bereich „Speicher“ auswählen.
Speicherdruck beobachten.
Speicher, komprimierten Speicher und Swap-Nutzung prüfen.
Nach Speicherverbrauch sortieren.

Terminalprüfung:

vm_stat
sysctl vm.swapusage

Mehrere Messungen im Abstand von zwei Sekunden:

vm_stat -c 5 2

Wichtige Werte:

freie und aktive Speicherseiten;
komprimierter Speicher;
Page-ins und Page-outs;
Swap-ins und Swap-outs;
Entwicklung der Werte während der Störung.

Interpretation:

Befund	Bewertung
Speicherdruck Grün	Speicherverwaltung arbeitet derzeit ausreichend
Speicherdruck Gelb	Ressourcen werden knapp; Verlauf und verursachende Prozesse prüfen
Speicherdruck Rot	Akuter Speicherengpass wahrscheinlich
Hohe Komprimierung ohne Störung	Kann normal sein
Wachsende Swap-Nutzung und Leistungseinbruch	Speicherengpass oder übermäßiger Prozessverbrauch möglich
Einzelner Prozess wächst kontinuierlich	Mögliches Speicherleck
Hohe historische Swap-Zahl ohne aktuelle Änderung	Kein ausreichender Ursachenbeweis

Ein einmaliger Gesamtwert ist weniger aussagekräftig als die Veränderung während des reproduzierten Fehlers.

8.5.17 Datenträger, APFS und Speicherplatz analysieren

Dateisystembelegung:

df -h
df -h /System/Volumes/Data
df -ih

Datenträgerstruktur:

diskutil list
diskutil info /
diskutil apfs list

Lokale Time-Machine-Snapshots anzeigen:

tmutil listlocalsnapshots /

Speicherbelegung im Benutzerordner untersuchen:

du -x -h -d 1 "$HOME" 2>/dev/null | sort -h

Datenträgeraktivität beobachten:

iostat -w 2 -c 5

Dateisystem oder Datenträger-I/O für 15 Sekunden verfolgen:

sudo fs_usage -w -f diskio -t 15

Kennzeichnung: [PRIVILEGIERT] [LIVE] [BELASTEND] [DATENSCHUTZRELEVANT]

Ein Volume prüfen:

diskutil verifyVolume /

Kennzeichnung: [PRÜFEND] [POTENZIELL BELASTEND]

Bei APFS beachten:

mehrere Volumes können Speicher innerhalb eines Containers gemeinsam nutzen;
lokale Snapshots können Speicher belegen;
löschbarer Speicher wird nicht in jeder Anzeige identisch dargestellt;
System- und Datenvolume bilden gemeinsam das startfähige macOS-System;
ein voller Datenträger kann Updates, Protokollierung, Swap, App-Starts und Datenbanken beeinträchtigen;
freie Inodes und freier Speicherplatz sind unterschiedliche Größen;
externe Datenträger können durch Kabel, Stromversorgung, Adapter oder Dateisystemfehler ausfallen.

Für Reparaturen sollte das Festplattendienstprogramm verwendet werden. Apple empfiehlt, „Erste Hilfe“ zuerst für die Volumes, anschließend für die Container und zuletzt für das physische Speichergerät auszuführen. Bei Problemen mit dem Startvolume kann die macOS-Wiederherstellung erforderlich sein.

8.5.18 Dateiberechtigungen, ACLs und erweiterte Attribute

Identität des aktuellen Benutzers prüfen:

id
groups

Datei oder Ordner untersuchen:

ls -ldeO@ "/Pfad/zum/Ordner"
stat -x "/Pfad/zum/Ordner"

Dabei werden unter anderem sichtbar:

Eigentümer;
Gruppe;
klassische Unix-Berechtigungen;
ACL-Einträge;
Dateiflags;
erweiterte Attribute.

Zu prüfen ist der gesamte benötigte Pfad. Schreibrechte auf eine Datei reichen beispielsweise nicht aus, wenn ein übergeordneter Ordner nicht betreten oder verändert werden darf.

Berechtigungen dürfen nicht pauschal mit chmod -R 777 geöffnet werden. Dadurch entstehen Sicherheitsprobleme, und bestehende ACLs oder Eigentümerfehler werden nicht zuverlässig behoben.

8.5.19 Datenschutzfreigaben und TCC

macOS schützt bestimmte Daten und Geräte zusätzlich zu den Unix-Berechtigungen.

Mögliche Freigaben sind unter anderem:

Dateien und Ordner;
Festplattenvollzugriff;
Kamera;
Mikrofon;
Bildschirm- und Systemaudioaufnahme;
Bedienungshilfen;
Automation;
Eingabeüberwachung;
Bluetooth;
lokales Netzwerk.

Ein Zugriff kann deshalb fehlschlagen, obwohl ls -l korrekte Unix-Berechtigungen anzeigt.

Prüfung:

„Systemeinstellungen → Datenschutz & Sicherheit“ öffnen.
Nur die für die App tatsächlich benötigte Kategorie auswählen.
Prüfen, ob die richtige App oder das richtige Terminalprogramm eingetragen ist.
Nach einer Änderung die betroffene App gegebenenfalls vollständig beenden und neu starten.
Funktion erneut testen.

Festplattenvollzugriff sollte nicht pauschal vergeben werden. Die kleinste benötigte Freigabe ist vorzuziehen.

8.5.20 App-Signatur, Gatekeeper und Quarantäne prüfen

Eine App kann wegen einer beschädigten Signatur, einer nicht vertrauenswürdigen Herkunft oder einer unvollständigen Installation nicht starten.

Signatur einer Beispiel-App prüfen:

codesign --verify --deep --strict --verbose=2 \
  "/Applications/Beispiel.app"

Gatekeeper-Bewertung prüfen:

spctl --assess --type execute --verbose=4 \
  "/Applications/Beispiel.app"

Erweiterte Attribute anzeigen:

xattr -l "/Applications/Beispiel.app"

Diese Befehle sind lesend.

Ein negatives Ergebnis sollte durch eine unveränderte, signierte Installationsdatei des Herstellers behoben werden. Das Entfernen von Quarantäneattributen, das Ad-hoc-Signieren oder das Deaktivieren von Gatekeeper ist keine allgemeine Fehlerlösung.

8.5.21 Anmeldeobjekte, Hintergrunddienste und Erweiterungen

Grafische Prüfung:

„Systemeinstellungen → Allgemein → Anmeldeobjekte & Erweiterungen“ öffnen.
„Bei der Anmeldung öffnen“ erfassen.
„Im Hintergrund erlauben“ erfassen.
installierte Erweiterungen prüfen.
unbekannte oder zeitlich zur Störung passende Drittanbieterkomponenten dokumentieren.

Systemerweiterungen anzeigen:

systemextensionsctl list

MDM-Registrierungsstatus prüfen:

profiles status -type enrollment

Sicherheitszustände können ergänzend gelesen werden:

fdesetup status
csrutil status
spctl --status

Diese Zustände dürfen nicht ohne begründete Anforderung verändert werden.

Wenn Anmeldeobjekte als Ursache vermutet werden:

vollständige Liste sichern;
verdächtige Drittanbieterobjekte kontrolliert deaktivieren;
ab- und wieder anmelden oder neu starten;
ursprüngliche Funktion testen;
Objekte einzeln wieder aktivieren;
den tatsächlich verursachenden Eintrag bestätigen.

8.5.22 Netzwerkabhängigkeiten kurz prüfen

Wenn eine App langsam ist oder einen Dienst nicht erreicht, muss zwischen lokalem Prozessproblem und externer Abhängigkeit unterschieden werden.

scutil --dns
route -n get default
netstat -rn
lsof -nP -iTCP -sTCP:LISTEN

Fragen:

Ist die lokale App blockiert oder wartet sie auf DNS?
Ist das Ziel per IP und Name erreichbar?
Ist ein erforderlicher lokaler Listener vorhanden?
Verhindern Proxy, VPN, Firewall oder lokaler Netzwerkzugriff die Verbindung?
Wartet die App auf einen Server, eine API, eine Freigabe oder einen Cloud-Dienst?

Die ausführliche Netzwerkdiagnose erfolgt nach den Abläufen aus Kapitel 3.

8.5.23 Fehler auf Benutzer, System oder Hardware eingrenzen

Test	Erkenntnis
Nur eine App betroffen	App-Konfiguration, App-Daten oder Abhängigkeit wahrscheinlich
Mehrere Apps eines Benutzers betroffen	Benutzerprofil, TCC, LaunchAgent oder Anmeldeobjekt möglich
Alle Benutzer betroffen	Systemdienst, systemweite Konfiguration, Datenträger oder Hardware möglich
Fehler nur mit einem externen Gerät	Gerät, Kabel, Adapter, Stromversorgung oder Treiber untersuchen
Fehler verschwindet nach App-Neustart	Prozesszustand wahrscheinlich, Ursache aber noch nicht bewiesen
Fehler verschwindet nach Abmeldung	Benutzerbezogener Agent oder Sitzungszustand möglich
Fehler verschwindet im sicheren Modus	Drittanbietererweiterung, Anmeldeobjekt oder zusätzlich geladene Komponente möglich
Fehler bleibt im sicheren Modus bestehen	Grundsystem, Benutzerdateien, Hardware oder weiterhin aktive Abhängigkeit untersuchen
Fehler tritt auch in der Wiederherstellung auf	Hardware oder Datenträger wird wahrscheinlicher
Apple Diagnose meldet Referenzcode	Hardwarebefund dokumentieren und nach Apple-Vorgabe weiterbearbeiten

8.5.24 Sicherer Modus

Der sichere Modus hilft zu prüfen, ob beim normalen Start zusätzlich geladene Software beteiligt ist.

Mac mit Apple-Chip:

Mac vollständig ausschalten.
Ein-/Ausschalter gedrückt halten, bis die Startoptionen erscheinen.
Startvolume auswählen.
Umschalttaste gedrückt halten.
„Im gesicherten Modus fortfahren“ auswählen.

Intel-Mac:

Mac einschalten oder neu starten.
Sofort die Umschalttaste gedrückt halten.
Taste loslassen, wenn das Anmeldefenster erscheint.

Der sichere Modus ist ein Kreuztest. Wenn der Fehler dort nicht auftritt, ist damit noch keine einzelne Ursache bewiesen. Anschließend müssen Anmeldeobjekte, Agents, Erweiterungen und Drittanbietersoftware einzeln geprüft werden.

Ein normaler Neustart beendet den sicheren Modus.

8.5.25 Apple Diagnose und Wiederherstellung

Apple Diagnose prüft Hardwarekomponenten.

Mac mit Apple-Chip:

Mac ausschalten.
Nicht benötigte externe Geräte trennen.
Ein-/Ausschalter gedrückt halten, bis die Startoptionen erscheinen.
Befehlstaste und D gedrückt halten, bis der Mac neu startet.
Diagnoseanweisungen befolgen.
angezeigte Referenzcodes dokumentieren.

Intel-Mac:

Mac einschalten.
Sofort D gedrückt halten.
Falls erforderlich, beim Start Option-D verwenden.
Diagnoseanweisungen befolgen.
Referenzcodes dokumentieren.

Die macOS-Wiederherstellung wird benötigt, wenn beispielsweise das Startvolume nicht im laufenden System repariert werden kann.

Apple-Chip: Ein-/Ausschalter bis zu den Startoptionen gedrückt halten und „Optionen“ auswählen.
Intel-Mac: beim Einschalten Command-R gedrückt halten.

Eine erfolgreiche Apple Diagnose schließt nicht jede denkbare Hardwarestörung aus. Sporadische Fehler, Kabelprobleme oder externe Geräte müssen weiterhin durch Kreuztests untersucht werden.

8.5.26 Systematischer Diagnoseablauf

Störung aufnehmen
Benutzer, App, Funktion, Zeitpunkt, Häufigkeit und genaue Meldung erfassen.
Umfang bestimmen
Eine App, ein Benutzer, alle Benutzer oder der gesamte Mac?
Basiszustand sichern
macOS-Version, Build, Architektur, Laufzeit, Installationshistorie und Speicherplatz dokumentieren.
Fehler reproduzieren
Zeitpunkt notieren und nur den erforderlichen Ablauf ausführen.
Prozess prüfen
Existenz, Benutzer, Elternprozess, Zustand, CPU, Speicher und offene Dateien untersuchen.
Dienstzuordnung prüfen
Richtiges launchd-Label und richtigen Bereich bestimmen.
Protokolle korrelieren
Meldungen unmittelbar vor, während und nach dem Fehler auswerten.
Ressourcen untersuchen
CPU, Speicherdruck, Swap, Datenträgerbelegung und I/O messen.
Zugriff prüfen
Unix-Berechtigungen, ACLs, TCC-Freigaben und App-Signatur unterscheiden.
Abhängigkeiten prüfen
Netzwerk, DNS, Server, API, Freigabe, Cloud-Dienst oder externes Gerät kontrollieren.
Fehlerdomäne isolieren
Anderer Benutzer, sicherer Modus, getrennte Peripherie oder Wiederherstellung verwenden.
Hypothese formulieren
Erwartetes Prüfergebnis und Gegenbeweis festlegen.
Eine kontrollierte Maßnahme durchführen
Risiko, Rückweg und Messkriterium dokumentieren.
Ursprüngliche Funktion verifizieren
Nicht nur den Prozessstatus, sondern den realen Benutzerablauf testen.
Nachkontrolle durchführen
Protokolle und Ressourcen erneut prüfen sowie Rückfall ausschließen.

8.5.27 Befundmatrix

Befund	Mögliche Erklärung	Nächster Nachweis
App-Prozess fehlt	App wurde nicht gestartet oder beendet sich sofort	Absturzbericht und zeitlich passende Logs prüfen
Prozess läuft, App reagiert nicht	Thread blockiert oder wartet auf Ressource	Prozessanalyse oder Spindump erstellen
Dienstlabel im `system`-Bereich nicht gefunden	Falsches Label, falscher Bereich oder Dienst nicht geladen	Property-List und tatsächliches Label prüfen
Agent fehlt im `gui/<UID>`-Bereich	Falscher Benutzer oder keine grafische Sitzung	UID und Anmeldesitzung prüfen
Dienst besitzt keine PID	On-Demand-Zustand oder Startfehler	Auslöser betätigen und Logs beobachten
Hohe CPU bei einem Prozess	Schleife, hohe Last oder fehlerhafte Verarbeitung	Mehrfach messen und Prozess analysieren
Niedrige CPU, App trotzdem langsam	Warten auf I/O, Netzwerk oder Sperre	`fs_usage`, Netzwerk und Prozessanalyse
Speicherdruck Gelb oder Rot	Speicherengpass	Speicherverbrauch und zeitliche Entwicklung prüfen
Swap wächst während der Störung	Arbeitsspeicher reicht für aktuelle Last nicht aus	verursachende Prozesse bestimmen
Startvolume fast voll	Apps, Updates, Logs und Swap beeinträchtigt	große Verzeichnisse und Snapshots prüfen
Viele lokale Snapshots	Speicher wird durch Snapshots mitbelegt	Time-Machine-Zustand und Richtlinie prüfen
Unix-Rechte korrekt, Zugriff trotzdem verweigert	TCC- oder Sandbox-Einschränkung	Datenschutzfreigabe der richtigen App prüfen
Signaturprüfung schlägt fehl	App beschädigt oder verändert	Originaldatei des Herstellers vergleichen
Nur ein Benutzer betroffen	Benutzerprofil, LaunchAgent oder TCC	anderes Benutzerkonto als Kreuztest
Fehler verschwindet im sicheren Modus	zusätzliche Software beteiligt	Drittanbieterkomponenten einzeln prüfen
Kernel-Panics treten wiederholt auf	Treiber-, Erweiterungs- oder Hardwareproblem	Panic-Berichte, Peripherietest und Apple Diagnose
Prozess und Port sind vorhanden, Funktion scheitert	Abhängigkeit oder Anwendungsebene fehlerhaft	vollständigen Benutzerpfad Ende zu Ende prüfen

8.5.28 Mögliche Ursachen und erforderliche Nachweise

Mögliche Ursache	Erforderlicher Nachweis
Fehlerhafte App-Konfiguration	Fehler ist mit gesicherter Standardkonfiguration reproduzierbar beziehungsweise verschwindet kontrolliert ohne diese Konfiguration
Beschädigte App-Installation	Signatur- oder Integritätsprüfung schlägt fehl und eine unveränderte Herstellerinstallation funktioniert
Fehlerhafter LaunchAgent	Fehler tritt nur im zugehörigen Benutzerkontext auf und verschwindet nach kontrollierter Deaktivierung
Fehlerhafter LaunchDaemon	Systemweiter Fehler korreliert mit Dienststatus, Logs und reproduzierbarem Neustartverhalten
CPU-Engpass	CPU ist während der Störung dauerhaft ausgelastet und der verursachende Prozess ist bestimmt
Speicherengpass	Speicherdruck und Swap wachsen während der reproduzierten Störung
Voller Datenträger	Freier Speicher ist kritisch niedrig und die Funktion arbeitet nach kontrollierter Freigabe wieder
APFS- oder Dateisystemfehler	`diskutil`, Erste Hilfe oder Systemprotokolle melden konkrete Fehler
Berechtigungsfehler	Zugriff scheitert mit konkretem Berechtigungsbefund und funktioniert nach minimaler Korrektur
TCC-Verweigerung	Benötigte Datenschutzfreigabe fehlt und die Funktion arbeitet nach gezielter Freigabe
Netzwerkabhängigkeit	Lokaler Prozess arbeitet, aber DNS, Verbindung oder Zielsystem scheitert reproduzierbar
Drittanbietererweiterung	Fehler verschwindet im sicheren Modus und kehrt mit der einzeln aktivierten Erweiterung zurück
Hardwarefehler	Apple Diagnose, wiederkehrende Panic-Berichte oder unabhängige Kreuztests belegen den Fehler

8.5.29 Kontrollierte Maßnahmen, Risiko und Rückweg

Maßnahme	Risiko	Rückweg
App regulär beenden und neu öffnen	Nicht gespeicherte Daten	App erneut starten und gesicherte Daten öffnen
Prozess mit `SIGTERM` beenden	Funktionsunterbrechung	App oder Dienst kontrolliert neu starten
Drittanbieterdienst mit `kickstart` neu starten	Kurzzeitiger Dienstausfall	dokumentierten Ausgangszustand und Konfiguration wiederherstellen
Anmeldeobjekt vorübergehend deaktivieren	Funktion steht nach Anmeldung nicht bereit	Eintrag anhand der gesicherten Liste wieder aktivieren
TCC-Freigabe gezielt erteilen	zusätzlicher Datenzugriff	Freigabe nach Test wieder entziehen
Drittanbieter-App aktualisieren	neue Version kann Konfiguration verändern	Installationsdatei und Konfiguration der vorherigen Version sichern
App aus Originalquelle neu installieren	lokale App-Bestandteile werden ersetzt	Konfiguration und Benutzerdaten vorher sichern
Nicht benötigte Benutzerdaten verschieben	Datei steht am alten Ort nicht mehr bereit	Datei aus dem Sicherungsort zurückverschieben
Sicherer Modus	eingeschränkte Funktionen	normal neu starten
Erste Hilfe ausführen	zusätzliche Datenträgerbelastung	aktuelles Backup bereithalten; bei Fehler abbrechen und Befund sichern
Peripheriegerät trennen	zugehörige Funktion steht nicht bereit	Gerät nach Test wieder anschließen

Pro Maßnahme darf möglichst nur eine relevante Variable verändert werden.

8.5.30 Verifikation

Nach einer Maßnahme müssen mindestens folgende Prüfungen erfolgen:

ursprünglicher Benutzerablauf funktioniert vollständig;
App startet und reagiert;
benötigter Dienst wird im richtigen Kontext ausgeführt;
erwartete Datei- und Netzwerkzugriffe funktionieren;
keine neuen Fehler oder Fault-Meldungen erscheinen;
CPU-Auslastung normalisiert sich;
Speicherdruck bleibt im normalen Bereich;
Swap wächst nicht weiter ungewöhnlich;
ausreichender Datenträgerspeicher ist vorhanden;
temporär erteilte Rechte wurden geprüft oder zurückgenommen;
deaktivierte Sicherheitsfunktionen wurden nicht als Dauerlösung belassen;
Funktion bleibt nach Ab- und Anmeldung stabil;
falls relevant, Funktion bleibt nach einem kontrollierten Neustart stabil;
keine andere Benutzerfunktion wurde beeinträchtigt.

8.5.31 Präventionsmaßnahmen

macOS und Anwendungen kontrolliert aktuell halten;
vor Updates Kompatibilität geschäftskritischer Software prüfen;
ausreichend freien Datenträgerspeicher vorhalten;
Backups regelmäßig durchführen und Wiederherstellung testen;
Anmeldeobjekte und Hintergrunddienste dokumentieren;
nicht mehr benötigte Drittanbietererweiterungen entfernen;
Datenschutzfreigaben nach dem Minimalprinzip vergeben;
Installationsquellen und Signaturen prüfen;
Baseline-Werte für CPU, Speicher, Datenträger und Startzeit erfassen;
zentrale oder regelmäßige Protokollauswertung für wichtige Systeme einrichten;
Änderungen mit Zeitpunkt, Version und Rückweg dokumentieren;
Systemdiagnosen und Protokolle datenschutzgerecht behandeln;
bei wiederkehrenden Kernel-Panics Hardware und Erweiterungen frühzeitig isolieren.

8.5.32 Typische Fehler bei der Diagnose

Einen Prozess allein wegen eines hohen Einzelwerts beenden.
Einen fehlenden PID-Wert automatisch als Dienstfehler interpretieren.
Einen Agent im system-Bereich suchen, obwohl er im Benutzerkontext läuft.
Nur nach dem Wort „error“ suchen und Zeit, Prozess oder Subsystem ignorieren.
Alte Protokollmeldungen mit dem aktuellen Fehler verwechseln.
Freien RAM als einziges Speicherkriterium verwenden.
APFS-Container, Volume, Snapshot und physisches Laufwerk gleichsetzen.
Unix-Berechtigungen und TCC-Freigaben verwechseln.
Gatekeeper oder SIP zum Testen dauerhaft deaktivieren.
chmod -R 777 als allgemeine Berechtigungslösung verwenden.
unbekannte Systemdateien oder lokale Snapshots manuell löschen.
sofort kill -9 verwenden.
nach einem Neustart den vorherigen flüchtigen Zustand nicht mehr rekonstruieren können.
nur prüfen, ob ein Prozess läuft, statt die ursprüngliche Benutzerfunktion zu testen.

8.5.33 Typische Prüfungsfragen

Warum beweist ein laufender Prozess noch keine funktionierende Anwendung?

Der Prozess kann blockiert sein, auf eine Ressource warten oder eine benötigte Abhängigkeit nicht erreichen. Entscheidend ist die vollständige Benutzerfunktion.

Was ist der Unterschied zwischen einem LaunchDaemon und einem LaunchAgent?

Ein LaunchDaemon arbeitet systemweit. Ein LaunchAgent arbeitet im Kontext eines Benutzers beziehungsweise einer Benutzeranmeldung.

Warum kann ein registrierter launchd-Dienst keine PID besitzen, ohne fehlerhaft zu sein?

Bedarfsgesteuerte Dienste werden möglicherweise erst gestartet, wenn ein definierter Auslöser eintritt.

Warum ist der Speicherdruck aussagekräftiger als nur der freie Arbeitsspeicher?

macOS nutzt freien Speicher unter anderem für Caches und Komprimierung. Der Speicherdruck zeigt besser, ob die Speicherverwaltung die aktuelle Last noch ausreichend bewältigt.

Warum sollte kill -9 nicht als erste Maßnahme verwendet werden?

Der Prozess erhält keine Möglichkeit, Dateien zu schließen, Daten zu speichern oder seinen Zustand geordnet zu bereinigen.

Warum können korrekte Unix-Berechtigungen trotzdem zu einer Zugriffsverweigerung führen?

Zusätzliche macOS-Schutzmechanismen wie TCC können den Zugriff auf Dateien, Geräte oder geschützte Daten verhindern.

Was bedeutet es, wenn ein Fehler im sicheren Modus nicht auftritt?

Zusätzlich geladene Software, Anmeldeobjekte oder Erweiterungen werden wahrscheinlicher. Eine konkrete Ursache ist dadurch noch nicht bewiesen.

Warum müssen Protokolle zeitlich mit der Störung korreliert werden?

Ein System erzeugt auch im Normalbetrieb Warnungen und Fehler. Erst die zeitliche und funktionale Übereinstimmung macht eine Meldung für den konkreten Vorfall relevant.

Warum ersetzt eine erfolgreiche Erste-Hilfe-Prüfung kein Backup?

Die Prüfung schützt nicht vor späterem Hardwareausfall, versehentlichem Löschen oder bereits beschädigten beziehungsweise fehlenden Benutzerdaten.

8.5.34 Checkliste

8.5.35 Schnellreferenz

Aufgabe	Befehl oder Werkzeug
macOS-Version	`sw_vers`
Prozessorarchitektur	`uname -m`
Systemlaufzeit	`uptime`
Hardware- und Softwarebericht	`system_profiler SPHardwareDataType SPSoftwareDataType`
Prozesse	`ps -axo pid,ppid,user,state,%cpu,%mem,etime,command`
Live-Ressourcen	`top` oder Aktivitätsanzeige
Prozess suchen	`pgrep -fl "Prozessname"`
offene Dateien eines Prozesses	`lsof -nP -p 1234`
Prozess analysieren	`sample 1234 10 -file Bericht.txt`
Systemweite launchd-Dienste	`launchctl print system`
Benutzer-Agents	`launchctl print gui/$(id -u)`
Property-List prüfen	`plutil -lint Datei.plist`
letzte Protokolle	`log show --last 30m`
Protokolle live	`log stream`
Arbeitsspeicher	`vm_stat`
Swap	`sysctl vm.swapusage`
Speicherbelegung	`df -h`
Datenträgerstruktur	`diskutil list`
APFS-Struktur	`diskutil apfs list`
lokale Snapshots	`tmutil listlocalsnapshots /`
Datenträger-I/O	`iostat -w 2 -c 5`
Dateiaktivität	`sudo fs_usage`
Berechtigungen und ACLs	`ls -ldeO@ Pfad`
Systemerweiterungen	`systemextensionsctl list`
MDM-Status	`profiles status -type enrollment`
App-Signatur	`codesign --verify`
Gatekeeper-Bewertung	`spctl --assess`
grafische Protokolle	Konsole
CPU, Speicher und I/O	Aktivitätsanzeige
Dateisystemprüfung	Festplattendienstprogramm
Hardwareprüfung	Apple Diagnose

8.5.36 Quellen

Offizielle Apple-Dokumentation

Befehlsreferenzen

Die maßgebliche Befehlsreferenz ist die jeweilige lokale macOS-Manpage:

man launchd
man launchctl
man log
man vm_stat
man diskutil
man fs_usage
man system_profiler

Der folgende Spiegel stellt aus Xcode extrahierte Manpages bereit, ist jedoch keine offizielle Apple-Supportseite. Bei Abweichungen gilt die lokale Manpage der installierten macOS-Version:

Revision #1
Created 2 August 2026 12:51:12 by Admin
Updated 2 August 2026 12:51:29 by Admin