Einführung in das Sammeln von Windows-Absturzabbildern - WER/ProcDump/WinDbg

Sobald eine Windows-Anwendung anfängt, „nur gelegentlich“ abzustürzen, gibt es einige Situationen, in denen Logs allein zur Aufklärung nicht ausreichen.

Besonders unangenehm sind Fälle wie diese.

• Es tritt nur in der Kundenumgebung auf
• Die Ausnahmemeldung liegt vor, aber der Kontext des Aufrufers fehlt
• Es sind nicht nur die Managed-Anteile von C# / .NET beteiligt, sondern auch COM, P/Invoke, native DLLs und Vendor-SDKs
• Es stürzt nur nach langem Dauerbetrieb ab

Genau hier helfen Absturzabbilder. Hält man den Prozesszustand zum Zeitpunkt des Absturzes in einer Datei fest, lassen sich im Nachhinein der Ausnahmecode, der Stack des abgestürzten Threads, die geladenen Module und ein Teil oder der gesamte Speicher auslesen.

Unter Windows ist es übersichtlich, in dieser Reihenfolge zu denken: zunächst WERs LocalDumps, bei Bedarf Sysinternals ProcDump, und wenn noch mehr Kontrolle gewünscht ist, MiniDumpWriteDump. Dieser Artikel fasst die ersten Schritte der Absturzabbild-Erfassung zusammen, ausgehend von Windows-Desktop-Anwendungen, residenten Anwendungen, Windows-Diensten, Anlagenanbindungs-Tools und Ähnlichem.

Begriffe, die in diesem Artikel wiederholt vorkommen

Vorab kurz geklärt. Bleiben diese unscharf, verschwimmen auch die folgenden Kapitel.

1. Das Wichtigste zuerst

Zunächst nur die Punkte, die Sie sich als Erstes merken sollten.

• Der sichere erste Schritt ist, WER LocalDumps pro Anwendung zu konfigurieren. Ohne zusätzliche Tools bleibt nach einem Absturz ein Abbild lokal erhalten.
• Für Felduntersuchungen mit niedriger Reproduktionsrate, oder wenn Sie auch First-Chance-Exceptions bzw. Hänger sehen möchten, verwenden Sie ProcDump.
• Betrachten Sie die eigene Erfassung als letzten Ausweg — das ist ungefähr die richtige Priorität. Ziehen Sie MiniDumpWriteDump erst in Betracht, wenn Sie es tatsächlich brauchen.
• Genauso wichtig wie die Abbilder selbst ist die Aufbewahrung der PDBs und der ausgelieferten Binärdateien. Ein Abbild allein, ohne Symbole, reduziert die lesbare Informationsmenge erheblich.
• Vollständige Abbilder sind mächtig, aber ihre Größe und das Risiko, vertrauliche Daten einzuschließen, sind es ebenso. Legen Sie Speicherort, Aufbewahrungsanzahl, Zugriffsrechte und das Freigabeverfahren vorab fest.

Die für die Einführungsphase empfohlene Konfiguration landet meist etwa hier.

Kurz gesagt: zuerst WER, dann ProcDump, zuletzt die eigene Erfassung. Wer in umgekehrter Reihenfolge beginnt, macht das Design meist unnötig schwer.

2. Was ein Absturzabbild zeigt

Ein Absturzabbild ist eine „Momentaufnahme dieses Augenblicks“. Es ähnelt weniger einer Überwachungskamera als vielmehr einem Standbild vom Unfallort.

Deshalb lassen sich diese Informationen recht einfach ermitteln.

• Mit welchem Ausnahmecode der Absturz erfolgte
• Welcher Thread abgestürzt ist
• Der Call Stack zu diesem Zeitpunkt
• Die geladenen Module
• Je nachdem, wie viel Speicher einbezogen wurde, der Zustand des Heaps und der Inhalt von Objekten

Andererseits fehlen bei einem Abbild allein häufig folgende Dinge.

• Die Zeitleiste, die zu diesem Moment geführt hat
• Ein Wachstumstrend, der Stunden zuvor begonnen hat
• Der externe Zustand von Kommunikation oder Geräten
• Die letzten Eingaben und der fachliche Kontext

In der Praxis gilt daher als Grundprinzip: Versuchen Sie nicht, sich allein auf das Abbild zu verlassen, sondern kombinieren Sie es mit Logs und Heartbeats.

3. Überblick über die Sammelmethoden

Für die Erfassung von Abbildern bei Windows-Anwendungen gibt es vier Methoden, die Sie als Einsteiger kennen sollten.

Für Einsteiger ist das Wichtigste, noch vor der Frage „womit erfassen“ festzulegen, „unter welchen Bedingungen“, „wohin“ und „in welcher Größe“ erfasst wird.

4. Der empfohlene erste Schritt: WER LocalDumps

4.1. Die zuerst zu prüfenden Registrierungswerte

Windows Error Reporting (WER) verfügt über LocalDumps, das nach einem Absturz Benutzermodus-Abbilder lokal speichert. Da keine zusätzlichen Tools verteilt werden müssen, ist dies als erster Schritt sehr gut zu handhaben.

Der Basisschlüssel ist hier.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps

Hier lässt sich zwar auch eine globale Konfiguration ablegen, in der Praxis ist es aber einfacher, sich an anwendungsspezifischen Unterschlüsseln zu orientieren.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe

Es gibt drei Werte, die Sie sich zuerst ansehen sollten.

4.2. Beispiel für eine anwendungsspezifische Konfiguration

Möchten Sie zum Beispiel für MyApp.exe bis zu 10 vollständige Abbilder in C:\CrashDumps\MyApp behalten, können Sie zunächst wie folgt konfigurieren.

reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpFolder /t REG_EXPAND_SZ /d "C:\CrashDumps\MyApp" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpCount /t REG_DWORD /d 10 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpType /t REG_DWORD /d 2 /f

Dieses Beispiel hat vier wesentliche Punkte.

• Es ist auf MyApp.exe beschränkt, nicht global
• Der Ausgabeort ist in einen eigenen Ordner getrennt
• Es beginnt mit vollständigen Abbildern
• Die Aufbewahrungsanzahl ist auf 10 begrenzt

4.3. Überprüfen, ob die Erfassung funktioniert hat

Sobald die Konfiguration steht, ist es sicherer, in einer Testumgebung mindestens einmal eine vollständige Erfassung durchzuspielen, statt in der Produktion auf den natürlichen Absturz zu warten.

Prüfen Sie diese vier Punkte.

1. Erscheint eine .dmp-Datei im erwarteten Ordner?
2. Passt die Größe zu den betrieblichen Erwartungen?
3. Lässt sie sich in WinDbg öffnen?
4. Ist der Absturz im Anwendungsprotokoll der Ereignisanzeige sichtbar?

4.4. Minimaler Code, um die Anwendung absichtlich abstürzen zu lassen

„Vollständig erfassen“ klingt einfach, aber wenn Sie auf einen echten Absturz warten, kommen Sie bei der Verifikation nicht voran. Für die Verifikation ist es schneller, eine kleine EXE vorzubereiten, die absichtlich abstürzt.

Bei .NET genügt eine Konsolenanwendung, die lediglich eine unbehandelte Ausnahme wirft. Eine unbehandelte Managed-Ausnahme in .NET beendet den Prozess und fällt damit direkt unter WER.

// CrashTest.csproj: <TargetFramework>net8.0</TargetFramework>
using System;
using System.Threading;

internal static class Program
{
    private static void Main()
    {
        Console.WriteLine($"PID={Environment.ProcessId} / Stürzt in 3 Sekunden ab.");
        Thread.Sleep(3000);

        throw new InvalidOperationException("beabsichtigter Absturz für den Test der Abbilderfassung");
    }
}

Wenn Sie die native Seite prüfen möchten, ist es näherliegend, eine Zugriffsverletzung (0xC0000005) auszulösen. Damit sie von der Optimierung nicht wegoptimiert wird, fügen Sie volatile hinzu.

// crash_test.cpp / C++17 / MSVC
int main()
{
    volatile int* p = nullptr;
    *p = 1;  // Hier tritt STATUS_ACCESS_VIOLATION auf
    return 0;
}

Hier gibt es genau einen Punkt, den man leicht übersieht. Der Name des LocalDumps-Unterschlüssels muss mit dem Dateinamen der EXE übereinstimmen, die gerade zum Absturz gebracht wird. Wenn Sie nur einen Schlüssel für MyApp.exe anlegen und dann CrashTest.exe abstürzen lassen, erscheint natürlich kein Abbild. Legen Sie für die Verifikation entweder vorübergehend einen Schlüssel für CrashTest.exe an, oder testen Sie über die globale Konfiguration.

Sysinternals’ NotMyFault wird ebenfalls häufig als Werkzeug zum „absichtlichen Abstürzen“ genannt, dient jedoch dazu, das Windows-System selbst zum Absturz oder zum Hängen zu bringen und ein Bluescreen-Abbild zu erzeugen, und erfordert außerdem Administratorrechte. Für die Verifikation von LocalDumps bei Benutzermodus-Anwendungen ist eine kleine eigene EXE wie oben sicherer und zuverlässiger.

5. Wann ProcDump zum Einsatz kommt

WER reicht oft aus, aber es gibt auch Situationen, in denen ProcDump nützlich ist.

• Sie möchten eine dauerhafte Registrierungseinstellung vermeiden
• Sie möchten nur einen bereits laufenden Prozess überwachen
• Sie möchten erst ab dem nächsten Start überwachen
• Sie möchten First-Chance-Exceptions sehen
• Sie möchten einen Hänger erfassen
• Sie möchten anhand von Leistungsindikatoren oder anderen Bedingungen erfassen

5.1. Häufig verwendete Optionen

Beschränkt man sich auf das, was man als Einsteiger häufig braucht, kommt man mit den folgenden ProcDump-Optionen schon recht weit.

5.2. Typische Befehlsbeispiele

Vollständiges Abbild eines bereits laufenden Prozesses bei unbehandelter Ausnahme

procdump -accepteula -ma -e 1234 C:\CrashDumps\MyApp

Auf den nächsten Start warten und bei unbehandelter Ausnahme ein vollständiges Abbild erstellen

procdump -accepteula -ma -e -w MyApp.exe C:\CrashDumps\MyApp

Selbst starten und direkt überwachen

procdump -accepteula -ma -e -x C:\CrashDumps\MyApp MyApp.exe

Auch First-Chance-Exceptions erfassen

procdump -accepteula -ma -n 3 -e 1 MyApp.exe C:\CrashDumps\MyApp

Einen Hänger erfassen

procdump -accepteula -h MyApp.exe C:\CrashDumps\MyApp

5.3. Warum -i nicht der erste Schritt sein sollte

ProcDump lässt sich auch mit -i als Postmortem-Debugger registrieren. Das ist mächtig, greift aber in das maschinenweite Verhalten im Absturzfall ein, weshalb es als allererster Schritt in der Einführungsphase etwas zu schwergewichtig ist.

Deshalb ist es einfacher, zunächst mit der anwendungsspezifischen WER-Konfiguration oder mit ProcDumps -w / -x / PID-Angabe zu beginnen.

6. Überlegungen zur eigenen Erfassung mit MiniDumpWriteDump

Die eigene Erfassung eignet sich zum Beispiel für folgende Situationen.

• Sie möchten in der UI eine Schaltfläche „Diagnoseinformationen speichern“ anbieten
• Sie möchten Logs, Einstellungen und Trace-IDs zusammen mit dem Abbild bündeln
• Sie möchten zugehörige Kind- oder Hilfsprozesse ebenfalls einbeziehen
• Sie möchten vor dem Hochladen eigene Maskierung oder Komprimierung anwenden

Die zentrale API hierfür ist MiniDumpWriteDump.

Allerdings hat das seine Tücken. Als Einsteiger sollten Sie besonders diese zwei Punkte nicht übersehen.

1. Rufen Sie sie nach Möglichkeit aus einem anderen Prozess als dem zu erfassenden auf
2. Behandeln Sie die DbgHelp-Familie als grundsätzlich single-threaded

7. Die Wahl zwischen Miniabbild, Vollständigem Abbild und Zwischengrößen

Hier zögern erfahrungsgemäß viele. Die folgende Tabelle zeigt, wie in der Praxis ausgewählt wird.

Die Empfehlung für Einsteiger ist recht einfach.

• Auf Entwicklungs- / Testrechnern vollständige Abbilder
• In Kundenumgebungen je nach Betriebsbedingungen zwischen Mini und Vollständig wählen
• Bei Verdacht auf Speicherbeschädigung, native DLLs, COM, P/Invoke oder Zustandsanomalien nach langem Dauerbetrieb eher zum vollständigen Abbild tendieren

7.1. Wie MiniPlus / benutzerdefiniert in der Praxis tatsächlich angegeben werden

Nur zur dritten Zeile der Tabelle ist die Angabe etwas schwer verständlich, daher hier eine Ergänzung.

Bei WER LocalDumps setzen Sie DumpType auf 0 (benutzerdefiniert) und tragen in CustomDumpFlags die Bitkombination von MINIDUMP_TYPE ein. CustomDumpFlags wird nur verwendet, wenn DumpType=0 ist; der Standardwert ist 0x00000121 (die Kombination aus MiniDumpWithDataSegs, MiniDumpWithUnloadedModules und MiniDumpWithProcessThreadData).

reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpType /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v CustomDumpFlags /t REG_DWORD /d 0x121 /f

Bei ProcDump ist -mp MiniPlus und -mc <Mask> benutzerdefiniert.

procdump -accepteula -mp -e MyApp.exe C:\CrashDumps\MyApp

MiniPlus ist trotz seines Namens inhaltlich recht nah am vollständigen Abbild. Laut Dokumentation umfasst es den gesamten privaten Speicher sowie sämtlichen les-/schreibbaren Image- und Mapped-Speicher, wobei nur der größte private Bereich über 512 MB ausgeschlossen wird, um die Größe zu begrenzen. Das Ergebnis lässt sich einordnen als „so detailliert wie ein vollständiges Abbild, aber nur 10 %–75 % dessen Größe“.

Es gibt jedoch zwei Vorbehalte.

• Bei CLR-Prozessen wird aufgrund technischer Debug-Einschränkungen auch bei -mp ein vollständiges Abbild (-ma) erfasst. Wer bei .NET-Anwendungen auf eine Größenreduzierung durch MiniPlus setzt, liegt in der Regel falsch
• Wenn das Motiv für eine kleinere Größe darin besteht, „das Risiko vertraulicher Daten zu verringern“, ist es naheliegender, statt MiniPlus über ein Miniabbild nachzudenken

8. Was betrieblich im Voraus zu klären ist

Bei der Abbilderfassung geht in der Praxis öfter im Betrieb etwas schief als bei der Implementierung. Hier sind die Punkte, die Sie vorab klären sollten.

8.1. Wie PDBs und Binärdateien aufbewahrt werden

Das ist das Wichtigste überhaupt.

• Die genaue Version der ausgelieferten EXE / DLL
• Die zu dieser Version passenden PDBs
• Welcher Commit / welche Build-Pipeline sie erstellt hat
• Versionsinformationen für Installer und Distributionsartefakte

8.2. Wohin ausgeben und wie viele behalten

Vollständige Abbilder werden ziemlich groß. Es ist sicherer, Ausgabeort und Aufbewahrungsrichtlinie von Anfang an festzulegen.

• Abbilder nicht direkt auf dem Systemlaufwerk liegen lassen
• In einen eigenen Ordner trennen
• Mit DumpCount oder -n eine Obergrenze setzen
• Langzeitarchivierung von der Erstaufnahme trennen

8.3. Wer Zugriff haben darf

Vollständige Abbilder können vertrauliche oder personenbezogene Informationen enthalten.

• Klartext-Konfigurationen
• Verbindungszeichenfolgen
• Tokens und Anmeldeinformationen
• Unmittelbar zuvor verarbeitete Geschäftsdaten
• Dateipfade und Benutzernamen

Deshalb müssen Sie gleichzeitig mit dem Design der Erfassung auch festlegen, wer darauf zugreifen darf.

9. Der kürzeste Weg zur Analyse nach der Erfassung

Nach der Erfassung eines Abbilds sind die ersten Schritte überraschend simpel.

9.1. WinDbg installieren

Das heutige WinDbg lässt sich bequem über den Microsoft Store oder mit winget installieren.

winget install Microsoft.WinDbg

9.2. Das Abbild öffnen

windbg -z C:\CrashDumps\MyApp\MyApp_YYMMDD_HHMMSS.dmp

Der hier verwendete Dateiname ist der von ProcDump vergebene Standardname. Der ProcDump-Standarddateiname lautet PROCESSNAME_YYMMDD_HHMMSS.dmp, wobei PROCESSNAME / PID / EXCEPTIONCODE / YYMMDD / HHMMSS als Platzhalter verwendet werden können.

WER LocalDumps hingegen erstellt Dateien mit einer anderen Namenskonvention als ProcDump. Da diese Namenskonvention in Microsoft Learn nicht dokumentiert ist, ist es zuverlässiger, den Ausgabeordner nach Änderungsdatum zu sortieren, statt nach einem vermuteten Namen zu suchen.

dir /o-d "C:\CrashDumps\MyApp\*.dmp"

Wenn DumpFolder nicht konfiguriert ist, lautet der Standardausgabeort %LOCALAPPDATA%\CrashDumps. Bei Diensten geht der Absturz jedoch in den Profilordner des jeweiligen Ausführungskontos. Bei einem System-Dienst ist das %WINDIR%\System32\Config\SystemProfile, bei Network Service / Local Service liegt es unter %WINDIR%\ServiceProfiles. Wenn Sie den Eindruck haben, „es wurde kein Abbild erzeugt“, sollten Sie zuerst hier nachsehen.

9.3. Symbole einrichten

Richten Sie zunächst die öffentlichen Symbole von Microsoft ein, und fügen Sie danach den Speicherort Ihrer eigenen PDBs hinzu.

.symfix C:\Symbols\Microsoft
.sympath+ C:\Symbols\MyApp
.reload

9.4. Zunächst die automatische Analyse betrachten

!analyze -v

Anschließend prüfen Sie der Reihe nach:

• Welcher Ausnahmecode vorliegt
• Was das Faulting Module ist
• Wie weit der eigene Code im Stack sichtbar ist
• Ob es außer dem Ausnahme-Thread verdächtige Wartezustände oder Blockierungen gibt

10. Häufige Fallstricke

10.1. Das Abbild wurde erfasst, aber es fehlen PDBs

Das kommt ziemlich häufig vor. Die Erfassung des Abbilds ist zwar erfolgreich, aber es fehlt das Material zum Lesen. Richten Sie das PDB-Aufbewahrungsdesign gleichzeitig mit der Erfassungskonfiguration ein.

10.2. Die ACL von DumpFolder wurde nicht geprüft

Bei Diensten oder Prozessen mit getrennten Berechtigungen geht hier häufig etwas ins Leere. Prüfen Sie zuerst, ob der Prozess wirklich schreiben kann. Auch Microsoft Learn weist darauf hin, dass Sie bei Verwendung eines anderen als des Standardpfads sicherstellen sollten, dass „die ACL dem abstürzenden Prozess das Schreiben erlaubt“.

Die aktuelle ACL lässt sich mit icacls anzeigen.

icacls C:\CrashDumps\MyApp

Fehlt das Schreibrecht, fügen Sie dem Ausführungskonto M (Ändern) hinzu. Da der Dump-Ordner auch für die darunterliegenden Dateien dieselben Rechte benötigt, versehen Sie sie mit (OI) und (CI), um die Vererbung zu aktivieren.

rem Beispiel: für einen unter Network Service laufenden Dienst
icacls C:\CrashDumps\MyApp /grant "NT AUTHORITY\NETWORK SERVICE:(OI)(CI)M"

(OI) vererbt das ACE an untergeordnete Dateien, (CI) an untergeordnete Ordner. Der Umfang der Vererbung bestimmt direkt, wer die Abbilder lesen kann, prüfen Sie also vor dem Setzen einmal, ob dies mit der in 8.3 festgelegten Richtlinie übereinstimmt.

10.3. Vollständige Abbilder dauerhaft auf das Systemlaufwerk der Produktionsmaschine schreiben

Das ist der Klassiker unter den Speicherplatz-Vorfällen. Richten Sie Aufbewahrungslimits und die Trennung des Ausgabeorts von Anfang an ein.

10.4. Versuchen, mit WER allein auch alle Hänger abzudecken

WER LocalDumps ist vor allem bei Abstürzen stark. Für Hänger und First-Chance-Exceptions ist ProcDump in manchen Fällen besser geeignet.

10.5. -e 1 dauerhaft aktiviert lassen und in einem Exception-Sturm ertrinken

First-Chance-Exceptions sind nützlich, treten aber ganz normal häufig auf. Realistisch ist: eine Anzahlbegrenzung setzen, nur kurzzeitig aktivieren und das Ziel eingrenzen.

11. Zusammenfassung

Absturzabbilder sind ein bemerkenswert starker Beobachtungspunkt für Störungen mit niedriger Reproduktionsrate. Besonders wenn bei einer Windows-Anwendung COM, P/Invoke, native DLLs oder Langzeitbetrieb eine Rolle spielen, lohnt es sich, von Anfang an festzulegen, „was im Absturzfall zurückbleibt“.

Die empfohlene Reihenfolge ist einfach.

1. Zuerst WER LocalDumps pro Anwendung einrichten
2. Bei Bedarf ProcDump hinzufügen
3. Wenn noch mehr Kontrolle gewünscht ist, MiniDumpWriteDump unter der Voraussetzung eines separaten Prozesses verwenden

Wer in dieser Reihenfolge vorgeht, liegt selten grob daneben.

12. Referenzen

• [Sammeln von Benutzermodusabbildern - Win32-Apps

  Microsoft Learn](https://learn.microsoft.com/de-de/windows/win32/wer/collecting-user-mode-dumps)

• [ProcDump v11.1 - Sysinternals

  Microsoft Learn](https://learn.microsoft.com/en-us/sysinternals/downloads/procdump)

• [MiniDumpWriteDump function (minidumpapiset.h) - Win32

  Microsoft Learn](https://learn.microsoft.com/en-us/windows/win32/api/minidumpapiset/nf-minidumpapiset-minidumpwritedump)

• [User-mode dump files - Windows drivers

  Microsoft Learn](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/user-mode-dump-files)

• [Analysieren einer Benutzermodusabbilddatei - Windows drivers

  Microsoft Learn](https://learn.microsoft.com/de-de/windows-hardware/drivers/debugger/analyzing-a-user-mode-dump-file)

• [Installieren des Windows-Debuggers - Windows drivers

  Microsoft Learn](https://learn.microsoft.com/de-de/windows-hardware/drivers/debugger/)

• [Symbol path for Windows debuggers - Windows drivers

  Microsoft Learn](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/symbol-path)

• [!analyze (WinDbg) - Windows drivers

  Microsoft Learn](https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/-analyze)

• [Troubleshoot processes by using Task Manager - Windows Server

  Microsoft Learn](https://learn.microsoft.com/en-us/troubleshoot/windows-server/support-tools/support-tools-task-manager)

• [Enabling Postmortem Debugging - Windows drivers

  Microsoft Learn](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/enabling-postmortem-debugging)

• [MINIDUMP_TYPE enumeration (minidumpapiset.h) - Win32

  Microsoft Learn](https://learn.microsoft.com/en-us/windows/win32/api/minidumpapiset/ne-minidumpapiset-minidump_type)

• [icacls - Windows commands

  Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/icacls)

• [NotMyFault - Sysinternals

  Microsoft Learn](https://learn.microsoft.com/en-us/sysinternals/downloads/notmyfault)

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.

Was ist ein Absturzabbild? Was kann man daraus erfahren?

Es ist der in einer Datei gespeicherte Prozesszustand zum Zeitpunkt des Absturzes — eine Momentaufnahme, vergleichbar mit einem Standbild vom Unfallort. Im Nachhinein lassen sich der Ausnahmecode, der abgestürzte Thread mit seinem Call Stack, die geladenen Module und, je nach einbezogener Speichermenge, sogar der Inhalt von Objekten auf dem Heap ermitteln. Andererseits fehlen häufig die Zeitleiste bis zu diesem Moment sowie der externe Zustand von Kommunikation oder Geräten, weshalb es in der Praxis üblich ist, das Abbild mit Logs und Heartbeats zu kombinieren.

Wo konfiguriert man WERs LocalDumps?

Die Konfiguration erfolgt in der Registrierung unter HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps. In der Praxis ist es einfacher, sich statt an einer globalen Konfiguration an anwendungsspezifischen Unterschlüsseln wie MyApp.exe zu orientieren. Die drei zuerst zu prüfenden Werte sind der Ausgabeort DumpFolder, die Aufbewahrungsanzahl DumpCount und der Typ DumpType — damit lässt sich nach einem Absturz ein Abbild lokal aufbewahren, ohne zusätzliche Tools zu verteilen.

Sollte man Miniabbilder oder vollständige Abbilder erfassen?

Als Faustregel gilt: auf Entwicklungs- und Testrechnern vollständige Abbilder (DumpType=2), in Kundenumgebungen je nach Speicherplatz und Vertraulichkeitsanforderungen ein Miniabbild (DumpType=1) oder ein vollständiges Abbild. Bei Verdacht auf Speicherbeschädigung, native DLLs, COM, P/Invoke oder Zustandsanomalien nach langem Dauerbetrieb ist das vollständige Abbild im Vorteil. Vollständige Abbilder sind allerdings groß und bergen das Risiko, dass vertrauliche Informationen wie Verbindungszeichenfolgen oder Tokens hineingeraten, weshalb Speicherort, Aufbewahrungsanzahl und Zugriffsrechte vorab festgelegt werden müssen.

Wann verwendet man ProcDump?

Da WER LocalDumps grundsätzlich auf Abstürze ausgerichtet ist, eignet sich ProcDump besonders, wenn Sie auch Hänger oder First-Chance-Exceptions sehen möchten, eine dauerhafte Registrierungseinstellung vermeiden wollen oder nur einen bereits laufenden Prozess überwachen möchten. Typische Optionen sind -ma für ein vollständiges Abbild, -e für die Erfassung bei unbehandelter Ausnahme, -h für die Hang-Erkennung und -w für das Warten auf den Start. Da -e 1, das auf First-Chance-Exceptions abzielt, leicht zu einer hohen Anzahl führt, ist es realistisch, es mit -n zu begrenzen und nur kurzzeitig und gezielt einzusetzen.

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.