Process Monitor Anleitung: Windows-Fehler finden

Diese Process Monitor Anleitung zeigt Dir, welche Datei- und Registry-Zugriffe hinter einem Windows-Fehler stecken können. Zum Beispiel wenn ein Programm nicht startet, eine Einstellung verschwindet oder beim Speichern „Zugriff verweigert“ erscheint! Mit einer kurzen Aufzeichnung vom Prozess Monitor kannst Du Dir anschauen, was unmittelbar passiert und dies erleichtert die Fehlersuche immens.

Der Ablauf ist recht einfach: Du zeichnest den problematischen Vorgang auf, filterst nach dem betroffenen Prozess und untersuchst die passenden Ereignisse. Entscheidend ist dabei der Zusammenhang. Ein auffälliger Eintrag allein beweist noch nicht, dass Du die Ursache gefunden hast.

Was ist Process Monitor und wofür eignet sich das Programm?

Process Monitor, häufig Procmon genannt, ist ein kostenloses Diagnosewerkzeug von Microsoft Sysinternals. Es protokolliert unter Windows einzelne Dateisystemzugriffe, Registry-Vorgänge sowie Prozess- und Threadaktivitäten. Ein Thread ist ein Ausführungsstrang innerhalb eines Prozesses. Die Aufzeichnung zeigt unter anderem Zeitpunkt, ausführenden Prozess, betroffene Ressource und Ergebnis einer Operation.

Dadurch kannst Du beispielsweise feststellen, welche Konfigurationsdatei eine Anwendung sucht, welcher Prozess einen Registry-Wert schreibt oder an welchem Pfad ein Zugriff scheitert. Process Monitor beobachtet diese Vorgänge. Die passende Reparatur leitest Du anschließend aus der Auswertung ab.

Auch TCP- und UDP-Aktivitäten lassen sich Prozessen zuordnen. Dabei siehst Du Verbindungsdaten und übertragene Datenmengen, aber nicht die übertragenen Nutzdaten. Neuere Ausgaben erfassen außerdem bestimmte Vorgänge der Kommunikation zwischen Prozessen. Was dabei Named Pipes und Mailslots bedeuten, erklärt unser Beitrag zur IPC-Analyse mit Process Monitor.

Process Monitor, Process Explorer und Ereignisanzeige unterscheiden

Werkzeug	Passende Frage
Task-Manager	Welche Anwendung läuft und belastet gerade CPU, Arbeitsspeicher oder Datenträger?
Process Explorer	Welche Prozesse gehören zusammen und welcher Prozess hält eine Datei geöffnet?
Process Monitor	Welche einzelnen Zugriffe finden während des untersuchten Vorgangs statt?
Ereignisanzeige	Welche Meldungen haben Windows, Dienste oder Anwendungen in ihre Ereignisprotokolle geschrieben?

Für die Untersuchung laufender Programme ergänzt unsere Process Explorer Anleitung die Arbeit mit Procmon. Bei einem Absturz lohnt sich zusätzlich die Windows Ereignisanzeige. Ein Procmon-Mitschnitt und ein Windows-Ereignisprotokoll enthalten unterschiedliche Informationen und können sich bei der Diagnose ergänzen.

Process Monitor herunterladen und die Aufzeichnung vorbereiten

Du kannst den Process Monitor herunterladen und das Paket in einen eigenen Ordner entpacken. Ein klassischer Installationsassistent ist nicht erforderlich. Falls Du dabei Unterstützung brauchst, hilft die Anleitung zum Entpacken einer ZIP-Datei unter Windows.

Der Inhalt der Datei „ProcessMonitor.zip“ sieht dann wie folgt aus:

Die aktuelle Ausgabe setzt auf Desktop-PCs Windows 11 oder neuer voraus. Für Server gilt Windows Server 2019 oder neuer. Auf einem üblichen Windows-PC mit x64-Prozessor verwendest Du Procmon64.exe, auf einem passenden ARM64-Gerät Procmon64a.exe. Für die Aufzeichnung wird Process Monitor mit Administratorrechten gestartet.

Das untersuchte Programm sollte dagegen zunächst unter den Bedingungen laufen, unter denen sein Fehler tatsächlich auftritt. Wenn Du eine normalerweise ohne erhöhte Rechte gestartete Anwendung plötzlich als Administrator ausführst, kann ein Berechtigungsproblem vorübergehend verschwinden. Die Aufzeichnung würde dann einen anderen Ablauf zeigen.

Vor dem Mitschnitt helfen drei kurze Notizen: Welche Aktion löst den Fehler aus, wie lautet die Meldung und wann tritt sie auf? Ein klarer Testfall wie „Datei öffnen, Änderung speichern, Fehlermeldung abwarten“ lässt sich später wesentlich besser auswerten als eine lange Aufzeichnung ohne konkreten Auslöser.

Process Monitor Anleitung: Die erste Aufzeichnung in sieben Schritten

1. Process Monitor starten und die laufende Aufnahme anhalten

Über das Kontextmenü der passenden Programmdatei kannst Du Als Administrator ausführen auswählen. Beim ersten Start erscheinen die Lizenzbedingungen. Danach beginnt Process Monitor normalerweise sofort mit der Erfassung, sodass sich das Fenster schnell mit Einträgen füllt.

Mit Strg + E hältst Du die Aufnahme an. Dieselbe Tastenkombination startet sie später wieder. Der entsprechende Menüpunkt heißt File > Capture Events. Das Anhalten gibt Dir Zeit, die Einstellungen in Ruhe vorzubereiten.

2. Alte Filter zurücksetzen und einen sauberen Ausgangspunkt schaffen

Unter Filter > Reset Filter kannst Du zuvor gesetzte Filter zurücksetzen. Achte darauf, dass Filter > Drop Filtered Events für diese erste Diagnose nicht aktiviert ist. Dann bleiben ausgeblendete Ereignisse grundsätzlich für eine spätere Auswertung erhalten.

Die Schaltflächen in der Symbolleiste steuern unter anderem die Anzeige von Dateisystem-, Registry-, Netzwerk- und Prozessereignissen. Für einen Programmstart sollten insbesondere Dateisystem, Registry und Prozessaktivitäten sichtbar sein. Mit Strg + X leerst Du anschließend die bisherige Aufzeichnung. Falls darin bereits wichtige Daten stehen, sicherst Du sie vorher.

3. Den Fehler während einer kurzen Aufnahme auslösen

Nun kannst Du die Aufnahme mit Strg + E einschalten und unmittelbar danach Deinen vorbereiteten Testfall durchführen. Bei einem Startproblem gehört der vollständige Programmstart in die Aufzeichnung. Bei einem Fehler beim Speichern einer Datei genügt häufig die kurze Phase rund um den betroffenen Speichervorgang.

Währenddessen bleiben zusätzliche Aktionen möglichst aus. Ein parallel gestarteter Browser oder ein Installationsprogramm erzeugt weitere Ereignisse und erschwert die Zuordnung. Sobald die Fehlermeldung sichtbar ist, hältst Du den Mitschnitt erneut mit Strg + E an.

4. Den vollständigen Mitschnitt als PML-Datei sichern

Unter File > Save wählst Du All events und Native Process Monitor Format (PML). Ein eindeutiger Name wie BeispielApp-Speicherfehler-01.pml erleichtert spätere Vergleiche. Damit hast Du eine unveränderte Ausgangsaufzeichnung, bevor Du tiefer in die Analyse einsteigst.

All events umfasst die noch vorhandenen erfassten Ereignisse. Bereits während der Aufnahme verworfene Daten kann diese Auswahl nicht wiederherstellen. Die Unterschiede zwischen vollständiger Sicherung und gefiltertem Export werden weiter unten erläutert.

5. Den betroffenen Prozess auswählen

Unter Tools > Process Tree findest Du den Prozessbaum der Aufzeichnung. Er hilft auch dann, wenn eine Anwendung nur kurz gestartet ist und bereits wieder beendet wurde. Über Add process to Include filter im Kontextmenü des passenden Eintrags kannst Du die Anzeige auf diese Prozessinstanz eingrenzen.

Alternativ lässt sich ein Filter auf den Prozessnamen setzen. Den genauen Namen und die Prozess-ID, kurz PID, findest Du bei laufenden Programmen auch im Task-Manager unter Details. Eine PID kennzeichnet eine konkrete Prozessinstanz. Nach einem Neustart des Programms kann eine andere PID gelten.

6. Auffällige Ereignisse rund um den Fehler untersuchen

Ausgangspunkt ist der Zeitpunkt Deiner Fehlermeldung. Von dort gehst Du die vorausgehenden Zugriffe durch und achtest auf passende Dateipfade, Registry-Einträge und Ergebnisse. Ein Doppelklick auf eine Zeile öffnet die Ereigniseigenschaften.

Die Registerkarte Event enthält Details zur Operation. Unter Process findest Du unter anderem Programmpfad, Befehlszeile und ausführendes Konto. Stack zeigt die beteiligte Aufrufkette und ist vor allem für eine tiefere Analyse hilfreich. Für den Einstieg reichen meist Event und Process.

7. Eine begründete Änderung mit einer zweiten Aufnahme überprüfen

Aus einer Vermutung wird erst durch einen passenden Vergleich ein belastbarer Befund. Wenn beispielsweise ein falscher Speicherpfad erkennbar ist, korrigierst Du die betreffende Programmeinstellung und wiederholst denselben Testfall. Dabei bleibt möglichst alles andere unverändert.

Die zweite Aufnahme speicherst Du unter einem neuen Namen. Anschließend vergleichst Du, ob der zuvor fehlgeschlagene Zugriff nun gelingt und ob auch das sichtbare Problem verschwunden ist. Ein zusätzliches SUCCESS in der Liste allein genügt dafür nicht.

Process Monitor verstehen: Die wichtigsten Spalten und Operationen

Eine Zeile beschreibt eine einzelne aufgezeichnete Operation. Sie ist weder eine vollständige Handlung des Anwenders noch zwangsläufig eine Fehlermeldung. Ein einfacher Klick auf Speichern kann zahlreiche Datei-, Registry- und Prozessereignisse auslösen.

Spalte	Bedeutung für die Auswertung
Time of Day	Zeitpunkt des Ereignisses. Hilft bei der Zuordnung zu Deiner beobachteten Störung.
Process Name	Name des ausführenden Prozesses.
PID	Prozess-ID zur Unterscheidung gleichnamiger Prozessinstanzen.
Operation	Art des Vorgangs, etwa ReadFile oder RegQueryValue.
Path	Betroffene Ressource, beispielsweise eine Datei oder ein Registry-Pfad.
Result	Ergebnis genau dieser Operation.
Detail	Zusatzinformationen, beispielsweise angeforderte Zugriffsrechte, Datenlänge oder Registry-Wertdaten.
Duration	Dauer einer abgeschlossenen Operation, sofern für die Auswertung relevant.

Bei den Operationsnamen lohnt sich genaues Hinsehen: CreateFile kann auch das Öffnen einer vorhandenen Datei oder eines Verzeichnisses bedeuten. Ob etwas geöffnet oder neu angelegt werden sollte, ergibt sich aus Details wie Disposition. ReadFile steht für einen Lesezugriff, WriteFile für einen Schreibzugriff.

In der Registry bezeichnet RegQueryValue das Abfragen eines Wertes, RegSetValue das Setzen seiner Daten. Auch RegCreateKey ist kein sicherer Beleg für einen neu angelegten Schlüssel, weil dabei ein vorhandener Schlüssel geöffnet werden kann. Der Operationsname allein ersetzt deshalb nicht den Blick auf Ergebnis und Details.

Process Monitor Filter richtig setzen

Mit Strg + L beziehungsweise Filter > Filter öffnest Du den Filterdialog. Eine Regel besteht aus einem Feld, einer Bedingung, einem Vergleichswert und der Aktion Include oder Exclude. Include nimmt passende Ereignisse in die Ansicht auf, Exclude blendet passende Ereignisse aus.

Für einen Prozessfilter wählst Du Process Name, danach is, den tatsächlichen Dateinamen und Include. Über Add wird die Regel hinzugefügt; mit OK übernimmst Du die Auswahl. Der Name BeispielApp.exe in den folgenden Beispielen ist ein Platzhalter und wird durch den Prozessnamen Deiner Anwendung ersetzt.

Ziel	Beispielregel
Eine Anwendung untersuchen	Process Name | is | BeispielApp.exe | Include
Eine konkrete Prozessinstanz auswählen	PID | is | tatsächlich ermittelte PID | Include
Zugriffe auf Inhalte eines Ordners finden	Path | begins with | C:\ProgramData\BeispielApp\ | Include
Einen bestimmten Dateinamen suchen	Path | ends with | \settings.json | Include
Verweigerte Zugriffe anzeigen	Result | is | ACCESS DENIED | Include
Schreibzugriffe auf Registry-Werte finden	Operation | is | RegSetValue | Include

Warum mehrere Include-Filter manchmal unerwartete Treffer liefern

Include-Regeln für dasselbe Feld werden als Alternativen behandelt. Zwei Regeln für Process Name zeigen deshalb Ereignisse von Anwendung A oder Anwendung B. Include-Regeln für unterschiedliche Felder müssen dagegen gemeinsam passen.

Ein konkretes Beispiel: Process Name is BeispielApp.exe und Result is ACCESS DENIED zeigen verweigerte Zugriffe dieser Anwendung. Ergänzt Du einen zweiten Prozessnamen, werden verweigerte Zugriffe beider Anwendungen sichtbar. Ergänzt Du zusätzlich einen Path-Filter, muss außerdem der angegebene Pfad passen. Passende Exclude-Regeln können Ereignisse weiterhin ausblenden.

Diese Logik erklärt auch eine häufige Falle: Ein Filter auf den Hauptprozess nimmt seine anders benannten Hilfsprozesse nicht automatisch mit auf. Bei Installationen, Browsern oder Anwendungen mit Hintergrunddiensten lohnt sich deshalb der Prozessbaum. Die tatsächlich beteiligten Prozesse müssen in der Auswahl berücksichtigt werden.

Anzeigefilter und Drop Filtered Events auseinanderhalten

Normale Filter verändern zunächst die Ansicht. Du kannst sie nach der Aufnahme lockern und zuvor ausgeblendete Ereignisse wieder betrachten. Auch die Schaltflächen für Ereigniskategorien sind Anzeigefilter. Eine kürzere sichtbare Liste bedeutet deshalb nicht automatisch einen kleineren Mitschnitt.

Mit Drop Filtered Events werden herausgefilterte Ereignisse dagegen schon während der Erfassung verworfen. Das kann bei einer gut vorbereiteten Spezialdiagnose die Datenmenge reduzieren, erschwert aber eine spätere Erweiterung der Untersuchung. Für den ersten Durchlauf bleibt die Option deshalb besser ausgeschaltet.

NAME NOT FOUND und ACCESS DENIED richtig interpretieren

Die Spalte Result beschreibt den Ausgang einer einzelnen Operation. Programme testen häufig mehrere Speicherorte oder fragen optionale Einstellungen ab. Dabei entstehen auch in einem funktionierenden System zahlreiche Einträge, die zunächst wie Fehler aussehen.

Ergebnis	Bedeutung	Sinnvolle Einordnung
SUCCESS	Die betreffende Operation war erfolgreich.	Das sagt noch nichts über den Erfolg des gesamten Programmablaufs aus.
NAME NOT FOUND	Der angefragte Name wurde nicht gefunden.	Eine optionale Datei oder Einstellung kann fehlen, ohne die Anwendung zu beeinträchtigen.
PATH NOT FOUND	Der angefragte Pfad konnte nicht aufgelöst werden.	Verzeichnisstruktur, Laufwerk und verwendeten Speicherort nachvollziehen.
ACCESS DENIED	Der angeforderte Zugriff wurde verweigert.	Konto, angeforderte Rechte und nachfolgende Ausweichversuche berücksichtigen.
SHARING VIOLATION	Der Zugriff ist mit einer bestehenden Öffnung beziehungsweise deren Freigabemodus unvereinbar.	Untersuchen, welche Anwendung die Datei geöffnet hält.
BUFFER OVERFLOW	Der bereitgestellte Puffer reicht für die angefragten Informationen nicht aus.	Kann Teil einer normalen Größenabfrage mit anschließendem größeren Puffer sein.
NO MORE FILES	Eine Dateiaufzählung hat ihr Ende erreicht.	Allein kein Hinweis auf einen defekten Datenträger.
REPARSE	Die Pfadauflösung wird weitergeführt beziehungsweise umgeleitet.	Kann bei Verknüpfungen im Dateisystem normal sein.

Die wichtigste Frage lautet deshalb: Scheitert genau die Ressource, die für Deine Aktion benötigt wird, und fehlt danach ein erfolgreicher Ersatzweg? Ein Treffer gewinnt an Aussagekraft, wenn er unmittelbar zum beobachteten Problem passt und sich beim Wiederholen erneut zeigt. Ein Result-Filter dient zum Auffinden verdächtiger Stellen; für deren Bewertung blendest Du die umliegenden Ereignisse wieder ein.

Praxisbeispiel 1: Ein Programm sucht eine fehlende Datei

Angenommen, eine Anwendung meldet beim Start eine fehlende Konfiguration. Du filterst ihre Ereignisse nach dem genannten Dateinamen und vergleichst die vollständigen Pfade. Der folgende vereinfachte Beispielablauf ist noch kein Beleg für einen Defekt:

CreateFile  C:\ProgramData\BeispielApp\settings.json  NAME NOT FOUND
CreateFile  C:\Users\Anna\AppData\Roaming\BeispielApp\settings.json  SUCCESS
ReadFile    C:\Users\Anna\AppData\Roaming\BeispielApp\settings.json  SUCCESS

Hier wird die Datei zunächst an einem allgemeinen Speicherort gesucht und anschließend im Benutzerprofil gefunden. Der erste erfolglose Versuch kann zum vorgesehenen Suchablauf gehören. Wenn die Anwendung danach trotzdem scheitert, untersuchst Du die weiteren Ereignisse statt vorschnell eine neue Datei am ersten Pfad anzulegen.

Fehlt dagegen auch am erwarteten Speicherort eine benötigte Datei, kommen beispielsweise ein falscher Konfigurationspfad oder eine unvollständige Programminstallation infrage. Informationen zu benutzerspezifischen Ablagen findest Du im Beitrag zum AppData-Ordner und seiner Funktion. Pfadangaben wie %APPDATA% werden je nach ausführendem Konto aufgelöst; dabei hilft das Verständnis der Windows-Umgebungsvariablen.

Bei einer fehlenden Programmbibliothek ist eine Reparatur der zugehörigen Anwendung meist der nachvollziehbarere nächste Schritt. Einzelne DLL-Dateien aus beliebigen Downloads ersetzen keine saubere Diagnose und können zusätzliche Probleme verursachen.

Praxisbeispiel 2: Zugriff verweigert beim Speichern oder Dienststart

Bei einem Speicherfehler ergänzt Du den Prozessfilter vorübergehend um Result is ACCESS DENIED. In den Eigenschaften eines passenden Ereignisses ist interessant, auf welchen Pfad zugegriffen wurde und welche Rechte unter Desired Access angefordert wurden. Ein verweigerter Schreibzugriff ist anders zu bewerten als ein erfolgloser Versuch, besonders weitreichende Rechte anzufordern.

Danach überprüfst Du das ausführende Konto und die vorgesehenen Berechtigungen des betroffenen Ordners. Dienste können unter einem anderen Konto laufen als der angemeldete Anwender. Falls beim Ereignis eine abweichende Identität unter Impersonating erscheint, gehört auch diese in die Prüfung.

Die passende Lösung hängt vom Befund ab: Vielleicht ist ein beschreibbarer Datenordner einzustellen, vielleicht fehlt einem Dienstkonto eine konkret erforderliche Berechtigung. Ein pauschaler Vollzugriff für Jeder oder ein dauerhaft erhöhter Programmstart wäre daraus nicht automatisch abzuleiten. Weitere typische Ursachen behandelt die Anleitung zum Windows-Fehler 0x80070005 und verweigerten Zugriffen.

Wenn Du einen Dienststart nachvollziehen möchtest, sollte die Aufnahme bereits vor dem Startversuch laufen. Unsere Anleitung zum Starten und Stoppen von Windows-Diensten erläutert die Bedienung. Die zeitlich passenden Dienstmeldungen kannst Du ergänzend über die Ereignisanzeige mit PowerShell auslesen.

Praxisbeispiel 3: Herausfinden, wo ein Programm seine Einstellungen speichert

Du möchtest wissen, welcher Registry-Wert beim Ändern einer Programmeinstellung geschrieben wird? Dafür eignet sich ein kurzer kontrollierter Vergleich. Besonders übersichtlich wird er, wenn Du nur eine leicht rückgängig zu machende Option innerhalb der Anwendung änderst.

1. Du stellst zunächst einen Filter auf den betreffenden Prozess ein.
2. Zusätzlich lässt Du über Operation is RegSetValue die Schreibzugriffe auf Registry-Werte anzeigen.
3. Während der Aufnahme änderst Du genau eine Programmeinstellung und bestätigst sie.
4. Falls die Anwendung Einstellungen erst beim regulären Beenden speichert, bleibt auch dieser Vorgang Teil des Mitschnitts.
5. Nach dem Anhalten vergleichst Du die passenden Pfade und die unter Detail protokollierten Wertdaten.

Ein erfolgreicher RegSetValue-Vorgang zeigt, dass Wertdaten geschrieben wurden. Er liefert aber nicht automatisch den vorherigen Inhalt. Für einen echten Vorher-nachher-Vergleich braucht es einen dokumentierten Ausgangszustand und einen zweiten Durchlauf mit der zurückgestellten Programmeinstellung.

Erscheint kein passender Registry-Zugriff, kann die Anwendung ihre Konfiguration beispielsweise in einer Datei speichern. Dann entfernst Du den Operationsfilter und untersuchst die Schreibzugriffe auf Dateien. Falls ein Verhalten ausschließlich bei einem Konto auftritt, hilft ergänzend die systematische Eingrenzung eines Problems mit dem Windows-Benutzerprofil.

Praxisbeispiel 4: Viele Dateizugriffe und langsame Programme untersuchen

Bei einem langsamen Rechner ist zunächst interessant, welcher Prozess und welcher Datenträger auffallen. Dafür eignet sich der Ressourcenmonitor unter Windows 11. Anschließend kannst Du mit Process Monitor untersuchen, welche Dateien die betroffene Anwendung während der Verzögerung anspricht.

Hilfreich sind wiederholte Zugriffe auf denselben Pfad, ständig neue Suchversuche oder auffällig lange einzelne Operationen. Die Spalte Duration lässt sich bei Bedarf über Options > Select Columns einblenden. Sie beschreibt die Dauer einer Operation und darf nicht einfach mit der gesamten Wartezeit des Anwenders gleichgesetzt werden.

Viele Ereignisse bedeuten außerdem nicht automatisch einen Fehler. Ein Suchlauf oder ein Programmstart kann zahlreiche normale Zugriffe erzeugen. Auch ein Dateizugriff im Protokoll beweist nicht, dass die entsprechenden Daten jedes Mal unmittelbar vom physischen Datenträger gelesen wurden. Für eine Leistungsdiagnose gehören Ablauf, Dauer und die tatsächlich beobachtete Belastung zusammen.

PML-Dateien öffnen, gefiltert exportieren und Speicherverbrauch begrenzen

Eine gespeicherte PML-Datei öffnest Du über File > Open wieder in Process Monitor. Das native Format erhält die erfassten Detailinformationen für die weitere Analyse. Ein CSV-Export eignet sich dagegen für eine tabellarische Auswertung, ersetzt aber keine vollständige PML-Aufzeichnung.

Beim Speichern entscheidet zusätzlich die Ereignisauswahl über den Inhalt. All events sichert den vorhandenen Gesamtbestand. Events displayed using current filter enthält nur die Ereignisse der aktuellen Ansicht. Für eine schmale Auswertungskopie kann das sinnvoll sein; die vollständige Ausgangsdatei sollte dabei erhalten bleiben.

Für längere Aufnahmen kannst Du unter File > Backing Files die Option Use file named verwenden und einen Dateipfad vorgeben. Process Monitor schreibt dann während der Erfassung in eine Datei. Das reduziert die Abhängigkeit vom virtuellen Speicher, begrenzt aber nicht automatisch den belegten Platz auf dem Laufwerk.

Praxistipp: Die Dauer richtet sich nach dem Fehler, nicht nach einer festen Zielgröße. Für einen reproduzierbaren Speichervorgang ist ein kurzer Mitschnitt oft hilfreicher als eine stundenlange Aufnahme. Protokolle können Kontonamen, Dateipfade, Befehlszeilen und vertrauliche Wertdaten enthalten. Vor einer Weitergabe gehört deshalb auch der Inhalt der Datei zur Prüfung.

Process Monitor Boot Logging: Fehler beim Windows-Start aufzeichnen

Wenn eine Störung bereits beim Start oder bei der Anmeldung entsteht, kommt eine normale Aufnahme manchmal zu spät. Mit Boot Logging kann Process Monitor früh im Windows-Startvorgang protokollieren. Für den Einstieg eignet sich vor allem ein Problem, nach dem Du Windows noch bedienen und die Aufzeichnung sichern kannst.

1. Du startest Process Monitor mit Administratorrechten.
2. Unter Options > Enable Boot Logging aktivierst Du die Startaufzeichnung.
3. Nach einem regulären Neustart lässt Du den problematischen Start- oder Anmeldevorgang ablaufen.
4. Anschließend startest Du Process Monitor erneut. Dabei wird die Startaufzeichnung beendet und ihre Speicherung angeboten.
5. Du sicherst die Aufzeichnung und verwendest für die weitere Speicherung All events sowie das PML-Format.

Die Auswertung erfolgt anschließend nach denselben Grundsätzen wie bei einer normalen Aufnahme. Ein zeitnaher Abschluss hält die Datenmenge überschaubar. Wenn Du zusätzlich wissen möchtest, welcher Eintrag ein Programm automatisch startet, ergänzt die Autostart-Analyse mit Autoruns den aufgezeichneten Ablauf um die konfigurierten Startpunkte.

Process Monitor zeigt nichts an oder liefert zu viele Ereignisse

Eine leere Ansicht hat häufig eine einfache Erklärung. Vielleicht läuft die Erfassung nicht, der Vorgang fand bereits vor dem Aufnahmebeginn statt oder eine alte PID passt nicht mehr zur neu gestarteten Anwendung. Auch eine ausgeblendete Ereigniskategorie oder eine zusätzliche Exclude-Regel kann relevante Zeilen verbergen.

Du kannst die Aufnahme zunächst anhalten, die Filter zurücksetzen und die benötigten Kategorien wieder einblenden. Sind die Ereignisse dann sichtbar, wird die Eingrenzung schrittweise neu aufgebaut. Fehlen sie weiterhin, ist entscheidend, ob sie überhaupt erfasst wurden oder durch Drop Filtered Events bereits verloren gegangen sind.

Bei einer zu langen Liste hilft die umgekehrte Reihenfolge: erst den Zeitraum, dann den Prozess und anschließend den betroffenen Pfad eingrenzen. Wenn der zuständige Prozess unbekannt ist, kann ein Filter auf den konkreten Dateipfad alle zugreifenden Prozesse sichtbar machen. Ein zu früh gesetzter Prozessfilter würde gerade den gesuchten Verursacher möglicherweise ausblenden.

Bei Netzwerkfragen ist außerdem die Grenze des Werkzeugs zu beachten. Procmon kann eine Aktivität einem Prozess zuordnen, beantwortet aber nicht jede Frage zu Paketinhalt oder Protokollablauf. Für die Zuordnung eines lokalen Ports hilft ergänzend die Anleitung Welches Programm belegt welchen Port?.

FAQ: Häufige Fragen zur Process Monitor Anleitung

Fazit: Mit Process Monitor aus einer Vermutung eine überprüfbare Diagnose machen

Der Sysintenal Process Monitor ist besonders dann hilfreich, wenn eine Fehlermeldung von einem Programm erzeugt wird, aber die eigentliche Ursache verborgen bleibt. Eine kurze, passend gefilterte Aufnahme im Process Monitor kann Dir den betroffenen Pfad, das ausführende Konto und die gescheiterte Operation anzeigen.