4. C++ Exceptions verlassen nicht die DLL?

C++ Exceptions verlassen nicht die DLL?

  • A

    Martin Richter schrieb:

    Wenn bestimmte Exceptions innerhalb von SendMessage und einer Fenster Prozedur auftreten, dann werden die auch "gefressen". Das kann ich auch immer wieder beobachten.

    Mein erste Versuch eine Exception zu werfen, war bei einem WM_PAINT. Meine erste Vermutung war, das die ATL Messages vielleicht einen catch-Block haben o.ä. Konnte in den ATL Sourcen nichts finden.

    Deshalb hatte ich als Test auch probiert, eine Exception zu werfen, die nichts mit ATL zu tun hat:

    // Dummy Code in der EXE
int WinMain()
{
MyAtlWindow w; // DLL
w.show();

MyPlainClass c; // DLL
c.foo(); // hier drin wird eine exception geworfen!
         // First-Chance Exception, aber kein Unhandled Exception

while() { aufwändiger windows message loop kram }; 
}

    Da es auch so nichts bewirkt hat, hatte ich ATL bzw. CWindow-Messages ausgeschlossen.

    Ich könnte heute Abend probieren in meiner Solution die CWindow Erzeugung weg zu lassen. Und dann al schauen ob es funktioniert. Ich ahne es aber schon, das wahrscheinlich das ganze Window-Handling in der DLL daran schuld ist... 🙄

    0
  • Mod

    Das Exceptions in einem WM_PAINT Block "gefressen" werden ist ein bekanntes Problem, das zum Teil auch noch durch Bugs verschärft wird. (Siehe auch http://support.microsoft.com/kb/976038).

    Siehe auch Diskussion hier:
    http://stackoverflow.com/questions/1487950/access-violation-in-wm-paint-not-caught

    Aber dennoch ist mir unklar, was bei Dir passiert mit der "plain class". Irgendwie leuchtet mir das nicht ein und mir scheint ein weiterer Exception Handler zu existieren.

    Was sagt SetUnhandledExceptionFilter wenn Du es explizit auf NULL setzt? Ist einer gesetzt gewesen? Was passiert nun, wenn er nicht NULL war?

    0

  • @Martin Richter
    Weisst du ob diese "exceptions in callbacks werden gefressen" Geschichte mit SP1 behoben wurde (gibt ja nen Hotfix)?
    EDIT: OK, never mind, hab's selbst grad gefunden: ja, ist drinnen. => Sollte heute also kein Problem mehr sein.

    0
  • Mod

    Also ich habe gerade aktuell ein "ähnliches" Problem.

    Sieht aber "ganz anders" aus. Ich habe einen COM Server.
    Der wird angesprochen und mache "viele" Sachen (Fenster erzeugen, Daten umsetzen etc.).
    Jetzt habe ich den Fall, das ein bestimmter COM Zeiger im Server 0 ist. Dieser wird auch verwendet 😞 es kommt zu einer First Chance Exception im Debugger und das war es.

    Mein Exception Handler schreibt einen Minidump und crashed, aber der wird nicht angesprungen...

    Und ehrlich gesagt verstehe ich es auch nicht. Nachvollziehbar auf einem Win 8.1 und Win 7 Rechner. Beides 64bit. Anwednung ist 32bit.

    Exception tritt in der EXE auf und es sind gefühlte 1000 DLLs geladen.

    0

  • @Martin & Artchi
    Könnt ihr nen 64 Bit Build machen und/oder die 32 Bit EXE mal auf nem 32 bittigen Windows (selbe Version/SP-level wie das wo ihr sonst testet, nur halt 32 Bit) laufen lassen?

    Dann wüsste man zumindest mal ob es was mit dieser "64 Bit Windows frisst Exceptions" Geschichte zu tun hat.

    Was mir sonst noch einfällt ist die .NET Runtime. Aber wenn die geladen wäre hättet ihr das vermutlich erwähnt, und IIRC pfuscht die auch nur ins SEH Handling rein während irgendwo managed Code auf dem Callstack ist.

    ps:
    Oder vielleicht mal folgenden Code probieren (achtung, irgendwer hat die "==" in dem Listing gefressen):
    http://blog.kalmbachnet.de/?postid=75
    EDIT: Jochen hat die fehlenden "==" ersetzt und mir nen Link auf die neue, verbesserte Version geschickt:
    http://blog.kalmbach-software.de/2013/05/23/improvedpreventsetunhandledexceptionfilter/
    /EDIT
    und dann nen Breakpoint in MyDummySetUnhandledExceptionFilter reinsetzen.
    Und sich den Callstack von jedem angucken der das aufruft.

    ps2:
    Eigentlich müsste es reichen nen Breakpoint in SetUnhandledExceptionFilter zu setzen. Wobei ich die Syntax dafür immer wieder vergessen...

    0
  • A

    Ich habe jetzt mal den Build auf x64 umgestellt. Und tatsächlich kommt jetzt die Exception bis zur Exe durch und ich erhalte auch ein Unhandled Exception. Das nachträgliche abfangen mit catch funktioniert auch!

    Als weiteren Test habe ich mein Projekt wieder auf Win32 umgestellt, die ATL Windows _nicht_ instantiiert und wieder in einer Plain DLL Class eine Exception geworfen: Exception kommt durch!

    Wenn ich das richtig verstehe, machen die Fenster in einer Win32-DLL auf einem X64-Windows Probleme. Ohne Fenster kommen die Exceptions bei dieser Kombi durch.

    Den SetUnhandledExceptionFilter auf Null setzen, werde ich nachher ausprobieren.

    0
  • A

    Ich habe SetUnhandledExceptionFilter(NULL) gesetzt und ein ATL Fenster erstellt, und jetzt wird unter Win32 Build auch die Exception bis zur EXE durch geworfen! 👍

    Kann man raus finden, welcher Handler dort drin steckt, bevor ich ihn auf Null setze?

    0

  • Hm.
    Das ist irgendwie ... krass. Wir wissen also jetzt dass es etwas mit 32 Bit EXEn auf nem 64 bittigen Windows zu tun hat. Und irgendwie irgendwas mit Fenstern.

    Wobei ich nicht glaube dass es hier ein allgemeines Problem mit Fenstern gibt - sonst würden ja massig Windows Anwendungen nicht mehr funktionieren (bzw. deren Error-Handling). Die MFC z.B. verwendet ja auch Exceptions, und MFC Extension DLLs sind auch nicht gerade SO selten.

    Und ich frage mich jetzt ob das ganze überhaupt irgendwas mit DLLs zu tun hat. Kannst du das nochmal probieren? Also z.B. die Definition von "MyPlainClass" in die EXE verschieben - ohne weitere Änderungen? Ich kann mir nämlich grad nicht vorstellen wieso das was mit DLL vs nicht-DLL zu tun haben sollte. Wobei es natürlich möglich ist, der Exception Filter könnte ja gucken in welchem Modul die Exception aufgetreten ist, und unterschiedliche reagieren je nachdem ob es das Modul des EXE Files oder ein anderes Modul ist. Ich frage mich aber wieso er das tun sollte.

    Noch ein Versuch wäre: erzeug mal ein Fenster direkt mit WinAPI, also ohne ATL. Wäre interessant was dann passiert.

    0

  • Artchi schrieb:

    Kann man raus finden, welcher Handler dort drin steckt, bevor ich ihn auf Null setze?

    Du kannst nen Breakpoint in SetUnhandledExceptionFilter setzen.

    Müsste mit Debug->New Breakpoint->Break at Function...
    Function: {,,kernel32.dll}SetUnhandledExceptionFilter
    gehen.

    Siehe
    http://www.highprogrammer.com/alan/windev/visualstudio.html
    bzw.
    http://www.codeproject.com/Articles/518159/Even-More-Visual-Studio-Debugging-Tips-for-Nati

    Ich würde das, also SetUnhandledExceptionFilter(0) , auch nicht als Lösung ansehen. Sondern versuchen rauszufinden ob es nicht einen weniger krassen Workaround gibt.

    0
  • A

    Sehr mysteriös, habe alles wieder zurück genommen (auf Win32 Build zurück und SetUnhandledExceptionFilter entfernt). Die Exception schlägt weiterhin durch. OK, Clean Solution und Rebuild. Schlägt immer noch durch. 😮

    PC neu booten. Schlägt immer noch durch! 😡

    Gesamte Solution inkl. Configfiles per Sourcecode Management UNDO. Jetzt schlägt die Exception nicht mehr durch.

    OK, jetzt setze ich SetUnhandledExceptionFilter(NULL)... und die Exception schlägt wieder nicht durch. 😡 Am SetUnhandledExceptionFilter kann es also nicht liegen. Wahrscheinlich an der x64 Config alleine, obwohl ich vor dem Undo auf Win32 gestellt hatte.

    Für heute Nacht ist erst mal Schluss... werde Morgen nochmal ein paar Konstellationen ausprobieren.

    0

  • Artchi schrieb:

    Gesamte Solution inkl. Configfiles per Sourcecode Management UNDO. Jetzt schlägt die Exception nicht mehr durch.

    Waaah, hast du vorher nen Backup oder wenigstens ein Diff gemacht?

    0
  • Mod

    Reply auf eine frühere Frage:

    SetUnhandledExceptionFilter gibt Dir den alten Handler zurück...

    0
  • A

    hustbaer schrieb:

    Artchi schrieb:

    Gesamte Solution inkl. Configfiles per Sourcecode Management UNDO. Jetzt schlägt die Exception nicht mehr durch.

    Waaah, hast du vorher nen Backup oder wenigstens ein Diff gemacht?

    Bevor ich das Undo gemacht hatte, habe ich mit einem Diff geschaut was sich alles geändert hatte. Es waren nur die hier in meinen Posts genannte SetUnhandledExceptionFilter(NULL) und die x64 Config.
    Genau das hat mich verwundert...

    Kein Drama. Werde mich heute Abend nochmal dazu melden.

    0
  • A

    hustbaer schrieb:

    Noch ein Versuch wäre: erzeug mal ein Fenster direkt mit WinAPI, also ohne ATL. Wäre interessant was dann passiert.

    Habe ohne ATL ein Fenster in einer DLL erzeugt (Win32 Build). Exception kommt dann auch bis zur EXE durch.

    0
  • A

    Habe ein ATL Window in der Test-DLL erstellt. Exception fliegt bis zur EXE. 🙄

    Werde mal mein originales Problem-Projekt Schritt für Schritt zurück bauen. Schauen was da schhuld ist...

    0
  • A

    So langsam verzweifele ich. Vor dem Rückbau, habe ich nochmal das Verhalten nachgeprüft. Es wird jetzt die Exception durch geworfen, obwohl ich wieder den versionierten Stand habe.

    Seit dem letzten Wochenende ist mein PC durch die Windows Updates zwei Mal neu gebootet. Keine Ahnung ob jetzt in den Windows Updates was drin war, dass das Verhalten positiv beeinflusst oder ob vielleicht eine andere Konstellation das problematische Verhalten beeinflusst hat.

    Ich vermute, das irgend ein Prozess oder Status im System die Exception am durchlauf bis in die Exe verhinderte. Ich werde mir jetzt einen Testfall bauen, der immer wieder eine provozierte Exception in der Exe erwartet.

    Erstmal ist das Thema erledigt. Danke allen für ihre Zeit! 🙂

    0
Anmelden zum Antworten