MiniDumpWriteDump funktioniert auf Win7, aber nicht bei Win XP
-
Du darfst nicht einfach die dbghelp.dll kopieren! und schon gar nicht in das system32-Verzeichnis!
Wenn, dann kopiere es ins gleiche Verzeichnis wie Deine EXE, dann sollte es in XP auch korrekt geladen werden.
Offiziell darfst Du die dbghelp.dll nur mitgeben, aus den "Debugging Tools for Windows". Dort ist ein "redist.txt" enthalten, wo Du auch die dbghelp.dll weitergeben darfst.
Von irgend einem System etwas zu kopieren halte ich für gefährlich...
-
Da hast du Recht.
Jetzt habe ich ein neues Problem...
Ich greife mit COM auf eine Funktion des Programms(für das das Dumpfile funktioniert) zu. Tritt jetzt in der Funktion ein Fehler(Speicherzugriff, etc...) auf, bekomme ich im aufrufenden Programm eine Fehlermeldung. Aber das Dumpfile wird nicht geschrieben, da ja das Programm als solches nicht abgestürtzt ist, sondern im COM Aufruf der Crash war. Das Programm läuft weiter und so wird auch kein Dump erzeugt.
Gibt's da eine Möglichkeit, damit das Dumpfile auch bei Abstürtzen in COM Aufrufen werzeugt wird?Mfg
-
Wenn nix abstürzt wird auch kein *Unhandled*-Exception Handler aufgerufen.
Im COM-Aufruf ist somit auch kein Crash, sondern max. eine Handled-Exception!
Wenn Du COM direkt verwendest, dann solltest Du eigentlich die Exception ganz normal mit "__try __except" behandlen können und dann auch passend einen "Dump" schreiben können.
Wenn jemand anders das "try-except" macht, dann ist das schwieriger... WER fängt denn die Exception ab???
-
Die COM Exceptions müssen nach "außen" gegeben werden, damit das aufrufende Programm merkt, dass es die Exception gegeben hat.
Wenn ich __try _catch um den Inhalt der COM Methode hinzufüge meldet der Compiler:
__try kann nicht in Funktionen verwendet werden, die eine Objektentladung benötigenAlso hab ich /EHsc ausgeschaltet, dann gibts keinen Fehler mehr.
Allerdings wird die Ausgabe im except Handler nicht ausgeführt...
-
Hatte ich von try catch geschrieben? Ich hatte von __try __except geschrieben...
Meine Fragen hast Du aber immer noch nicht beantwortet... eher noch mehr verwirrt...
-
Sorry, meinte natürlich __try _except.
Die Exceptions fängt "jemand anders" ab.
-
Warum willst Du es dann wissen, wenn sie jemand anders fängt? Frag doch den Hersteller der DLL!
-
Firewall schrieb:
Wenn ich __try _catch um den Inhalt der COM Methode hinzufüge meldet der Compiler:
__try kann nicht in Funktionen verwendet werden, die eine Objektentladung benötigenDann schieb eine Funktion dazwischen in der nur der __try/__except Block + Weiterleitung an "die eigentliche" Funktion drin ist.
-
Firewall schrieb:
Wenn ich __try _catch um den Inhalt der COM Methode hinzufüge meldet der Compiler:
__try kann nicht in Funktionen verwendet werden, die eine Objektentladung benötigenDann schieb eine Funktion dazwischen in der nur der __try/__except Block + Weiterleitung an "die eigentliche" Funktion drin ist.
ps: und dreh /EHa bzw. /EHac auf.
-
Falls Du die Exception dennoch "Abfangen" willst, so kannst Du versuchen einen eigenen Vectored-Exception-Handler zu installieren mit "CALL_FIRST".
Damit wird Dein Exception-Handler vor dem eigentlichen "__except" Block aufgerufen...
Siehe: AddVectoredExceptionHandler
http://msdn.microsoft.com/en-us/library/windows/desktop/ms679274Siehe: Using a Vectored Exception Handler
http://msdn.microsoft.com/en-us/library/windows/desktop/ms681411
