Kann man die Microsoft-Fehlerberichterstattung für eine einzelne App verhindern?

Question

Wir haben eine nicht verwaltete C++ - Anwendung, die APIs von Drittanbietern zum Lesen von CAD-Dateien verwendet. Bei bestimmten beschädigten CAD-Dateien stürzt die 3rd-Party-Bibliothek ab und bringt unsere EXE-Datei herunter. Aus diesem Grund ist unsere Hauptanwendung eine separate EXE und wird dadurch nicht vom Absturz betroffen. Wir haben jedoch ärgerliche Microsoft-Fehlerberichterstellungsdialoge.

Ich möchte das Microsoft Error Reporting systemweit nicht deaktivieren. Gibt es eine Möglichkeit, die Fehlerberichterstattung für eine einzelne Anwendung zu deaktivieren, so dass im Falle eines Absturzes das System ohne Fehlermeldung automatisch stürzt?

Answer 1

Ich bin überhaupt nicht sicher, aber vielleicht SetErrorMode oder SetThreadErrorMode wird für Sie arbeiten?

Answer 2

Unter Vista und höher kann die API-Funktion WerAddExcludedApplication verwendet werden, um eine angegebene ausführbare Anwendung von der Fehlerberichterstattung auszuschließen. Soweit mir bekannt ist, gibt es keine ähnliche Option für XP und andere ältere Betriebssystemversionen.

Da WER jedoch nur auf nicht behandelte Anwendungsausnahmen zugreifen wird, sollten Sie in der Lage sein, dies zu unterdrücken, indem Sie Ihrer EXE einen "Catch-All" -Ausnahmehandler hinzufügen. Für einige Ideen, wie das zu erreichen ist, siehe vectored exception handling.

Beachten Sie, dass alle unbehandelten Ausnahmen unterdrückt ist generell eine schlechte Idee (und wird zum Beispiel dazu führen, dass App Windows-Logo-Zertifizierung zum Scheitern verurteilt), so dass man diese Technik nicht wahllos verwenden sollte ...

Answer 3

Ja, es gibt etwas, was du tun kannst. Rufen Sie SetUnhandledExceptionFilter() in Ihrer main() -Methode auf, um einen Rückruf zu registrieren. Es wird aufgerufen, wenn sich niemand freiwillig mit der Ausnahme befasst, kurz bevor der Microsoft WER-Dialog angezeigt wird.

Eigentlich etwas in diesem Rückruf zu tun ist voller Probleme. Das Programm ist ausnahmslos mit etwas Schädlichem wie einer AccessViolation-Ausnahme gestorben. Was oft durch Heap-Korruption ausgelöst wird. Der Versuch, etwas wie das Anzeigen eines Meldungsfelds zu tun, um den Benutzer wissen zu lassen, ist mühsam, wenn der Heap Toast ist. Immer wieder lauert der Deadlock um die Ecke, bereit, das Programm ohne jegliche Diagnose zu sperren.

Die einzige sichere Sache ist, einen Hilfsprozess zu haben, der Ihren Hauptprozess schützt. Aktivieren Sie es, indem Sie in Ihrem Callback ein benanntes Ereignis signalisieren. Geben Sie ihm die Ausnahmeinfo, die er benötigt, mit einer Memory-Mapped-Datei. Der Helfer kann so ziemlich alles machen, was er will, wenn er das Ereignis signalisiert sieht. Einschließlich das Zeigen einer Nachricht, das Nehmen eines Minidumps. Und den Hauptprozess beenden.

Genau so funktioniert der Microsoft WerFault-Helfer.

Answer 4

Hans Passants Antwort über SetUnhandledExceptionFilter ist auf dem richtigen Weg. Er macht auch einige gute Punkte, wenn es darum geht, im Callback nicht zu viel zu tun, da sich verschiedene Teile des Prozesses in einem instabilen Zustand befinden könnten.

Von der Art und Weise, wie das Problem beschrieben wird, klingt es jedoch nicht so, als ob Sie etwas tun möchten, außer dass das System den normalen Crash-Dialog nicht aufruft. In diesem Fall ist es einfach und sollte sicher sein, unabhängig davon, welche Teile des Prozesses vom Absturz betroffen sein könnten.

eine Funktion so etwas wie dieses Fabrikat:

LONG WINAPI UnhandledExceptionCallback(PEXCEPTION_POINTERS pExceptPtrs) 
{ 
    if (IsDebuggerPresent()) 
     // Allow normal crash handling, which means the debugger will take over. 
     return EXCEPTION_CONTINUE_SEARCH; 
    else 
     // Say we've handled it, so that the standard crash dialog is inhibited. 
     return EXCEPTION_EXECUTE_HANDLER; 
} 

Und irgendwo in Ihrem Programm (wahrscheinlich so früh wie möglich) den Rückruf:

SetUnhandledExceptionFilter(UnhandledExceptionCallback); 

das tun sollten, was Sie wollen - erlauben eine beliebige Abstürze dieses bestimmten Programms, um still zu sterben.

Es gibt jedoch noch etwas zu beachten: Jedes Mal, wenn Sie Komponenten von Drittanbietern (DLLs, OCXs, etc.) einbringen, besteht die Gefahr, dass einer von ihnen auch SetUnhandledExceptionFilter aufruft und somit Ihren Callback durch ihren eigenen ersetzt . Ich bin einmal auf ein ActiveX-Steuerelement gestoßen, das bei der Instanziierung einen eigenen Rückruf festlegen würde. Und noch schlimmer, es ist nicht gelungen, den ursprünglichen Rückruf wiederherzustellen, als er zerstört wurde. Das schien ein Fehler in ihrem Code zu sein, aber ich musste trotzdem zusätzliche Schritte unternehmen, um sicherzustellen, dass mein gewünschter Callback zumindest wiederhergestellt wurde, nachdem er heruntergefahren wurde. Wenn Sie also feststellen, dass dies manchmal nicht für Sie funktioniert, selbst wenn Sie wissen, dass Sie den Rückruf richtig eingestellt haben, können Sie auf etwas Ähnliches stoßen.

Answer 5

Ich fand mich in genau dieser Situation während der Entwicklung einer Delphi-Anwendung. Ich habe festgestellt, dass ich zwei Dinge benötigt habe, um das Dialogfeld "App funktioniert nicht mehr" zuverlässig zu unterdrücken.

Der Aufruf SetErrorMode(SEM_NOGPFAULTERRORBOX); unterdrückt das Dialogfeld "App hat aufgehört zu arbeiten". Dann zeigt der Ausnahme-Handler von Delphi stattdessen ein Meldungsfeld mit einer Laufzeitfehlermeldung an.

Um den Exception-Handler von Delphi zu unterdrücken, rufe ich SetUnhandledExceptionFilter mit einem benutzerdefinierten Handler auf, der den Prozess durch Aufruf von Halt beendet.

So das Skelett für eine Delphi-Client-Anwendung, den Code anfällig für Abstürze läuft wird:

function HaltOnException(const ExceptionInfo: TExceptionPointers): Longint; stdcall; 
begin 
    Halt; 
    Result := 1; // Suppress compiler warning 
end; 

begin 
    SetErrorMode(SEM_NOGPFAULTERRORBOX); 
    SetUnhandledExceptionFilter(@HaltOnException); 
    try 
    DoSomethingThatMightCrash; 
    except 
    on E: Exception do 
     TellServerWeFailed(E.Message); 
    end; 
end.