Hinweis: Ich bin nicht interessiert an der Deaktivierung von WER . Ich interessiere mich für Crash-Szenarien, in denen WER nicht gestartet wird, obwohl dies der Fall sein sollte und Windows "stumm" beendet eine App.
Unter Windows XP ist es ziemlich trivial, eine C- oder C ++ - Anwendung (im Benutzermodus) zu schreiben, die ihren eigenen Adressraum so durcheinander bringt, dass bei einer Zugriffsverletzung (oder einer anderen nicht behandelten Win32-Ausnahme) Windows XP beendet den Prozess einfach ohne den Benutzer zu informieren:
%Vor%Das Aufrufen der obigen Funktion in einem einfachen C ++ - Projekt (im Freigabemodus - achten Sie beim Testen auf diese Compileroptimierungen - und nicht unter dem Debugger) wird:
SetUnhandledExceptionFilter setzen.
Ich frage mich jetzt, ob - unter Windows 7 - der WER-Mechanismus so implementiert wurde, dass ich immer einen Fehlerdialog für einen Absturz [a] in meiner Anwendung oder ob es sogar in Windows 7 Prozessbeschädigungsszenarien gibt, die verhindern, dass der WER-Dialog auftaucht?
Ich füge ein bisschen von dem, was ich gelesen habe, hinzu:
In dem Buch Windows via C / C ++ (5. Ausgabe von Richter, Nasarre) sie beschreiben, was in einem "Fehlvorgang" passiert (S. 711):
- Ausnahmefilter.
- ...
- ...
- Kernel erkennt unbehandelte Ausnahme
- blockiert den ALPC-Anruf beim Wer-Service
- WER-Berichterstattung tritt ein.
- ...
Nun weisen sie darauf hin, dass Win7 das anders macht als Windows XP (um dieses Buch auf S. 710 zu zitieren:)
... Ab Windows Vista sendet die Funktion
UnhandledExceptionFilterkeinen Fehler mehr an die Server von MS. Stattdessen. Der Kernel erkennt, dass die Ausnahme nicht vom Benutzermodus-Thread behandelt wird (Schritt 4) ...
Das würde bedeuten, dass es gar keinen Weg gibt, damit ein Prozess "abstürzt" - in Vista und darüber - in einer Weise, die WER davon abhält, zu treten. Ich versuche es entweder bestätigen oder widerlegen.
[a]: Offensichtlich kann ein Prozess ohne jede Spur "getötet" werden, indem eine der verschiedenen Funktionen *exit oder terminate* aufgerufen wird. Die Frage ist, wenn Sie einen solchen Beendigungsgrund ausschließen können, (wie) ist es möglich, einen Benutzermodus-Prozess auf Win7 auf eine Weise "abzustürzen", die verhindern würde, dass der WER-Dialog angezeigt wird.
Ich habe mir meine Ausgabe von Windows Internals angeschaut, aber zu diesem Thema gibt es nicht viel zu sagen. In früheren Versionen fand die Windows-Fehlerberichterstattungsroutine im Kontext des abstürzenden Threads statt. Das bedeutet, wenn der Stapel verworfen wird (wie in Ihrem Beispiel), kann er möglicherweise nicht ausgeführt werden.
In Vista und später läuft es extern zum abstürzenden Thread. Außerdem ist der Kernel selbst dafür verantwortlich, WER zu informieren, wenn ein Prozess abstürzt (durch einen fortgeschrittenen lokalen Prozeduraufruf).
Laut Windows Internals beheben diese Änderungen das Problem des verschwindenden Prozesses. Ich kann nur ihr Wort dafür nehmen. Offensichtlich, wenn der WER-Dienst selbst beschädigt ist (oder gestoppt wurde), werden Sie immer noch stille Abstürze bekommen.
BEARBEITEN
Von Windows Internals, 5. Ausgabe, Seite 122:
Bis Windows Vista mussten alle [WER] -Operationen, die wir beschrieben haben, im Kontext des abstürzenden Threads stattfinden ... Bei bestimmten Arten von Abstürzen ... ist der unbehandelte Ausnahmefilter selbst abgestürzt. Dieser "stille Prozesstod" wurde nirgends protokolliert. ... Windows Vista und spätere Versionen haben den WER-Mechanismus verbessert, indem diese Arbeit extern vom abgestürzten Thread ausgeführt wurde, wenn der unbehandelte Ausnahmefilter selbst abstürzt.
Seite 124:
... alle Windows-Prozesse haben jetzt einen Fehlerport, der eigentlich ein vom WER-Service registriertes ALPC-Port-Objekt ist. Der Kernel ... verwendet diesen Port, um eine Nachricht an den WER-Dienst zu senden, der dann den Absturzvorgang analysiert. ... Das löst alle Probleme des stillen Prozesstodes ...
Sie wissen bereits, wie Sie einen Prozess abstürzen können, also antworte ich darauf, den WER-Dialog zu verbergen.
Weg, um den WER-Dialog seit Windows XP zu verstecken:
SEM_NOGPFAULTERRORBOX 0x0002 Das System zeigt das Dialogfeld Windows-Fehlerberichterstattung nicht an.
Beachten Sie, dass es auch andere Gründe für Fehlerdialoge gibt, die auch mit dieser Funktion deaktiviert werden können. Weitere Informationen finden Sie in der Dokumentation.
Zusätzlich seit Windows 7:
%Vor%Einige Programme und DLLs verwenden diese Funktionen, um Fehler vom Benutzer zu verbergen.
Tags und Links windows-7 visual-c++ winapi unhandled-exception windows-error-reporting