When exiting Kleopatra and choosing to really quit Kleopatra the application does not cleanly quit but crashes. Since the effect -> Kleo is quit. Is the same for the user most users have not noticed this, but it is noticeable in the Event Viewer log. This error exists at least since 3.1.21, Gpg4win-4.0.0 I have not tested older versions. Prio high as my policy was the reproducable crashes should always have high priority, even if they are not noticable.
The initial analysis done by a User of Gpg4win is:
>
> Wenn man Kleopatra komplett schließt, also
> bei meiner englischen Lokalisierung auf Quit, dann kommt die Frage ob
> nur das Fenster minimiert werden, oder ob der Prozess komplett beendet
> werden soll.
>
> Wählt man letzteres, dann scheint es auch so als ob Kleopatra _sauber_
> beendet wurde - das Problem ist, dem ist aber nicht so, das habe ich
> direkt gemerkt als über dem Mauszeiger der bekannte Kreis erscheint
> ist, der in diesem Fall einen Absturz signalisiert hatte, und im
> Hintergrund der Handler für AppCrashes (keine Ahnung wie die PE-Datei
> genau heißt) schon lief.
>
> Folgende Informationen kann ich euch weiterleiten:
>
> 1.) Der Crash tritt immer an der selben Stelle im Code-Segment von
> libKF5ConfigWidgets.dll auf, hier ein Auszug des AppFault-Eintrages
> aus dem Event Viewer (Windows Logs -> Application):
>
> Faulting application name: kleopatra.exe, version: 3.1.22.0, time
> stamp: 0x00000000
> Faulting module name: libKF5ConfigWidgets.dll, version: 0.0.0.0, time
> stamp: 0x00000000
> Exception code: 0xc0000005
> Fault offset: 0x00034ef0
> Faulting process id: 0x1208
>
> Der Exception Code ist nur allzu bekannt, Access Violation, also eine
> Zugriffsverletzung - oh wie klingt das widerlich im Deutschen (nun
> gut, ich spreche und denke 95% der Zeit nur noch in Englisch, obwohl
> ich in Deutschland geboren wurde.. das verändert einen schon recht
> deutlich)
>
> Aus Lust und Laune habe ich die betroffene DLL mal in IDA geladen, da
> ASLR hier scheinbar nicht richtig funktioniert habt, entweder weil Ihr
> per API die Mitigations komplett deaktiviert (aus welchem Grund auch
> immer), oder wegen einem isoliertem Problem auf meinem System, ist ja
> auch egal - die Adresse, an der die Exception auftritt bleibt die
> selbe - 0x00034ef0.
>
> Also, die Bibliothek in IDA geladen, und zu der Adresse navigiert, wo
> der Code eine Access Violation auslöst:
>
> Siehe da, es handelt sich um den Export mit dem Ordinal 483, eine
> Funktion namens
> "_ZN28QExplicitlySharedDataPointerI13KSharedConfigED1Ev", die C++
> Compiler Namensdekoration des Funktionsnamens habe ich nicht entfernt,
> aber Ihr solltet mit all den Informationen die Funktion sehr einfach
> finden können.
>
> An der Adresse 0x00034ef0 finden wir auch ganz zufällig folgenden
> Assembler Code:
>
> .text:00034EF0 8B 01 mov eax, [ecx]
>
> Da es sich um eine Funktion mit der Aufrufkonvention __fastcall
> handelt, handelt es sich hier bei dem Register ecx um Argument #1 der
> Funktion, die eckigen Klammern [] bedeuten dass hier ein Pointer
> dereferenziert wird - wahrscheinlich ein Nullpointer oder eine Adresse
> die auf einen invaliden Speicherbereich zeigt, so dass der Kernel bzw.
> die CPU hier eine Exception / Ausnahme wirft.
>
> "Live debuggt" habe ich das ganze nicht, aber ein Großteil der Arbeit
> habe ich ja schon für euch getan.
>
> Jetzt muss nur noch rausgefunden werden, warum ein ein falsches
> Argument übergeben wird.
>
> Noch etwas: IDA ist nicht immer korrekt mit den Schätzungen der
> Calling Convention, es könnte also auch __thiscall, also eine
> virtuelle Funktion einer C++ Klasse sein, dann wäre das ecx-Register
> _IMMER_ ein Zeiger auf die zugehörige Klasse - warum dieser ein
> nullptr oder ähnliches sein sollte, kann ich mir beim besten Willen
> nicht erklären - da müsste schon arg viel aus dem Ruder laufen.
>
> Ich hoffe meine Informationen konnten euch erst einmal in die richtige
> Richtung leiten, wenn Ihr mehr Informationen braucht oder Ihr den
> Fehler nicht reproduzieren könnt, dann meldet euch unter dieser E-Mail
> Adresse.
>
> Ich habe das Problem lokal erst einmal gefixt, in dem ich die Funktion
> einfach mit 0x90 Instruktionen überschrieben habe - also NOOP / do
> nothing - die Funktion hatte, mit dem Absturz, ja eh keinen Nutzen.
{F3556140}