8.1 Windows-Prozesse und Dienste gezielt untersuchen
Kurzbeschreibung
Wenn ein Windows-System langsam reagiert, eine Anwendung nicht startet, ein Dienst ausfällt oder ein Prozess ungewöhnliche Ressourcen verbraucht, muss der verursachende Prozess einschließlich seiner Abhängigkeiten untersucht werden.
Windows-Bordmittel und die Microsoft-Sysinternals-Werkzeuge ermöglichen unter anderem die Analyse von:
- Prozessen und untergeordneten Prozessen,
- Diensten,
- Threads,
- CPU- und Arbeitsspeichernutzung,
- geöffneten Dateien und Handles,
- geladenen DLLs,
- Registry-Zugriffen,
- Dateisystemzugriffen,
- Netzwerkverbindungen,
- Autostarteinträgen,
- Programmabstürzen,
- nicht mehr reagierenden Anwendungen.
Ein auffälliger Prozess ist nicht automatisch die eigentliche Ursache. Er kann selbst auf eine Datei, eine Sperre, einen Treiber, eine Datenbank, das Netzwerk oder einen anderen Dienst warten.
1. Typische Symptome
- Anwendung startet nicht.
- Anwendung reagiert nicht mehr.
- Dienst beendet sich unerwartet.
- Dienst bleibt im Zustand „Wird gestartet“ oder „Wird beendet“.
- CPU-Auslastung ist dauerhaft hoch.
- Arbeitsspeicherverbrauch wächst kontinuierlich.
- Datenträger wird durch einen Prozess stark ausgelastet.
- Datei kann nicht gelöscht, verschoben oder überschrieben werden.
- Anwendung meldet „Zugriff verweigert“.
- Prozess öffnet ungewöhnlich viele Dateien oder Registry-Schlüssel.
- Netzwerkverbindung wird von einem unbekannten Prozess hergestellt.
- Programm funktioniert nur mit Administratorrechten.
- Fehler tritt nur nach der Anmeldung oder nach einem Neustart auf.
- Systemstart oder Benutzeranmeldung dauert ungewöhnlich lange.
- Anwendung stürzt ohne eindeutige Fehlermeldung ab.
- Ereignisanzeige enthält Anwendungs-, Dienst- oder Treiberfehler.
- Prozesse werden mehrfach oder unerwartet gestartet.
- Anwendung funktioniert nach einem Prozessneustart nur vorübergehend.
2. Mögliche Auswirkungen
- einzelne Anwendung nicht verfügbar,
- Hintergrunddienst ausgefallen,
- mehrere Benutzer betroffen,
- Serverdienst nicht erreichbar,
- Leistungsprobleme des gesamten Systems,
- blockierte Dateien oder Verzeichnisse,
- Datenverlust durch einen Programmabsturz,
- fehlgeschlagene Sicherung oder Synchronisation,
- fehlerhafte Anmeldung oder Benutzerprofilinitialisierung,
- Sicherheitsrisiko durch unbekannten Prozess,
- Produktionsausfall bei geschäftskritischen Diensten.
3. Sicherheits- und Betriebswarnung
Sysinternals-Werkzeuge können tiefgehende Informationen über Prozesse, Benutzer, Dateien und Netzwerkverbindungen anzeigen. Diagnoseergebnisse können enthalten:
- Benutzernamen,
- interne Pfade,
- Servernamen,
- IP-Adressen,
- Befehlszeilenargumente,
- Zugriffstoken,
- geladene Module,
- Registry-Inhalte,
- personenbezogene Daten.
Besondere Vorsicht gilt bei:
- Beenden eines Prozesses,
- Stoppen oder Neustarten eines Dienstes,
- Schließen eines Handles,
- Deaktivieren eines Autostarteintrags,
- Erstellen eines vollständigen Speicherabbilds,
- länger laufender Process-Monitor-Aufzeichnung,
- Aktivieren zusätzlicher Debugprotokollierung.
Ein vollständiges Speicherabbild kann sensible Daten wie Kennwörter, Tokens, Schlüssel oder Anwendungsdaten enthalten. Dump-, ETL- und PML-Dateien müssen deshalb geschützt gespeichert und nach Abschluss der Analyse kontrolliert gelöscht werden.
Werkzeuge sollten nur aus der offiziellen Microsoft-Quelle bezogen werden. Vor dem Einsatz auf einem Produktivsystem sind Auswirkung, benötigter Speicherplatz und mögliche Leistungseinflüsse zu prüfen.
4. Werkzeugauswahl
| Fragestellung | Geeignetes Werkzeug |
|---|---|
| Welcher Prozess benötigt CPU oder RAM? | Task-Manager, Ressourcenmonitor, PowerShell, Process Explorer |
| Welcher Dienst gehört zu einem Prozess? | Task-Manager, tasklist /svc, Process Explorer |
| Welcher Prozess hat eine Datei geöffnet? | Ressourcenmonitor, Handle, Process Explorer |
| Welche DLLs hat ein Prozess geladen? | Process Explorer, ListDLLs |
| Warum erhält eine Anwendung „Zugriff verweigert“? | Process Monitor, AccessChk |
| Welcher Prozess stellt eine Netzwerkverbindung her? | TCPView, Get-NetTCPConnection |
| Was wird beim Systemstart automatisch geladen? | Autoruns |
| Warum stürzt eine Anwendung ab? | Ereignisanzeige, Zuverlässigkeitsverlauf, ProcDump, WinDbg |
| Warum reagiert ein Prozess nicht mehr? | Process Explorer, ProcDump, Wait-Chain-Analyse |
| Welcher Prozess erzeugt Registry- oder Dateisystemzugriffe? | Process Monitor |
| Warum ist das System zeitweise langsam? | Leistungsüberwachung, WPR und WPA |
| Wie hängen Prozesse zusammen? | Process Explorer |
| Welche Prozesse sind signiert? | Process Explorer, Sigcheck |
| Welche Berechtigung besitzt ein Benutzer oder Dienst? | AccessChk, whoami |
5. Benötigte Informationen
Vor der Diagnose sollten mindestens folgende Informationen vorliegen:
Computer:
Betriebssystem und Build:
betroffene Anwendung:
betroffener Dienst:
Prozessname:
Prozess-ID:
Benutzerkonto des Prozesses:
Beginn des Problems:
exakte Fehlermeldung:
Fehlercode oder Event-ID:
reproduzierbar:
letzter funktionierender Zeitpunkt:
letzte Änderung:
betroffene Benutzer:
Auswirkung:
bereits durchgeführte Maßnahmen:
Zusätzlich hilfreich:
- Installations- oder Updatezeitpunkt,
- Anwendungsversion,
- Dienstkonto,
- erwartete Netzwerkziele,
- erwartete Dateien und Registry-Pfade,
- funktionierendes Vergleichssystem,
- Baseline der normalen Ressourcennutzung.
6. Ausgangszustand sichern
Vor einem Neustart oder dem Beenden eines Prozesses sollten flüchtige Informationen dokumentiert werden.
Get-Date
Get-ComputerInfo |
Select-Object WindowsProductName,
WindowsVersion,
OsBuildNumber,
OsLastBootUpTime
Laufende Prozesse sichern:
Get-Process |
Sort-Object ProcessName |
Select-Object ProcessName,
Id,
CPU,
WorkingSet64,
Handles,
Threads
Laufende Dienste sichern:
Get-Service |
Where-Object Status -eq 'Running' |
Sort-Object Name
Aktive TCP-Verbindungen sichern:
Get-NetTCPConnection |
Select-Object LocalAddress,
LocalPort,
RemoteAddress,
RemotePort,
State,
OwningProcess
Ereignisse der letzten zwei Stunden:
Get-WinEvent -FilterHashtable @{
LogName = 'System', 'Application'
StartTime = (Get-Date).AddHours(-2)
} |
Select-Object TimeCreated,
LogName,
Id,
LevelDisplayName,
ProviderName,
Message
Die Ausgabe kann bei Bedarf kontrolliert in Dateien exportiert werden. Dabei sind Datenschutz und Speicherort zu beachten.
7. Sichere Schnellprüfung
- Exakte Fehlermeldung und Uhrzeit dokumentieren.
- Prozess- und Dienststatus prüfen.
- CPU, Arbeitsspeicher, Handles und Threads vergleichen.
- System- und Anwendungsereignisse zum Fehlerzeitpunkt untersuchen.
- Mit Process Explorer Prozessbaum und Eigenschaften prüfen.
- Mit Process Monitor nur den betroffenen Prozess aufzeichnen.
- Netzwerkverbindungen mit TCPView oder PowerShell prüfen.
- Erst nach gesicherter Diagnose eine kontrollierte Maßnahme durchführen.
8. Prozesse mit PowerShell untersuchen
Alle Prozesse anzeigen:
Get-Process
Prozesse nach CPU-Gesamtzeit sortieren:
Get-Process |
Sort-Object CPU -Descending |
Select-Object -First 15 ProcessName,
Id,
CPU,
WorkingSet64,
Handles,
Threads
Prozesse nach Arbeitsspeicher sortieren:
Get-Process |
Sort-Object WorkingSet64 -Descending |
Select-Object -First 15 ProcessName,
Id,
WorkingSet64,
PagedMemorySize64,
VirtualMemorySize64
Prozesse mit vielen Handles:
Get-Process |
Sort-Object Handles -Descending |
Select-Object -First 15 ProcessName,
Id,
Handles
Bestimmten Prozess untersuchen:
Get-Process -Id <PID> |
Format-List *
Prozess mit CIM einschließlich Befehlszeile und Elternprozess:
Get-CimInstance Win32_Process |
Where-Object ProcessId -eq <PID> |
Select-Object Name,
ProcessId,
ParentProcessId,
ExecutablePath,
CommandLine,
CreationDate
Der Wert CPU bei Get-Process ist die seit dem Prozessstart verbrauchte Prozessorzeit und keine momentane prozentuale CPU-Auslastung.
9. Prozess-ID und Dienst zuordnen
Eine Prozess-ID kann sich nach jedem Neustart des Prozesses ändern. Bei der Dokumentation müssen deshalb PID, Zeitpunkt und Prozessstart zusammen betrachtet werden.
Windows-Befehl:
tasklist /svc
Bestimmte PID suchen:
tasklist /svc /fi "PID eq <PID>"
Dienste einschließlich Prozess-ID:
Get-CimInstance Win32_Service |
Select-Object Name,
DisplayName,
State,
StartMode,
ProcessId,
StartName
Dienst zu einer PID suchen:
Get-CimInstance Win32_Service |
Where-Object ProcessId -eq <PID> |
Select-Object Name,
DisplayName,
State,
StartMode,
StartName
Mehrere Windows-Dienste können innerhalb desselben svchost.exe-Prozesses ausgeführt werden. Der Prozessname allein reicht deshalb nicht zur eindeutigen Zuordnung.
10. Dienste untersuchen
Alle Dienste:
Get-Service |
Sort-Object Status, Name
Automatisch startende, aber nicht laufende Dienste:
Get-CimInstance Win32_Service |
Where-Object {
$_.StartMode -eq 'Auto' -and
$_.State -ne 'Running'
} |
Select-Object Name,
DisplayName,
State,
StartMode,
StartName,
ExitCode
Bestimmten Dienst prüfen:
Get-Service -Name <Dienstname>
Ausführliche Dienstkonfiguration:
sc.exe qc <Dienstname>
Aktuellen Dienststatus:
sc.exe queryex <Dienstname>
Abhängigkeiten anzeigen:
Get-Service -Name <Dienstname> -DependentServices
Get-Service -Name <Dienstname> -RequiredServices
Zu prüfen sind:
- Starttyp,
- aktueller Status,
- Dienstkonto,
- ausführbare Datei,
- Abhängigkeiten,
- Rücksetzungs- und Wiederherstellungsoptionen,
- Exit-Code,
- wiederholte Neustarts,
- Zeitüberschreitungen beim Start,
- benötigte Dateien und Netzwerkziele.
Ein Dienst darf nicht allein deshalb gestartet werden, weil sein Starttyp auf „Automatisch“ steht. Verzögert gestartete Dienste, Triggerstart, Clustersteuerung oder bewusst deaktivierte Komponenten müssen berücksichtigt werden.
11. Ereignisanzeige untersuchen
Wichtige Protokollbereiche:
- Windows-Protokolle → Anwendung
- Windows-Protokolle → System
- Windows-Protokolle → Sicherheit
- Anwendungs- und Dienstprotokolle
- Microsoft → Windows → Windows Error Reporting
- Microsoft → Windows → Diagnostics-Performance
- herstellerspezifische Anwendungsprotokolle
Fehler und Warnungen der letzten zwei Stunden:
Get-WinEvent -FilterHashtable @{
LogName = 'System', 'Application'
Level = 2, 3
StartTime = (Get-Date).AddHours(-2)
} |
Select-Object TimeCreated,
LogName,
Id,
ProviderName,
LevelDisplayName,
Message
Ereignisse eines bestimmten Anbieters:
Get-WinEvent -FilterHashtable @{
LogName = 'Application'
ProviderName = '<Provider>'
StartTime = (Get-Date).AddHours(-2)
}
Ereignisse eines bestimmten Zeitraums:
$Start = Get-Date '2026-08-02 09:00:00'
$Ende = Get-Date '2026-08-02 10:00:00'
Get-WinEvent -FilterHashtable @{
LogName = 'System', 'Application'
StartTime = $Start
EndTime = $Ende
}
Wichtige Grundregel:
Zuerst nach Zeitpunkt, betroffener Komponente und technischer Wirkung filtern. Nicht jeder Fehler oder jede Warnung in der Ereignisanzeige gehört zur untersuchten Störung.
12. Dienstfehler im Systemprotokoll
Der Service Control Manager protokolliert Start-, Stopp- und Dienstfehler im Systemprotokoll.
Beispielhafte Abfrage:
Get-WinEvent -FilterHashtable @{
LogName = 'System'
ProviderName = 'Service Control Manager'
StartTime = (Get-Date).AddHours(-4)
} |
Select-Object TimeCreated,
Id,
LevelDisplayName,
Message
Häufig relevante Ereignisarten betreffen:
- unerwartet beendete Dienste,
- fehlgeschlagene Dienststarts,
- Zeitüberschreitungen,
- ungültige Dienstkonten,
- fehlende Dateien,
- fehlerhafte Abhängigkeiten.
Event-IDs dürfen nicht ohne Prüfung von Provider, Windows-Version und vollständigem Ereignistext interpretiert werden.
13. Process Explorer verwenden
Process Explorer zeigt Prozesse hierarchisch in einem Prozessbaum an.
Wichtige Informationen:
- Eltern- und Kindprozesse,
- Benutzerkonto,
- Integritätsstufe,
- Befehlszeile,
- ausführbare Datei,
- digitale Signatur,
- Prozessstart,
- CPU-Auslastung,
- private Bytes,
- Working Set,
- Threads,
- Handles,
- geladene DLLs,
- TCP/IP-Aktivität,
- Sicherheits-Token.
Empfohlene Vorgehensweise:
- Process Explorer als Administrator starten, wenn erhöhte Prozesse untersucht werden müssen.
-
View → Show Process Treeverwenden. - Unter
View → Select Columnsbenötigte Spalten aktivieren. - Betroffenen Prozess markieren.
- Eigenschaften des Prozesses öffnen.
- Image, Performance, Threads, TCP/IP und Security prüfen.
- Prozesspfad und digitale Signatur kontrollieren.
- Eltern- und Kindprozesse dokumentieren.
- Auffällige Threads oder Handles untersuchen.
- Prozess erst nach Sicherung der Ergebnisse verändern.
Hilfreiche Markierungen im Prozessbaum können auf unterschiedliche Prozessarten oder Lebenszyklen hinweisen. Die Farbdarstellung ist konfigurierbar und darf nicht ohne Prüfung der eingestellten Farblegende interpretiert werden.
14. Threads untersuchen
Ein Prozess kann insgesamt unauffällig erscheinen, obwohl ein einzelner Thread dauerhaft einen CPU-Kern beansprucht.
In Process Explorer:
- Prozess öffnen.
- Registerkarte
Threadsauswählen. - Threads nach CPU-Auslastung sortieren.
- Thread-ID und Startadresse dokumentieren.
- bei verfügbaren Symbolen den Stack untersuchen.
- geladenes Modul oder zugehörige DLL bestimmen.
Mögliche Befunde:
| Befund | Mögliche Bedeutung |
|---|---|
| ein Thread dauerhaft stark ausgelastet | Endlosschleife oder Single-Thread-Engpass |
| viele Threads entstehen fortlaufend | Thread-Leak oder fehlerhafte Parallelisierung |
| Thread wartet lange | Datei, Netzwerk, Lock oder externe Komponente |
| Startadresse gehört zu Drittanbieter-DLL | Anwendung oder Erweiterung untersuchen |
| Startadresse gehört zu Sicherheitssoftware | Scan oder Filtertreiber als mögliche Beteiligung prüfen |
| Prozess hat ungewöhnlich viele Threads | Worker-Konfiguration, Deadlock oder fehlerhafte Anwendung |
Das Beenden eines einzelnen Threads kann den Prozess beschädigen und ist keine sichere Standardmaßnahme.
15. Nicht reagierende Anwendungen und Wait Chains
Eine Anwendung kann als „Keine Rückmeldung“ erscheinen, wenn ihr Oberflächenthread nicht rechtzeitig auf Windows-Nachrichten reagiert.
Mögliche Ursachen:
- lang laufende Berechnung,
- blockierte Dateioperation,
- Netzwerk-Timeout,
- Datenbankabfrage,
- gegenseitige Sperre,
- blockierter untergeordneter Prozess,
- nicht reagierende Erweiterung,
- Treiberproblem.
Im Ressourcenmonitor kann über die CPU-Ansicht bei einem Prozess die Warteschlange beziehungsweise Wait Chain analysiert werden.
Ein möglicher Deadlock liegt vor, wenn mehrere Threads oder Prozesse gegenseitig auf Ressourcen warten. Die Wait-Chain-Analyse liefert einen Hinweis, aber nicht immer einen vollständigen Ursachennachweis.
Vor dem Beenden eines wartenden Prozesses sollten Dump, Ereignisse und Anwendungslogs gesichert werden.
16. Geöffnete Dateien und Handles untersuchen
Eine Datei kann nicht gelöscht oder umbenannt werden, wenn ein Prozess ein passendes Handle geöffnet hält.
Process Explorer:
-
Find → Find Handle or DLLöffnen. - Teil des Datei- oder Verzeichnisnamens eingeben.
- gefundenen Prozess und Handle-Typ prüfen.
- Anwendung möglichst regulär schließen.
- erst danach einen kontrollierten Prozess- oder Dienstneustart erwägen.
Handle als Kommandozeilenwerkzeug:
handle.exe "<Dateiname-oder-Pfad>"
Nach PID filtern:
handle.exe -p <PID>
Das direkte Schließen eines Handles kann:
- Datenverlust verursachen,
- eine Anwendung zum Absturz bringen,
- einen inkonsistenten Zustand erzeugen,
- eine Transaktion oder Sperrlogik beschädigen.
Ein Handle sollte deshalb nicht als erste Maßnahme erzwungen geschlossen werden.
17. Geladene DLLs untersuchen
Process Explorer kann im unteren Fensterbereich Handles oder geladene DLLs anzeigen.
Umschalten:
View → Lower Pane View → DLLs
Zu prüfen sind:
- vollständiger DLL-Pfad,
- Hersteller,
- digitale Signatur,
- Version,
- Ladezeitpunkt,
- unerwartete Verzeichnisse,
- unterschiedliche Versionen derselben Bibliothek,
- nicht signierte Erweiterungen.
ListDLLs:
listdlls.exe <Prozessname>
Nach einer bestimmten DLL suchen:
listdlls.exe -d <DLL-Name>
Eine unbekannte oder nicht signierte DLL ist nicht automatisch Schadsoftware. Sie muss anhand von Pfad, Hersteller, Signatur, Hash, Installationszusammenhang und Sicherheitsprüfung bewertet werden.
18. Process Monitor verwenden
Process Monitor zeichnet in Echtzeit unter anderem folgende Ereignisse auf:
- Dateisystemzugriffe,
- Registry-Zugriffe,
- Prozess- und Threadaktivität,
- Laden von DLLs,
- bestimmte Profilierungsereignisse.
Da sehr viele Ereignisse entstehen können, muss die Aufzeichnung gefiltert und zeitlich begrenzt werden.
Empfohlener Ablauf:
- Process Monitor starten.
- Aufzeichnung zunächst anhalten.
- vorhandene Ereignisse leeren.
- Filter für den betroffenen Prozess setzen.
- nur benötigte Ereignisklassen aktivieren.
- Aufzeichnung starten.
- Fehler genau einmal reproduzieren.
- Aufzeichnung sofort anhalten.
- Ereignisse rund um den Fehlerzeitpunkt untersuchen.
- Aufzeichnung geschützt speichern oder nach Abschluss löschen.
Beispielhafte Filter:
Process Name is <Anwendung.exe> then Include
oder:
PID is <PID> then Include
Zusätzliche Filter können beispielsweise betreffen:
Result is ACCESS DENIED
Result is NAME NOT FOUND
Result is PATH NOT FOUND
Operation is CreateFile
Operation is RegOpenKey
19. Process-Monitor-Ergebnisse bewerten
Häufige Ergebnisse:
| Ergebnis | Bedeutung |
|---|---|
SUCCESS |
Operation wurde erfolgreich ausgeführt |
NAME NOT FOUND |
Objekt mit diesem Namen wurde nicht gefunden |
PATH NOT FOUND |
Teil des Pfades wurde nicht gefunden |
ACCESS DENIED |
Zugriff wurde durch Berechtigung oder Sicherheitsmechanismus verweigert |
SHARING VIOLATION |
Objekt wird in nicht kompatibler Weise verwendet |
BUFFER OVERFLOW |
häufig normaler Teil einer Größenabfrage |
NO MORE FILES |
Verzeichnisaufzählung ist beendet |
REPARSE |
Pfad wurde über einen Reparse Point weitergeleitet |
Nicht jeder rote oder fehlgeschlagene Eintrag ist ein Fehler. Anwendungen prüfen häufig mehrere mögliche Pfade, Registry-Schlüssel oder Dateinamen, bevor sie den tatsächlich vorhandenen Eintrag verwenden.
Ein relevanter Befund entsteht erst, wenn:
- der Zeitpunkt mit dem Symptom übereinstimmt,
- das Objekt für die Funktion benötigt wird,
- keine erfolgreiche Ausweichoperation folgt,
- das Ergebnis technisch zum Fehler passt,
- der Fehler reproduzierbar ist.
20. „Zugriff verweigert“ untersuchen
Mögliche Ursachen:
- fehlende NTFS-Berechtigung,
- fehlende Freigabeberechtigung,
- fehlendes Benutzerrecht,
- niedrige Integritätsstufe,
- UAC,
- Dienstkonto ohne erforderliche Rechte,
- Datei durch Sicherheitssoftware blockiert,
- Controlled Folder Access,
- Zugriff auf geschützten Registry-Bereich,
- Netzwerkzugriff unter einem anderen Konto,
- Anwendung verwendet einen falschen Pfad.
Aktuelle Identität:
whoami
Gruppen und Sicherheitskennungen:
whoami /groups
Privilegien:
whoami /priv
Effektive NTFS-Berechtigungen sollten mit den Windows-Sicherheitseinstellungen oder einem kontrollierten Werkzeug geprüft werden.
AccessChk-Beispiel:
accesschk.exe -nobanner -v "<Benutzer>" "<Pfad>"
Die genaue Syntax ist vor dem produktiven Einsatz anhand der aktuellen Microsoft-Dokumentation zu prüfen.
Die dauerhafte Ausführung einer Anwendung als Administrator ist keine fachgerechte Standardlösung. Stattdessen muss die konkret fehlende Berechtigung identifiziert und nach dem Minimalprinzip vergeben werden.
21. Netzwerkverbindungen einem Prozess zuordnen
PowerShell:
Get-NetTCPConnection |
Sort-Object State, RemoteAddress |
Select-Object LocalAddress,
LocalPort,
RemoteAddress,
RemotePort,
State,
OwningProcess
Verbindungen eines bestimmten Prozesses:
Get-NetTCPConnection |
Where-Object OwningProcess -eq <PID>
Prozess zuordnen:
Get-Process -Id <PID>
TCPView zeigt:
- lokale Adresse,
- lokalen Port,
- entfernte Adresse,
- entfernten Port,
- Verbindungsstatus,
- zugehörigen Prozess,
- Prozess-ID.
Zu prüfen sind:
- erwartetes Ziel,
- erwarteter Port,
- wiederholte Verbindungsversuche,
- viele Verbindungen im selben Zustand,
- Verbindung zu nicht erwarteten Systemen,
- Verbindung nur über IPv4 oder IPv6,
- kurzzeitig entstehende Verbindungen,
- Portkonflikte.
Eine unbekannte Verbindung ist nicht automatisch bösartig. DNS, CDN, Update-, Telemetrie-, Lizenz- und Cloud-Dienste können externe Ziele verwenden. Der Zusammenhang muss geprüft werden.
22. Listener und Portkonflikte untersuchen
Lauschende TCP-Ports:
Get-NetTCPConnection -State Listen |
Sort-Object LocalPort |
Select-Object LocalAddress,
LocalPort,
OwningProcess
Prozess zu einem Port suchen:
Get-NetTCPConnection -LocalPort <Port> |
Select-Object LocalAddress,
LocalPort,
State,
OwningProcess
Mit klassischem Windows-Befehl:
netstat -ano
Mögliche Befunde:
| Befund | Mögliche Bedeutung |
|---|---|
| erwarteter Port fehlt | Dienst läuft nicht oder bindet nicht |
Port nur an 127.0.0.1 gebunden |
nur lokaler Zugriff möglich |
| Port an unerwartete Adresse gebunden | Konfiguration prüfen |
| andere PID verwendet den Port | Portkonflikt |
viele Verbindungen in SYN_SENT |
Ziel oder Netzwerk antwortet nicht |
viele Verbindungen in TIME_WAIT |
hohe Verbindungsrate oder fehlendes Connection-Reuse |
viele Verbindungen in CLOSE_WAIT |
Anwendung schließt empfangene Verbindungen nicht korrekt |
| Listener vorhanden, Zugriff scheitert | Firewall, TLS, Anwendung oder Rückweg prüfen |
23. Autostarts mit Autoruns untersuchen
Autoruns zeigt deutlich mehr Autostartorte als der Task-Manager.
Zu den möglichen Kategorien gehören:
- Benutzeranmeldung,
- Dienste,
- Treiber,
- geplante Aufgaben,
- Explorer-Erweiterungen,
- Browserkomponenten,
- Winlogon-Komponenten,
- AppInit- und Image-Hijack-Einträge,
- Codecs,
- Office-Erweiterungen.
Empfohlene Vorgehensweise:
- Autoruns als Administrator starten.
- vollständige Erfassung abwarten.
- Microsoft-Einträge bei Bedarf ausblenden, ohne sie zu löschen.
- nach nicht vorhandenen Dateien suchen.
- Publisher und Signatur prüfen.
- Eintrag, Pfad und Kategorie dokumentieren.
- verdächtigen Eintrag zunächst deaktivieren statt löschen.
- Neustart- oder Anmeldetest kontrolliert durchführen.
- bei ausbleibender Wirkung Eintrag wieder aktivieren.
Ein nicht signierter Autostarteintrag ist nicht automatisch Schadsoftware. Herkunft, Pfad, Hash, Installationszeitpunkt und Sicherheitsmeldungen müssen gemeinsam bewertet werden.
24. Digitale Signaturen mit Sigcheck prüfen
Beispiel:
sigcheck.exe -nobanner -a -h "<Pfad-zur-Datei>"
Mögliche Prüfpunkte:
- digitale Signatur vorhanden,
- Signatur gültig,
- Herausgeber erwartet,
- Zeitstempel vorhanden,
- Dateiversion,
- Produktname,
- kryptografischer Hash,
- Pfad der Datei.
Eine gültige Signatur beweist, dass die Datei seit der Signierung nicht unbemerkt verändert wurde und zu welchem Zertifikat sie gehört. Sie beweist nicht automatisch, dass die Software erwünscht, fehlerfrei oder für den konkreten Einsatzzweck sicher ist.
Online-Prüfungen oder Uploads zu externen Diensten dürfen nur unter Beachtung von Datenschutz, Geheimhaltung und Unternehmensrichtlinien durchgeführt werden.
25. Abstürze und Hänger mit ProcDump erfassen
ProcDump kann Speicherabbilder unter bestimmten Bedingungen erzeugen, beispielsweise bei:
- Prozessabsturz,
- unbehandelter Ausnahme,
- hoher CPU-Auslastung,
- nicht reagierendem Fenster,
- bestimmten Leistungsindikatoren.
Manuelles vollständiges Speicherabbild:
procdump.exe -accepteula -ma <PID> "<Zielverzeichnis>"
Dump bei unbehandelter Ausnahme:
procdump.exe -accepteula -e -ma <Prozessname.exe> "<Zielverzeichnis>"
Dump bei nicht reagierendem Fenster:
procdump.exe -accepteula -h -ma <Prozessname.exe> "<Zielverzeichnis>"
Vor dem Einsatz muss geprüft werden:
- ausreichend freier Speicherplatz,
- geschütztes Zielverzeichnis,
- mögliche Größe des Dumps,
- Datenschutz,
- Auswirkung auf den Prozess,
- erforderliche Freigabe,
- geeignetes Analysewerkzeug,
- sichere Übermittlung an Hersteller oder Entwicklung.
Ein Dump ist noch keine Fehlerdiagnose. Er muss mit Symbolen und geeigneten Debugwerkzeugen analysiert werden.
26. Windows Performance Recorder und Analyzer
Für komplexe oder nur zeitweise auftretende Leistungsprobleme können Windows Performance Recorder und Windows Performance Analyzer eingesetzt werden.
WPR erfasst ETW-Ereignisse. WPA stellt die erfassten Daten als Tabellen und Diagramme dar.
Typische Analysebereiche:
- CPU-Nutzung,
- CPU-Nutzung nach Prozess und Thread,
- Datenträger-I/O,
- Datei-I/O,
- DPC und ISR,
- Kontextwechsel,
- Prozesslebenszyklus,
- Start- und Anmeldeleistung,
- Netzwerkaktivität,
- Arbeitsspeicherverhalten.
Grundsätzlicher Ablauf:
- geeignetes WPR-Profil auswählen.
- Speicherplatz und Aufzeichnungsmodus prüfen.
- Aufzeichnung starten.
- Problem reproduzieren.
- Aufzeichnung unmittelbar danach stoppen.
- ETL-Datei geschützt speichern.
- Datei mit WPA öffnen.
- Zeitraum des Fehlers markieren.
- Prozess, Thread und Ressource korrelieren.
- Aufzeichnung nach Abschluss kontrolliert archivieren oder löschen.
Eine ETW-Aufzeichnung kann groß werden und das System zusätzlich belasten. Profil, Dauer und Detailgrad müssen deshalb begrenzt werden.
27. Prozesse sicher beenden oder neu starten
Ein Prozess darf erst beendet werden, wenn geklärt wurde:
- welche Anwendung oder welcher Dienst betroffen ist,
- ob Daten gespeichert wurden,
- ob Transaktionen laufen,
- ob andere Dienste den Prozess verwenden,
- ob der Prozess automatisch neu startet,
- ob ein Cluster oder Watchdog zuständig ist,
- ob ein Dump benötigt wird,
- welche Benutzer betroffen sind,
- wie der Rückweg aussieht.
Kontrolliertes Beenden ohne Erzwingen:
Stop-Process -Id <PID> -WhatIf
-WhatIf zeigt nur die geplante Aktion.
Erst nach Prüfung:
Stop-Process -Id <PID>
Erzwungenes Beenden:
Stop-Process -Id <PID> -Force
-Force erhöht das Risiko von Datenverlust oder inkonsistenten Zuständen und sollte nur bei begründetem Bedarf verwendet werden.
Bei Diensten ist ein kontrollierter Dienstneustart in der Regel besser als das direkte Beenden des zugehörigen Prozesses:
Restart-Service -Name <Dienstname> -WhatIf
Danach:
Restart-Service -Name <Dienstname>
28. Befundmatrix
| Befund | Bedeutung | Nächster Test |
|---|---|---|
| Prozess beansprucht dauerhaft einen Kern | einzelner Thread möglicherweise ausgelastet | Threads und Stack in Process Explorer prüfen |
| Working Set hoch, aber stabil | möglicherweise normaler Cache | Private Bytes und zeitliche Entwicklung prüfen |
| Private Bytes wachsen dauerhaft | mögliches Speicherleck | Verlauf erfassen und Dump erstellen |
| Handle-Anzahl wächst dauerhaft | mögliches Handle-Leak | Handle-Typen und geöffnete Objekte prüfen |
| Thread-Anzahl wächst dauerhaft | mögliches Thread-Leak | Threaderzeugung und Anwendung untersuchen |
viele ACCESS DENIED unmittelbar vor Fehler |
Berechtigungsproblem möglich | Identität und effektive Rechte prüfen |
NAME NOT FOUND, danach SUCCESS |
normale Suchlogik möglich | erfolgreichen Zielpfad bestimmen |
PATH NOT FOUND ohne erfolgreichen Ersatz |
fehlender Pfad oder fehlerhafte Konfiguration | Anwendungskonfiguration prüfen |
| Datei ist gesperrt | Prozess hält Handle offen | Handle-Suche durchführen |
| Dienst beendet sich wiederholt | Anwendung, Abhängigkeit oder Dienstkonto | Ereignisse und Anwendungslog prüfen |
| Dienst bleibt bei „Wird gestartet“ | Initialisierung oder Abhängigkeit hängt | Wait Chain, Netzwerk und Logs prüfen |
| Port wird von anderer PID verwendet | Portkonflikt | Prozess und Konfiguration identifizieren |
viele Verbindungen in CLOSE_WAIT |
Anwendung schließt Verbindungen nicht | Anwendung und Verbindungspool prüfen |
| unbekannte DLL geladen | Erweiterung oder mögliche Manipulation | Pfad, Signatur, Hash und Herkunft prüfen |
| Fehler nur nach Anmeldung | Autostart oder Benutzerkonfiguration | Autoruns und Benutzerprofil prüfen |
| Fehler nur nach Update | Versions- oder Kompatibilitätsproblem | Änderungsverlauf und Herstellerhinweise |
| Prozess stürzt ohne sichtbare Meldung ab | Ausnahme oder externe Beendigung | Ereignisse, WER und ProcDump |
| Problem nur unter Dienstkonto | Berechtigung oder Benutzerumgebung | Identität, Rechte und Pfade vergleichen |
| Anwendung funktioniert nur erhöht | fehlende Berechtigung oder falscher Speicherort | Process Monitor und AccessChk |
| mehrere Prozesse gleichzeitig auffällig | gemeinsame Abhängigkeit | Storage, Netzwerk, Sicherheitssoftware |
| nach Neustart vorübergehend behoben | Zustand zurückgesetzt, Ursache unbekannt | Langzeitmessung und Dump-Trigger |
29. Typische Ursachen und passende Maßnahmen
Ursache: fehlerhafter oder blockierter Prozess
Nachweis:
- Prozess reagiert nicht,
- Wait Chain zeigt Blockierung,
- Dump oder Log bestätigt den Fehler.
Mögliche Maßnahme:
- Diagnosezustand sichern,
- Anwendung kontrolliert schließen,
- betroffenen Dienst oder Prozess neu starten,
- Herstelleranalyse durchführen.
Rollback:
- nicht anwendbar, wenn nur der Prozess neu gestartet wurde;
- gegebenenfalls auf vorherige Anwendungsversion zurückwechseln.
Verifikation:
- ursprüngliche Funktion testen,
- Ressourcen und Logs kontrollieren,
- Wiederauftreten überwachen.
Ursache: fehlende Berechtigung
Nachweis:
- Process Monitor zeigt relevanten Zugriff mit
ACCESS DENIED, - Benutzer- oder Dienstkonto besitzt das benötigte Recht nicht.
Mögliche Maßnahme:
- genau erforderliche Berechtigung nach dem Minimalprinzip ergänzen,
- Dienstkonto oder Pfadkonfiguration korrigieren.
Rollback:
- hinzugefügte Berechtigung dokumentiert entfernen.
Verifikation:
- Anwendung unter dem vorgesehenen Konto testen,
- keine unnötigen Rechte vergeben.
Ursache: fehlende Datei oder fehlerhafter Pfad
Nachweis:
- Process Monitor zeigt relevanten Zugriff mit
NAME NOT FOUNDoderPATH NOT FOUND, - kein erfolgreicher alternativer Zugriff folgt.
Mögliche Maßnahme:
- Anwendung reparieren,
- Konfigurationspfad korrigieren,
- Datei aus vertrauenswürdiger Quelle wiederherstellen.
Rollback:
- ursprüngliche Konfiguration sichern und wiederherstellen können.
Verifikation:
- Datei wird erfolgreich geöffnet,
- Anwendung funktioniert,
- keine neuen Fehler entstehen.
Ursache: fehlerhafte Erweiterung oder DLL
Nachweis:
- Problem tritt nur mit bestimmter Erweiterung auf,
- Process Explorer oder Dump verweist auf das Modul,
- Deaktivierung im Test beseitigt den Fehler.
Mögliche Maßnahme:
- Erweiterung aktualisieren,
- kompatible Version installieren,
- Erweiterung kontrolliert deaktivieren.
Rollback:
- vorherige Version oder Konfiguration wiederherstellen.
Verifikation:
- Anwendung mehrfach starten und Funktion testen.
Ursache: fehlerhafter Autostarteintrag
Nachweis:
- Problem beginnt bei Anmeldung oder Systemstart,
- Autoruns zeigt zugehörigen Eintrag,
- kontrollierte Deaktivierung beseitigt das Symptom.
Mögliche Maßnahme:
- fehlerhafte Software reparieren oder aktualisieren,
- nicht benötigten Eintrag deaktivieren.
Rollback:
- Eintrag in Autoruns wieder aktivieren.
Verifikation:
- Neustart und erneute Anmeldung testen.
Ursache: Portkonflikt
Nachweis:
- erwarteter Port gehört einer anderen PID,
- Dienstprotokoll meldet fehlgeschlagene Bindung.
Mögliche Maßnahme:
- doppelte Anwendung beenden,
- Portkonfiguration kontrolliert ändern,
- Startreihenfolge korrigieren.
Rollback:
- vorherige Portkonfiguration wiederherstellen.
Verifikation:
- Listener prüfen,
- tatsächlichen Anwendungsport testen.
Ursache: Ressourcen- oder Handle-Leak
Nachweis:
- Speicher-, Handle- oder Threadanzahl wächst über längere Zeit,
- Wachstum korreliert mit dem Symptom,
- Dump oder Herstelleranalyse bestätigt die Ursache.
Mögliche Maßnahme:
- Anwendung aktualisieren,
- Konfiguration korrigieren,
- bis zur dauerhaften Fehlerbehebung kontrolliertes Wartungsfenster planen.
Rollback:
- vorherige Anwendungsversion wiederherstellen, sofern freigegeben.
Verifikation:
- Langzeitmessung wiederholen,
- Baseline mit neuem Verlauf vergleichen.
30. Nachkontrolle
Nach einer Maßnahme sind dieselben Kriterien erneut zu prüfen:
- Prozess läuft erwartungsgemäß.
- Dienststatus ist korrekt.
- Anwendung reagiert.
- CPU-Auslastung ist plausibel.
- Arbeitsspeicher wächst nicht unkontrolliert.
- Handles und Threads bleiben stabil.
- benötigte Dateien können geöffnet werden.
- erforderliche Ports sind gebunden.
- Netzwerkverbindungen erreichen die vorgesehenen Ziele.
- keine neuen Fehler erscheinen in den Protokollen.
- Benutzerfunktion wurde praktisch getestet.
- abhängige Dienste funktionieren.
- temporäre Filter, Traces und Debugfunktionen wurden beendet.
- Dump-, PML- und ETL-Dateien wurden geschützt gespeichert oder gelöscht.
- deaktivierte Autostarts wurden abschließend bewertet.
- Monitoring zeigt wieder den Normalzustand.
31. Dokumentation
Beispiel:
Symptom:
Der Dienst „Beispieldienst“ wurde nach dem Start innerhalb
weniger Sekunden wieder beendet.
Zeitpunkt:
02.08.2026, 09:42 Uhr MESZ
Nachweis:
Das Anwendungsprotokoll zeigte den Fehler zum gleichen Zeitpunkt.
Process Monitor zeigte unmittelbar davor einen relevanten Zugriff
auf C:\ProgramData\Beispiel\config.json mit ACCESS DENIED.
Ursache:
Das verwendete Dienstkonto besaß nach einer Änderung keine
Leseberechtigung mehr für die Konfigurationsdatei.
Maßnahme:
Die erforderliche Leseberechtigung wurde ausschließlich für
das vorgesehene Dienstkonto wiederhergestellt.
Rollback:
Dokumentierte Berechtigungsänderung kann entfernt werden.
Verifikation:
Dienst startet erfolgreich.
Anwendungsport ist erreichbar.
Keine neuen Fehler im Ereignisprotokoll.
Funktionstest erfolgreich.
Prävention:
Berechtigungen des Anwendungsverzeichnisses werden künftig
vor und nach Änderungen automatisiert verglichen.
32. Entscheidungsbaum
Windows-Anwendung oder Dienst funktioniert nicht
↓
Läuft der erwartete Prozess?
├── Nein
│ ↓
│ Dienststatus, Ereignisse, Autostart,
│ Datei, Dienstkonto und Abhängigkeiten prüfen
│
└── Ja
↓
Reagiert der Prozess?
├── Nein
│ ↓
│ Wait Chain, Threads, Dump und Abhängigkeiten prüfen
│
└── Ja
↓
Sind Ressourcen auffällig?
├── Ja
│ ↓
│ CPU, RAM, Handles, Threads und I/O untersuchen
│
└── Nein
↓
Fehler bei Datei oder Registry?
├── Ja
│ ↓
│ Process Monitor, Pfade und Berechtigungen prüfen
│
└── Nein
↓
Netzwerk oder externer Dienst beteiligt?
├── Ja
│ ↓
│ TCPView, Port, DNS und Zielsystem prüfen
│
└── Nein
↓
Anwendungslog, Erweiterungen, DLLs und Dump untersuchen
33. Typische Prüfungsfragen
Warum ist ein Prozess mit hoher CPU-Auslastung nicht automatisch die Fehlerursache?
Antwort anzeigen
Die CPU-Auslastung kann für die ausgeführte Aufgabe normal sein oder als Folge eines anderen Problems entstehen. Zeitpunkt, Threadaktivität, Anwendungssymptom und weitere Abhängigkeiten müssen gemeinsam untersucht werden.
Worin unterscheiden sich Task-Manager und Process Explorer?
Antwort anzeigen
Der Task-Manager bietet eine grundlegende Übersicht über Prozesse, Leistung, Benutzer und Autostarts. Process Explorer zeigt zusätzlich unter anderem Prozesshierarchie, Befehlszeilen, Signaturen, Handles, DLLs, Threads, Sicherheitsinformationen und detaillierte Prozesseigenschaften.
Wofür wird Process Monitor verwendet?
Antwort anzeigen
Process Monitor zeichnet Datei-, Registry-, Prozess-, Thread- und DLL-Aktivitäten auf. Damit können beispielsweise fehlende Dateien, fehlerhafte Pfade und verweigerte Zugriffe untersucht werden.
Warum ist NAME NOT FOUND in Process Monitor nicht automatisch ein Fehler?
Antwort anzeigen
Anwendungen prüfen häufig mehrere mögliche Namen oder Pfade. Wenn anschließend ein alternativer Zugriff erfolgreich ist, kann der fehlgeschlagene Versuch zum normalen Programmablauf gehören.
Warum sollte ein blockierendes Handle nicht sofort geschlossen werden?
Antwort anzeigen
Das erzwungene Schließen kann Datenverlust, Programmabstürze oder inkonsistente Anwendungszustände verursachen. Zuerst muss die zugehörige Anwendung identifiziert und möglichst regulär beendet werden.
Warum kann ein vollständiges Speicherabbild sicherheitsrelevant sein?
Antwort anzeigen
Der Prozessspeicher kann Kennwörter, Tokens, Schlüssel, personenbezogene Daten und vertrauliche Anwendungsinhalte enthalten. Dumps müssen daher wie sensible Daten behandelt werden.
Warum darf ein Programm nicht dauerhaft nur als Administrator ausgeführt werden, um „Zugriff verweigert“ zu umgehen?
Antwort anzeigen
Dadurch erhält das Programm weitreichendere Rechte als erforderlich. Stattdessen muss die konkret fehlende Berechtigung identifiziert und nach dem Minimalprinzip vergeben werden.
Wofür wird Autoruns eingesetzt?
Antwort anzeigen
Autoruns zeigt zahlreiche automatische Startpunkte von Windows, beispielsweise Anmeldeeinträge, Dienste, Treiber, geplante Aufgaben und Erweiterungen. Es hilft bei Problemen, die nach dem Start oder der Anmeldung auftreten.
Was ist der Unterschied zwischen WPR und WPA?
Antwort anzeigen
Windows Performance Recorder zeichnet ETW-Ereignisse auf. Windows Performance Analyzer öffnet und analysiert die erzeugten ETL-Dateien mithilfe von Tabellen und Diagrammen.
Warum sollte vor dem Neustart eines Prozesses ein Dump erstellt werden?
Antwort anzeigen
Der Neustart beseitigt den aktuellen Prozesszustand. Ein Dump kann Informationen über Threads, Aufrufstapel, Speicher und Sperren erhalten, die für die Ursachenanalyse benötigt werden.
34. Prüfungsfallen
- hohe CPU-Auslastung sofort als Ursache bewerten.
- Prozessname mit Dienstname gleichsetzen.
- PID ohne Zeitpunkt dokumentieren.
- gesamte CPU-Zeit mit momentaner CPU-Auslastung verwechseln.
- nur den Task-Manager verwenden.
- Prozesshierarchie nicht beachten.
- unbekannten Prozess sofort als Schadsoftware einstufen.
- nicht signierte Datei automatisch als schädlich bewerten.
- digitale Signatur als vollständigen Sicherheitsnachweis ansehen.
- Process Monitor ohne Filter lange laufen lassen.
- jeden roten Process-Monitor-Eintrag als Fehler interpretieren.
-
NAME NOT FOUNDautomatisch als Ursache bewerten. - ein Handle ohne Risikoprüfung schließen.
- einen Prozess ohne Dump oder Protokollsicherung beenden.
- Dienstprozess direkt beenden, obwohl ein kontrollierter Dienstneustart möglich ist.
- Anwendung dauerhaft als Administrator starten.
- Autostarteintrag sofort löschen statt kontrolliert deaktivieren.
- Dump-Dateien ungeschützt speichern.
- unbekannte interne Dateien ungeprüft zu einem externen Dienst hochladen.
- Port prüfen, aber zugehörige PID nicht ermitteln.
- Listener mit tatsächlicher Anwendungsfunktion verwechseln.
- Prozess untersuchen, aber externe Abhängigkeiten übersehen.
- mehrere Änderungen gleichzeitig durchführen.
- nach einer Maßnahme keine Vergleichsmessung durchführen.
- temporäre Traces oder Debugfunktionen aktiv lassen.
35. Checkliste
- exakte Fehlermeldung wurde dokumentiert.
- Fehlerzeitpunkt und Zeitzone wurden erfasst.
- betroffene Anwendung wurde bestimmt.
- Prozessname und PID wurden bestimmt.
- Prozessstartzeit wurde berücksichtigt.
- Eltern- und Kindprozesse wurden geprüft.
- Benutzer- oder Dienstkonto wurde bestimmt.
- Prozess- und Dienststatus wurden geprüft.
- Dienstabhängigkeiten wurden geprüft.
- CPU-Auslastung wurde geprüft.
- einzelne Threads wurden berücksichtigt.
- Arbeitsspeicher wurde geprüft.
- Private Bytes und Working Set wurden unterschieden.
- Handle-Anzahl wurde geprüft.
- Thread-Anzahl wurde geprüft.
- Datenträgeraktivität wurde geprüft.
- Ereignisanzeige wurde zeitlich gefiltert.
- Anwendungsprotokoll wurde geprüft.
- Systemprotokoll wurde geprüft.
- vollständiger Ereignistext wurde gelesen.
- Prozesspfad wurde geprüft.
- Befehlszeile wurde geprüft.
- digitale Signatur wurde geprüft.
- geladene DLLs wurden bei Bedarf geprüft.
- offene Handles wurden bei Bedarf geprüft.
- Process Monitor wurde gefiltert eingesetzt.
- fehlgeschlagene Zugriffe wurden technisch bewertet.
- Benutzer- und Dienstberechtigungen wurden geprüft.
- Netzwerkverbindungen wurden der PID zugeordnet.
- Listener und Portkonflikte wurden geprüft.
- Autostarts wurden bei passendem Fehlerbild geprüft.
- letzte Änderungen wurden berücksichtigt.
- funktionierendes Vergleichssystem wurde genutzt.
- vor einem Neustart wurden flüchtige Daten gesichert.
- Dump-Erstellung wurde bei Absturz oder Hänger geprüft.
- Schutzbedarf von Dump-, PML- und ETL-Dateien wurde beachtet.
- genau eine kontrollierte Maßnahme wurde durchgeführt.
- Rückweg wurde festgelegt.
- Benutzerfunktion wurde nach der Maßnahme getestet.
- Prozesse, Dienste und Protokolle wurden erneut geprüft.
- temporäre Diagnosefunktionen wurden beendet.
- Ursache, Maßnahme und Ergebnis wurden dokumentiert.
- vorbeugende Maßnahme wurde festgelegt.
36. Schnellreferenz
| Beobachtung | Nächstes Werkzeug |
|---|---|
| Prozess verbraucht viel CPU | Process Explorer, Leistungsüberwachung |
| nur ein Kern ausgelastet | Process Explorer → Threads |
| Arbeitsspeicher wächst | PowerShell, Process Explorer, ProcDump |
| Handles wachsen | Process Explorer, Handle |
| Datei ist gesperrt | Process Explorer oder Handle |
| DLL-Konflikt vermutet | Process Explorer oder ListDLLs |
| Zugriff verweigert | Process Monitor, AccessChk |
| Datei oder Pfad fehlt | Process Monitor |
| Dienst startet nicht | Ereignisanzeige, sc.exe, PowerShell |
| Dienst hängt beim Start | Ereignisanzeige, Wait Chain, ProcDump |
| Prozess reagiert nicht | Ressourcenmonitor, Process Explorer, ProcDump |
| Anwendung stürzt ab | Ereignisanzeige, WER, ProcDump |
| unbekannte Netzwerkverbindung | TCPView |
| erwarteter Port fehlt | Get-NetTCPConnection, TCPView |
| Port ist bereits belegt | Get-NetTCPConnection, netstat -ano |
| Fehler nach Anmeldung | Autoruns |
| langsamer Systemstart | Autoruns, WPR und WPA |
| unbekannte Datei | Sigcheck |
| zeitweises Leistungsproblem | WPR und WPA |
| Problem nur unter Dienstkonto | whoami, AccessChk, Process Monitor |
| Anwendung funktioniert nur erhöht | Process Monitor und Berechtigungsprüfung |
Merksatz
Windows-Prozesse und Dienste werden nicht allein anhand ihres Namens oder eines einzelnen Messwerts bewertet. Entscheidend sind Prozesshierarchie, Benutzerkonto, Threads, Speicher, Handles, Dateien, Registry-Zugriffe, Netzwerkverbindungen, Ereignisse und externe Abhängigkeiten. Vor dem Beenden oder Neustarten wird der flüchtige Zustand gesichert. Anschließend wird genau eine kontrollierte Maßnahme durchgeführt und ihre Wirkung erneut geprüft.
Quellen und weiterführende Dokumentation
Offizielle Microsoft-Dokumentation
- Microsoft Learn – Sysinternals
- Microsoft Learn – Sysinternals Utilities
- Microsoft Learn – Sysinternals Suite
- Microsoft Learn – Process Explorer
- Microsoft Learn – Process Monitor
- Microsoft Learn – Autoruns
- Microsoft Learn – TCPView
- Microsoft Learn – Handle
- Microsoft Learn – ListDLLs
- Microsoft Learn – AccessChk
- Microsoft Learn – Sigcheck
- Microsoft Learn – ProcDump
- Microsoft Learn – Get-Process
- Microsoft Learn – Get-Service
- Microsoft Learn – Get-WinEvent
- Microsoft Learn – Get-NetTCPConnection
- Microsoft Learn – Stop-Process
- Microsoft Learn – Restart-Service
- Microsoft Learn – Windows Performance Recorder
- Microsoft Learn – Windows Performance Analyzer
- Microsoft Learn – Prozesse und Threads mit WPR und WPA untersuchen