Process Monitor (ProcMon) Praxisleitfaden — „Konfiguration wird nicht gelesen“ und ACCESS DENIED in 10 Minuten identifizieren

„Ich habe die Konfigurationsdatei geändert, aber das Verhalten der Anwendung ändert sich nicht“ – „Auf dem Entwicklungsrechner läuft es, aber nur auf dem Rechner des Kunden stürzt es direkt nach dem Start ab“ – „Bis gestern lief es noch. Am Programm wurde nichts geändert.“ – Anfragen zur Fehleruntersuchung kommen meist in dieser Form. Und bei einem Großteil dieser Art von Symptomen führt selbst intensives Lesen des Quellcodes nicht zur Ursache. Denn welche Datei die Anwendung tatsächlich liest, welche Registry sie einsieht und woran sie scheitert, wird nicht vom Code, sondern von der Ausführungsumgebung bestimmt.

Genau dieses „was tatsächlich passiert ist“ zeichnet das kostenlos von Microsoft bereitgestellte Sysinternals-Tool Process Monitor (ProcMon) auf. Es zeichnet Aktivitäten des Dateisystems, der Registry sowie von Prozessen/Threads in Echtzeit vollständig auf – gewissermaßen ein Verhaltensprotokoll-Rekorder für Windows – und ist auch bei unseren Fehleruntersuchungen neben WinDbg eines der am häufigsten eingesetzten Werkzeuge.¹

So mächtig es ist, so leicht endet der erste Kontakt mit „zu viel, um es zu lesen“: Startet man es ohne weitere Einstellungen, strömen jede Sekunde mehrere Tausend bis Zehntausend Ereignisse vorbei. Dieser Artikel fasst den kürzesten Weg zusammen, um ProcMon in der Praxis einzusetzen – das Setzen von Filtern, das Lesen der Spalte Result, gängige Untersuchungsmuster nach Symptom, Vorsichtsmaßnahmen in Produktionsumgebungen sowie die Abgrenzung zu anderen Untersuchungswerkzeugen – aus der Perspektive der praktischen Fehleruntersuchung.

1. Zunächst das Fazit

• Die Frage, die ProcMon beantwortet, lautet: „Wann hat dieser Prozess an welchem Pfad was getan, und wie ist es ausgegangen?“ In wenigen Minuten lässt sich klären, woher eine Konfigurationsdatei gelesen wird, in welcher Reihenfolge eine DLL gesucht wurde und welche Operation zu ACCESS DENIED geführt hat.
• Die bewährte Vorgehensweise lautet: „Zunächst mit Process Name ein Include für den betreffenden Prozess setzen, dann mit Result auf Fehlerfälle eingrenzen.“ Es ist kein Werkzeug, mit dem man rohe Ereignisse von oben nach unten liest.
• In der Spalte Result gibt es viele Werte, die fehlerhaft aussehen, aber normal sind. BUFFER OVERFLOW ist meist ein normaler API-Hin-und-Rückweg, NAME NOT FOUND meist nur ein Zwischenschritt in der Suchreihenfolge (Kapitel 4).
• Der Filter grenzt nur die Anzeige ein, im Hintergrund werden weiterhin alle Ereignisse aufgezeichnet. Wenn Sie das Log speichern und weitergeben, speichern Sie alle Ereignisse. Bei langen Aufzeichnungen schützen Sie umgekehrt mit Drop Filtered Events den Arbeitsspeicher (Kapitel 5).
• ProcMon ist kein Allheilmittel. „Welcher Prozess hält diese Datei gerade?“ gehört zum Bereich von Process Explorer, der Zustand im Moment eines Absturzes zum Bereich des Crash Dumps, und wo CPU verbraucht wird, zum Bereich von PerfView (Kapitel 7).

Zunächst eine Übersichtstabelle, mit der Sie anhand des Symptoms das passende Werkzeug auswählen können.

2. Was ist ProcMon? — Die Installation ist in einer Minute erledigt

Process Monitor ist eines der Sysinternals-Tools und ein Überwachungswerkzeug, das Aktivitäten des Dateisystems, der Registry sowie von Prozessen/Threads in Echtzeit anzeigt. Es ist der Nachfolger, der die beiden früheren Tools Filemon und Regmon vereint und erweitert hat, und bietet detaillierte Informationen zu jedem Ereignis, nicht-destruktive Filter, die Aufzeichnung von Thread-Stacks sowie Boot-Time-Logging.¹

Die Installation ist einfach: Es gibt keinen Installer, Sie laden lediglich die ZIP-Datei von der Download-Seite herunter, entpacken sie und führen Procmon.exe aus. Für eilige Untersuchungen können Sie es über den Dienst Sysinternals Live auch direkt über https://live.sysinternals.com/procmon.exe ausführen.² Beim ersten Start werden Sie zur Zustimmung zur Lizenzvereinbarung aufgefordert; da ein Kernel-Treiber geladen wird, sind Administratorrechte (UAC-Erhöhung) erforderlich. Die allgemeine Frage, wann Administratorrechte benötigt werden, wurde bereits in „Wann werden unter Windows Administratorrechte benötigt“ behandelt – ein Werkzeug, das Ereignisse des gesamten Betriebssystems einsieht, gehört typischerweise zu denen, die eine Rechteerhöhung benötigen.

Sobald es gestartet ist, beginnt die Aufzeichnung, und Ereignisse beginnen über den Bildschirm zu laufen. Es genügt, sich drei zentrale Bedienschritte zu merken.

Eine Ereigniszeile besteht aus Time (Zeitpunkt), Process Name (Prozess), PID, Operation (Vorgang), Path (Zielpfad), Result (Ergebnis) und Detail (Einzelheiten). Operation hat in etwa die Granularität der Win32-API, mit Werten wie CreateFile (Datei öffnen/erstellen), ReadFile/WriteFile, RegOpenKey/RegQueryValue und ähnlichen. Mit anderen Worten: Das ProcMon-Log ist ein „Protokoll des Gesprächs zwischen Anwendung und Betriebssystem“, in dem die Differenz zwischen „Absicht“ und „Realität“ direkt sichtbar wird – etwa wenn die Anwendung glaubt, eine Konfigurationsdatei zu lesen, tatsächlich aber woanders liest.

3. Filter — ProcMon ist ein Werkzeug, das man erst eingrenzt und dann liest

Zeichnet man ohne weitere Einstellungen auf, laufen selbst bei einem im Leerlauf befindlichen Windows jede Sekunde mehrere Tausend Ereignisse durch. Man kann sagen, dass die praktische Nutzbarkeit von ProcMon davon abhängt, wie der Filter eingesetzt wird; die bewährte Vorgehensweise besteht aus den folgenden zwei Stufen.

Stufe 1: Nach Prozess eingrenzen. Öffnen Sie mit Ctrl+L den Filter-Dialog und fügen Sie Process Name / is / myapp.exe / Include hinzu. Alternativ können Sie das Fadenkreuz-Symbol in der Symbolleiste auf das Fenster der Zielanwendung ziehen, um den Filter nur auf diesen Prozess zu setzen.

Stufe 2: Nach Result oder Operation eingrenzen. Wenn Sie „fehlgeschlagene Operationen suchen“ möchten, verwenden Sie Result / is not / SUCCESS / Include (zeigt nur Fehlerfälle). Wenn Sie „nur Schreibvorgänge sehen“ möchten, verwenden Sie Category / is / Write / Include. Wenn Sie wissen möchten, „wer diese Konfigurationsdatei anfasst“, grenzen Sie nicht nach Prozess ein, sondern verwenden Path / contains / app.config / Include – und so weiter.

Ein weiteres in der Praxis häufig genutztes Mittel ist die interaktive Eingrenzung per Rechtsklick auf eine Ereigniszeile. Sobald Sie eine Zeile gefunden haben, die dem Ziel nahekommt, klicken Sie sie mit der rechten Maustaste an und wählen „Include ‘dieser Pfad’“ oder „Exclude ‘dieser Prozess’“ – der Filter baut sich so auf, ohne dass der Dialog geöffnet werden muss. Die Grundbewegung besteht darin, Rauschquellen (Antivirensoftware, Indexer usw.) per Exclude zu entfernen und nur den Bereich vor und nach der Zieloperation übrig zu lassen. Als Sehhilfe kann auch Highlight (Ctrl+H) verwendet werden: Damit lassen sich Zeilen mit demselben Bedingungsausdruck wie beim Filter farblich markieren, sodass Sie bei „ich möchte den Gesamtablauf sehen, aber die Fehlerfälle hervorheben“ statt eines Filters ein Highlight verwenden.

Drei Eigenheiten sollten Sie kennen, sonst tappen Sie leicht in eine Falle:

• Der Filter grenzt nur die Anzeige ein, nicht die Aufzeichnung. Im Hintergrund werden (standardmäßig) weiterhin alle Ereignisse aufgezeichnet, und wenn Sie den Filter entfernen, kehren Sie jederzeit zur Gesamtansicht zurück. Deshalb spricht man von einem nicht-destruktiven Filter – ein Design, bei dem es kaum vorkommt, dass man durch zu starkes Eingrenzen Beweise verliert.¹
• Die Filtereinstellungen werden auch beim nächsten Start übernommen. Dass der Filter der vorherigen Untersuchung erhalten bleibt und man sich über „es wird nichts angezeigt“ wundert, ist ein Weg, den wohl jeder einmal geht. Wenn die Anzeige seltsam erscheint, sollten Sie zuerst Reset Filter (Ctrl+R) im Filter-Menü in Betracht ziehen.
• Standardmäßig sind bereits einige Exclude-Regeln gesetzt. ProcMon selbst sowie Paging-I/O beispielsweise sind von vornherein ausgeschlossen. Bei Untersuchungen, bei denen „lückenlos das gesamte System“ erforderlich ist, sollten Sie sich der Existenz dieser Standardfilter bewusst sein.

4. Die Spalte Result lesen — Was fehlerhaft aussieht, aber normal ist

Grenzt man mit dem Filter auf Fehlerfälle ein, ist man überrascht, wie viele „fehlerhaft aussehende Ergebnisse“ nun auftauchen. Wichtig ist hier: Der Großteil der vermeintlichen Fehlerwerte in der Spalte Result ist Teil eines normalen Ablaufs. Im Folgenden die wichtigsten Result-Werte und ihre Bedeutung.

Die drei Hauptdarsteller einer Untersuchung sind darunter NAME NOT FOUND, ACCESS DENIED und SHARING VIOLATION. Für jeden gibt es ein bewährtes Untersuchungsmuster, das wir im nächsten Kapitel ausgehend von den Symptomen betrachten.

Umgekehrt leicht zu übersehen ist das Muster, bei dem „SUCCESS die Ursache ist“. Zum Beispiel war die Antwort auf „die korrigierte Konfigurationsdatei wird nicht übernommen“ nicht nur einmal ein SUCCESS beim Zugriff auf eine alte Konfigurationsdatei an einer anderen Stelle. Betrachtet man nur die Fehlerfälle, übersieht man die erfolgreich geladene „falsche richtige Antwort“ – deshalb ist es sicherer, nach Path einzugrenzen und alle Zugriffe auf diesen Dateityp einschließlich der erfolgreichen zu betrachten.

5. Gängige Untersuchungsmuster nach Symptom

5.1 „Die Konfiguration wurde korrigiert, wird aber nicht übernommen“ — Identifizieren, von wo gelesen wird

Setzt man mit Path / contains / Name der Konfigurationsdatei ein Include und startet die Anwendung, erhält man eine Liste, aus welchem Ordner und in welcher Reihenfolge die Anwendung nach einer Datei mit diesem Namen gesucht hat. Häufige Wahrheiten sind eine der folgenden:

• Es wurde nicht der Ordner der exe, sondern eine Kopie unter %APPDATA% oder ProgramData gelesen (das Design sah vor, beim ersten Start eine Kopie anzulegen)
• Registry- bzw. Systemordnerzugriffe eines 32-Bit-Prozesses wurden durch die WOW64-Umleitung abgefangen, sodass der vermeintlich betrachtete Ort und der tatsächliche Ort auseinanderfielen
• Schreibvorgänge unter Program Files am Installationsort wurden virtualisiert (VirtualStore), sodass Lese-/Schreibvorgänge in Wirklichkeit an einem anderen Ort landeten

In allen Fällen erkennt man es mit ProcMon auf einen Blick, da in Path der vollständige Pfad angezeigt wird. Die Kehrseite dieses Themas – wie man den Ablageort von Konfigurationsdateien gestalten sollte – haben wir in „Nicht nur appsettings.json — Praxis des Konfigurationsmanagements“ behandelt.

5.2 „Startet nur in dieser Umgebung nicht“ — Der DLL-Suche folgen

Wenn die Anwendung direkt nach dem Start abstürzt oder ein Fehler der Art „DLL nicht gefunden“ auftritt, setzen Sie ein Include auf den Prozess, fügen Path / ends with / .dll hinzu und betrachten die Kette der NAME NOT FOUND. Da Windows bei der DLL-Suche Ordner in einer festen Reihenfolge durchläuft, erscheint im ProcMon-Log genau das Muster „NAME NOT FOUND in der Suchreihenfolge, bis irgendwo SUCCESS eintritt (oder es bis zum Ende nicht gefunden wird)“. Die DLL, bei der es bis zum Ende zu keinem SUCCESS kommt, ist der Übeltäter. Umgekehrt findet man hier auch das Muster „SUCCESS, aber eine alte DLL an einer nicht beabsichtigten Stelle wird verwendet“. Zur Logik der Suchreihenfolge lesen Sie bitte ergänzend „Wie die Windows-DLL-Namensauflösung funktioniert“.

Auch das mit COM/ActiveX verbundene „Klasse ist nicht registriert“ folgt demselben Muster und lässt sich als NAME NOT FOUND unter dem CLSID-Zweig von RegOpenKey beobachten. Bei Vorfällen, bei denen durch eine Verwechslung von 32-Bit und 64-Bit auf die falsche Registry-Ansicht zugegriffen wird, ist ProcMon – wie in „Ursachen und Prüfschritte, wenn ActiveX unter Office 2024/Microsoft 365 nicht funktioniert“ beschrieben – der schnellste Weg.

5.3 „Es kommt zu ACCESS DENIED“ — Prüfen, unter wessen Rechten der Prozess läuft

Finden Sie ein ACCESS DENIED, doppelklicken Sie auf dieses Ereignis und prüfen Sie den Process-Tab. Dort wird angezeigt, als welcher Benutzer der Prozess lief, sodass Diskrepanzen wie „der Dienst lief nicht als SYSTEM, sondern unter einem eingeschränkten Dienstkonto“ oder „nur beim Start über den Taskplaner war es ein anderer Benutzer“ hier zutage treten. Handelt es sich um eine Datei, lässt sich die Ursache durch Abgleich mit der ACL dieses Pfads endgültig klären. Greift Antivirensoftware ein, ist zudem häufig zu sehen, dass unmittelbar davor oder danach ein anderer Prozess (die Engine der Schutzsoftware) denselben Pfad berührt – auch das ist ein Beweis, der nur durch ProcMons chronologische Aufzeichnung möglich ist.

5.4 „Die Dateiverarbeitung schlägt gelegentlich fehl“ — Den Gegenpart von SHARING VIOLATION suchen

Bei einer Freigabeverletzung ist die Chronologie entscheidend. Setzt man ein Include nach Path, ohne nach Prozess zu filtern, und zeichnet auf, erscheint im Moment des Fehlschlags in den umliegenden Zeilen, wer dieselbe Datei geöffnet hatte. Klassische Gegenparts sind Backup-Software, Antivirensoftware oder zurückgebliebene Excel-Prozesse. Wie man diesen Konflikt bei der Dateiintegration von vornherein vermeidet, haben wir in „Grundlagen der exklusiven Steuerung bei der Dateiintegration“ zusammengefasst, das Problem zurückbleibender Excel-Prozesse in „Das Problem, dass EXCEL.EXE bei Excel-Operationen mit C# bestehen bleibt“. Anzumerken ist außerdem: Wenn Sie nur wissen möchten, „wer hält die Datei gerade in diesem Moment“, ist die Handle-Suche (Ctrl+F) von Process Explorer schneller als ProcMon.³

5.5 „Der Start dauert lange“ — Eingrenzen, wo Zeit verbraucht wird

Fügt man über die Spaltenkonfiguration die Spalte Duration hinzu, sieht man, wie viel Zeit einzelne Operationen benötigt haben. Zudem lassen sich über Process Activity Summary oder File Summary im Tools-Menü Anzahl der Operationen und Zeitaufwand pro Prozess bzw. Datei aggregieren. Für Eingrenzungen wie „beim Start wurden mehrere Zehntausend Registry-Lesevorgänge durchgeführt“ oder „der Zugriff auf einen Netzwerkpfad wartete bis zum Timeout“ reicht das völlig aus. Eine ernsthafte Profilierung, wo CPU verbraucht wird, gehört jedoch nicht zum Aufgabenbereich von ProcMon. Ist es nicht I/O, sondern Berechnung, die die Verzögerung verursacht, wechseln Sie zu PerfView und dotnet-trace.

5.6 Probleme beim Start bzw. bei der Anmeldung — Boot-Logging

Bei Fällen wie „ein Dienst schlägt vor der Anmeldung fehl“ oder „eine als Autostart registrierte Anwendung startet nicht“ – also wenn das Problem auftritt, bevor ProcMon manuell gestartet werden könnte – verwenden Sie Enable Boot Logging im Options-Menü. Beim nächsten Systemstart werden Ereignisse vom frühen Bootvorgang an aufgezeichnet, und beim darauffolgenden Start von ProcMon werden Sie zum Speichern aufgefordert. Boot-Time-Logging wird als offizielle Funktion von ProcMon bereitgestellt¹ und ist bei Untersuchungen zur Startreihenfolge oder zu Anmeldeskripten das einzige verfügbare Auge.

6. Speichern und Weitergeben von Logs — Wenn der Kunde die Aufzeichnung in seiner Umgebung durchführt

In der Praxis der Fehleruntersuchung ist es keine Seltenheit, dass sich das Problem nur in der Umgebung des Kunden reproduzieren lässt. ProcMon-Logs lassen sich als PML-Datei speichern und zeigen auch bei Öffnen auf einer anderen Maschine alle Spalten und Details an, sodass die Arbeitsteilung „der Kunde erfasst, wir analysieren“ funktioniert. Die Anleitung, die wir dafür an Kunden weitergeben, sieht wie folgt aus:

1. Procmon.exe als Administrator ausführen und der Lizenzvereinbarung zustimmen
2. Nach dem Start zunächst mit Ctrl+E die Aufzeichnung stoppen und mit Ctrl+X die Anzeige löschen
3. Mit Ctrl+E die Aufzeichnung starten und die problematische Aktion reproduzieren
4. Sobald die Reproduktion gelingt (oder ein Fehler auftritt), sofort mit Ctrl+E stoppen
5. Unter File > Save All events statt Events displayed using current filter wählen, im PML-Format speichern, als ZIP komprimieren und übermitteln

Der entscheidende Punkt ist „All events“ in Schritt 5. Selbst wenn auf dem Bildschirm des Kunden noch ein Filter aktiv ist, liegt die Aufzeichnung selbst vollständig vor, sodass wir sie frei neu eingrenzen können. Bei Problemen, deren Reproduktion lange dauert oder deren Auftrittszeitpunkt unbekannt ist, verbraucht die Aufzeichnung sonst kontinuierlich Speicher; geben Sie daher mindestens eine der folgenden Maßnahmen an: Filter > Drop Filtered Events aktivieren, um nur den betreffenden Prozess aufzuzeichnen, oder unter File > Backing Files das Ziel von virtuellem Speicher auf eine Datei umstellen. Lässt man es ohne diese beiden Kenntnisse über Nacht laufen, erschöpft ProcMon den Speicher und stößt an seine eigenen Grenzen, noch bevor das eigentliche Untersuchungsziel eintritt.

Wenn Sie das automatisieren möchten, stehen auch Kommandozeilenschalter zur Verfügung: /AcceptEula unterdrückt den Zustimmungsdialog, /BackingFile legt die Aufzeichnungsdatei fest, /Runtime stoppt automatisch nach einer angegebenen Sekundenzahl, und /Terminate beendet ein laufendes ProcMon. Mit dieser Kombination lässt sich erreichen, dass „ein Operator im Störungsfall lediglich ein Batch-Skript ausführen muss, damit Beweise erhalten bleiben“. Der Grundgedanke, im Voraus festzulegen, was im Störungsfall erfasst werden soll, ist derselbe wie bei der Erfassung von Crash Dumps oder der Gestaltung von Ereignisprotokollen.

7. Grenzen von ProcMon und die Abgrenzung zu anderen Werkzeugen

ProcMon ist ein Werkzeug, das die „Chronologie von Operationen“ betrachtet, und eignet sich nicht für jede Art von Untersuchung. Die Rollenverteilung bei unseren Untersuchungen sieht wie folgt aus:

An folgenden drei Grenzen kommt es leicht zu Verwirrung:

• Netzwerk: ProcMon zeichnet TCP/UDP-Verbindungs- und Sende-/Empfangsereignisse auf (welcher Prozess mit wem kommuniziert hat), der Inhalt der Pakete ist jedoch nicht sichtbar. Für Protokolluntersuchungen wenden Sie sich an Wireshark oder das in Windows integrierte pktmon.⁴
• Speicher: „Der Speicherverbrauch steigt kontinuierlich“ lässt sich mit ProcMon nicht nachverfolgen. Bei einem Managed Heap gehen Sie zur Unterscheidung zwischen GC und Leck über, bei Handles zum Verfahren der Handle-Leck-Untersuchung.
• Stack: Tatsächlich zeichnet ProcMon auch den Thread-Stack auf, von dem jedes Ereignis ausgelöst wurde (Doppelklick auf das Ereignis → Stack-Tab); mit konfigurierten Symbolen lässt sich auf Code-Ebene identifizieren, „wer diesen Dateizugriff ausgelöst hat“. An diesem Punkt geht es nahtlos in die Welt von WinDbg über, und die Verwaltung der Symbole (PDB) wird entscheidend.

8. Zusammenfassung — „Bevor Sie den Code lesen, betrachten Sie die Fakten“

Bei der Untersuchung umgebungsabhängiger Fehler besteht der erste Schritt weder darin, den Code zu lesen, noch eine Hypothese aufzustellen, sondern eine Aufzeichnung dessen zu erstellen, was tatsächlich passiert ist. ProcMon ist dafür der kürzeste Weg: Mit einer Minute Installation und wenigen Minuten Aufzeichnung erhalten Sie die unumstößlichen Fakten – welcher Pfad, in welcher Reihenfolge, unter welchen Rechten berührt wurde und woran es scheiterte. Beherrscht man diese drei Punkte – die zweistufige Filterung (Prozess → Result), das Lesen von fehlerhaft aussehenden, aber normalen Result-Werten, und die Weitergabe mit vollständig gespeicherten Ereignissen –, kommt eine Untersuchung, die bei „auf dem Entwicklungsrechner lässt es sich nicht reproduzieren“ feststeckte, noch am selben Tag einen Schritt voran.

Wir übernehmen die Untersuchung von Fehlern mit unbekannten Reproduktionsbedingungen, die Einrichtung von Verfahren zur Beweiserfassung bei Störungen, die nur in der Kundenumgebung auftreten, sowie die Ursachenanalyse unter Kombination von ProcMon, WinDbg und PerfView. Wir können Ihnen auch schon in der Phase helfen, in der „im Log nichts zu sehen ist, aber es funktioniert nicht“.

Verwandte Artikel

• WinDbg + SOS zum Lesen von Crash Dumps — Praktische Einführung in die Analyse nach der Erfassung
• „Langsam“ mit PerfView und dotnet-trace identifizieren — Praktische Einführung in die .NET-Performance-Untersuchung
• Einführung in die Erfassung von Windows-Crash-Dumps – WER/ProcDump/WinDbg
• Wie die Windows-DLL-Namensauflösung funktioniert – Suchreihenfolge und SxS
• Untersuchung eines Langzeitbetrieb-Absturzes bei einer Industriekamera – Handle-Leck-Teil

Verwandte Beratungsbereiche

KomuraSoft LLC (合同会社小村ソフト) übernimmt die Ursachenuntersuchung von umgebungsabhängigen, schwer reproduzierbaren Fehlern, die Einrichtung von Verfahren zur Beweiserfassung bei Störungen sowie Unterstützung bei der Fehlerbehebung bestehender Windows-Anwendungen.

• Fehleruntersuchung und Ursachenanalyse
• Technische Beratung und Design-Review
• Überarbeitung und Wartung bestehender Windows-Software
• Kontakt

Quellen

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Ist es unbedenklich, ProcMon in einer Produktionsumgebung laufen zu lassen?

Eine kurzzeitige Aufzeichnung wird in der Praxis häufig durchgeführt, ist aber nicht bedingungslos sicher. Da ProcMon einen Treiber lädt und eine große Menge an Ereignissen aufzeichnet, verbraucht es auf Servern mit hohem Ereignisaufkommen spürbar CPU und Arbeitsspeicher. Es gibt drei Gegenmaßnahmen: (1) Die Aufzeichnung unmittelbar vor der Reproduktionsaktion starten und unmittelbar danach stoppen, um die Aufzeichnungsdauer so kurz wie möglich zu halten, (2) bei länger andauernder Überwachung im Filter-Menü Drop Filtered Events aktivieren, damit Ereignisse außerhalb des Filters nicht gespeichert werden, und (3) mit Backing File das Ziel der Aufzeichnung von Arbeitsspeicher auf eine Datei umstellen. Außerdem empfehlen wir, die Durchführung außerhalb der Geschäftszeiten oder nach Erstellung eines Snapshots vorzusehen und sie demselben Freigabeprozess wie normale Änderungsarbeiten zu unterwerfen.

Es gibt zu viele Ereignisse und ich finde die gesuchte Zeile nicht. Wie sollte ich filtern?

Die bewährte Vorgehensweise ist, zunächst mit Process Name ein Include nur für den betreffenden Prozess zu setzen und anschließend mit Result auf die Fehlerfälle (NAME NOT FOUND, ACCESS DENIED usw.) einzugrenzen. Sobald Sie eine gesuchte Zeile gefunden haben, grenzen Sie interaktiv weiter ein, indem Sie mit Rechtsklick auf die Zeile Include oder Exclude wählen. Umgekehrt kommt es häufig vor, dass man mit gesetztem Filter speichert und dann feststellt, dass Informationen fehlen – wenn Sie das Log in eine Datei speichern und an andere weitergeben, denken Sie daran, dass der Filter nur die Anzeige eingrenzt, und speichern Sie alle Ereignisse. Da die Filtereinstellungen auch beim nächsten Start erhalten bleiben, sollten Sie bei „es wird nichts angezeigt“ zunächst über Reset Filter im Filter-Menü prüfen, ob noch ein alter Filter aus einer vorherigen Sitzung vorhanden ist.

Ist BUFFER OVERFLOW in der Spalte Result ein Anzeichen für einen Bug oder einen Angriff?

Nein. Das hat nichts mit dem Sicherheitsbegriff Pufferüberlauf-Angriff zu tun, sondern ist ein normaler API-Hin-und-Rückweg: „Die benötigten Daten waren größer als der vom Aufrufer bereitgestellte Puffer, daher wurde die benötigte Größe zurückgegeben.“ Viele APIs sind so konzipiert, dass sie zunächst mit einem kleinen Puffer aufgerufen werden, um die benötigte Größe zu erfahren, und dann nach erneuter Zuweisung erneut aufgerufen werden – wenn direkt danach mehrere SUCCESS für denselben Pfad folgen, ist das unproblematisch. Ebenso bedeutet NAME NOT FOUND meist nur, dass „in der Mitte der Suchreihenfolge nichts gefunden wurde“; solange es am Ende irgendwo zu SUCCESS kommt, ist das nicht ungewöhnlich. Ein fehlerhafter Result-Wert lässt sich erst dann als Ursache bezeichnen, wenn geprüft wurde, ob das Scheitern dieser Operation tatsächlich kausal mit dem Symptom der Anwendung zusammenhängt.

Wie unterscheidet man die Verwendung von Process Explorer und Process Monitor?

Process Monitor ist ein Werkzeug, das den ‚Ablauf von Operationen‘ (wann, welcher Prozess, welchen Pfad, was getan wurde und was dabei herauskam) chronologisch aufzeichnet, während Process Explorer den ‚Zustand in diesem Moment‘ zeigt (welche Dateien oder DLLs ein Prozess gerade geöffnet hat, CPU- und Speicherauslastung). Wenn Sie beispielsweise wissen möchten, „Ich kann diese Datei nicht löschen – wer hält sie?“, ist die Handle-Suche von Process Explorer am schnellsten; wenn Sie wissen möchten, „wann und in welcher Reihenfolge liest die Anwendung diese Datei?“, ist Process Monitor die richtige Wahl. In der Praxis hält man beide stets als Teil der Sysinternals Suite bereit und merkt sich: Zustand ist Process Explorer, Verlauf ist Process Monitor.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.