Skip to main content

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

  1. Exakte Fehlermeldung und Uhrzeit dokumentieren.
  2. Prozess- und Dienststatus prüfen.
  3. CPU, Arbeitsspeicher, Handles und Threads vergleichen.
  4. System- und Anwendungsereignisse zum Fehlerzeitpunkt untersuchen.
  5. Mit Process Explorer Prozessbaum und Eigenschaften prüfen.
  6. Mit Process Monitor nur den betroffenen Prozess aufzeichnen.
  7. Netzwerkverbindungen mit TCPView oder PowerShell prüfen.
  8. 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:

  1. Process Explorer als Administrator starten, wenn erhöhte Prozesse untersucht werden müssen.
  2. View → Show Process Tree verwenden.
  3. Unter View → Select Columns benötigte Spalten aktivieren.
  4. Betroffenen Prozess markieren.
  5. Eigenschaften des Prozesses öffnen.
  6. Image, Performance, Threads, TCP/IP und Security prüfen.
  7. Prozesspfad und digitale Signatur kontrollieren.
  8. Eltern- und Kindprozesse dokumentieren.
  9. Auffällige Threads oder Handles untersuchen.
  10. 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:

  1. Prozess öffnen.
  2. Registerkarte Threads auswählen.
  3. Threads nach CPU-Auslastung sortieren.
  4. Thread-ID und Startadresse dokumentieren.
  5. bei verfügbaren Symbolen den Stack untersuchen.
  6. 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:

  1. Find → Find Handle or DLL öffnen.
  2. Teil des Datei- oder Verzeichnisnamens eingeben.
  3. gefundenen Prozess und Handle-Typ prüfen.
  4. Anwendung möglichst regulär schließen.
  5. 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:

  1. Process Monitor starten.
  2. Aufzeichnung zunächst anhalten.
  3. vorhandene Ereignisse leeren.
  4. Filter für den betroffenen Prozess setzen.
  5. nur benötigte Ereignisklassen aktivieren.
  6. Aufzeichnung starten.
  7. Fehler genau einmal reproduzieren.
  8. Aufzeichnung sofort anhalten.
  9. Ereignisse rund um den Fehlerzeitpunkt untersuchen.
  10. 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:

  1. Autoruns als Administrator starten.
  2. vollständige Erfassung abwarten.
  3. Microsoft-Einträge bei Bedarf ausblenden, ohne sie zu löschen.
  4. nach nicht vorhandenen Dateien suchen.
  5. Publisher und Signatur prüfen.
  6. Eintrag, Pfad und Kategorie dokumentieren.
  7. verdächtigen Eintrag zunächst deaktivieren statt löschen.
  8. Neustart- oder Anmeldetest kontrolliert durchführen.
  9. 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:

  1. geeignetes WPR-Profil auswählen.
  2. Speicherplatz und Aufzeichnungsmodus prüfen.
  3. Aufzeichnung starten.
  4. Problem reproduzieren.
  5. Aufzeichnung unmittelbar danach stoppen.
  6. ETL-Datei geschützt speichern.
  7. Datei mit WPA öffnen.
  8. Zeitraum des Fehlers markieren.
  9. Prozess, Thread und Ressource korrelieren.
  10. 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 FOUND oder PATH 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 FOUND automatisch 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