3. Fehlerursache bei SW finden, die auf Fremd-PC zusammenbricht

Fehlerursache bei SW finden, die auf Fremd-PC zusammenbricht

  • E

    Hi,

    meine neuste C++-Software mit QT funktioniert bei vielen Benutzern hervorragend und schnell. Bei einigen jedoch zeigt die Software seltsame Erscheinungen. Beispielsweise wird mir berichtet, dass die Berechnungen zum Anlaufen 30 Sekunden dauern und Imports (aus Zwischenablage nebst Parsen) zum Zusammenbruch der Software führen. Auch wenn man schnell hintereinander Buttons drücken würde, würde die Software zusammenbrechen. Und das auf einem Rechner, der Windows7 x64 mit 4GB Arbeitsspeicher und einem AMD-Prozessor (einem neueren, der auch auf alle Fälle schnell genug sein sollte) ausgerüstet ist. Die Software ist auch auf einem Windows7 x64 Rechner kompiliert - jedoch für x86, aber meine Konfiguration ist ja quasi dieselbe (i7-Prozessor halt).

    Ich erfrage jetzt noch detailliertere Informationen, befürchte aber, dass ich das Problem nur schwierig nachvollziehen kann. Was, wenn die zu importierenden Daten aus der Zwischenablage bei mir hervorragend importiert werden?

    Ich bin etwas ratlos, wie ich da weiter vorgehen soll. 😞 Wie gesagt treten solche Probleme fast nie auf, bei mindestens 20 Leuten hat das bisher wunderbar funktioniert. Viele (inkl. mir) arbeiten regelmäßig mit der Software und haben solche Probleme nie erlebt. Protokolle könnten mir helfen festzustellen, wo genau eine Software zusammenbricht, die müssten aber sehr detailliert sein, wenn das zu schnelle Klicken von Buttons zum Abbruch führt. Ich vermute stark, dass ich den Fehler nicht bei mir reproduzieren können werden. Das ist wirklich frustrierend...

    Hat jemand Ideen? Die Frage ist super-offen, das ist mir klar, aber ich bin für alle Ideen und Vorschläge offen. Vielleicht habt ihr auch Erfahrungen, woran solche bei wenigen Nutzern auftretenden Probleme liegen könnten, was man ausprobieren könnte usw. usf.

    Vielen Dank für alle Ideen im Voraus!
    Viele Grüße,
    Eisflamme

    0
  • A

    Remote-Debugger dranhängen, Leute wild auf Buttons herumklicken lassen und auf Exception warten. Alternativ einen Crash-Reporter einbauen, der dir Stacktrace und Crashdump per Mail schickt.

    Gerade für die 30s ist ein Debugger das richtige Werkzeug. Einfach mal den Prozeß anhalten und schauen, wo es hängt. Mein persönlicher Lieblingsgrund ist, daß Windows den Standarddrucker nicht finden kann; sowas erzeugt in Office und anderer Software (z.B. wenn ein Programm RICHEDIT verwendet) reproduzierbar sekundenlange Wartezeiten bei unscheinbaren Aktionen (die aber offenbar die Abfrage von Systemmetriken bedingen) oder einfach nur beim Starten.

    Wenn das mit dem Debuggen nicht geht, kannst du vielleicht eine dieser Crash-Dump-Bibliotheken so zweckentfremden, daß sie in regelmäßigen Abständen einen Stacktrace aller relevanten Threads loggt.

    0
  • M

    Oder einfach Logs schreiben und dir zuschicken lassen.

    0

  • audacia schrieb:

    Wenn das mit dem Debuggen nicht geht, kannst du vielleicht eine dieser Crash-Dump-Bibliotheken so zweckentfremden, daß sie in regelmäßigen Abständen einen Stacktrace aller relevanten Threads loggt.

    Gibt sogar zumindest ein Tool das das "von extern" kann, also ohne dass man das Programm modifizieren muss. Weiss nimmer auswendig wie das Ding heisst, sollte sich aber in annehmbarer Zeit ergoogeln lassen.

    ----

    Voraussetzung um damit was anfangen zu können ist natürlich dass man die exakten Source-Files + PDB-Files noch hat mit dem das Ding gebaut wurde.

    0
  • E

    Fürs Remote-Debuggen muss aber auch die Debug-Version bei demjenigen sein und nicht die Release-Version, oder?

    Außerdvem sagt MSDN: (http://msdn.microsoft.com/de-de/library/vstudio/bt727f1t.aspx; Erforderliche Komponenten)

    Das Debuggen über das Internet wird nicht unterstützt.

    Crash-Reporter klingt auch gut. Da habe ich nur wirklich keine Ahnung, wie ich das einsetzen soll. Sobald meine Software zusammenbricht, ist sie ja futsch. Soll ich die SW über eine andere exe starten lassen? Und wenn ja, wie komme ich dann an Crash-Report? Habe ich noch nie gemacht.

    Ich kann mir aber auch vorstellen, dass der Benutzer mit "Crash" meint, dass die Anwendung einfach sehr lange für etwas braucht und nicht wieder unter die Lebenden kommt. Das ließe sich wohl in der Tat mit einem anständigen Logger herausfinden.

    0
  • _

    Eisflamme schrieb:

    Fürs Remote-Debuggen muss aber auch die Debug-Version bei demjenigen sein und nicht die Release-Version, oder?

    Nein, du brauchst dann eine Release-Version, die auch Debug-Informationen enthält.

    EDIT:

    Eisflamme schrieb:

    Außerdvem sagt MSDN: (http://msdn.microsoft.com/de-de/library/vstudio/bt727f1t.aspx; Erforderliche Komponenten)

    Das Debuggen über das Internet wird nicht unterstützt.

    Hm, das wusste ich gar nicht. War bei mir bislang auch nie nötig. Könnte man da eventuell mit einer VPN-Verbindung tricksen?

    0
  • A

    Eisflamme schrieb:

    Außerdvem sagt MSDN: (http://msdn.microsoft.com/de-de/library/vstudio/bt727f1t.aspx; Erforderliche Komponenten)

    Das Debuggen über das Internet wird nicht unterstützt.

    Wußte ich auch nicht. Vielleicht klappt es wie vorgeschlagen mit einem VPN.

    Eisflamme schrieb:

    Crash-Reporter klingt auch gut. Da habe ich nur wirklich keine Ahnung, wie ich das einsetzen soll. Sobald meine Software zusammenbricht, ist sie ja futsch. Soll ich die SW über eine andere exe starten lassen? Und wenn ja, wie komme ich dann an Crash-Report? Habe ich noch nie gemacht.

    Wenn du mit Visual C++ arbeitest, gibt es das hier:
    http://code.google.com/p/crashrpt/
    http://www.codeproject.com/Articles/379592/CrashRptEx-An-Extension-to-the-CrashRpt-Crash-Repo

    Eisflamme schrieb:

    Ich kann mir aber auch vorstellen, dass der Benutzer mit "Crash" meint, dass die Anwendung einfach sehr lange für etwas braucht und nicht wieder unter die Lebenden kommt. Das ließe sich wohl in der Tat mit einem anständigen Logger herausfinden.

    Und zumindest das Stack-Trace-Logging unabhängig von einem Crash kannst du mithilfe der dbghelp.dll selbst implementieren (PDBs vorausgesetzt):
    http://msdn.microsoft.com/en-us/library/windows/desktop/ms680650.aspx

    0
  • E

    Hi,

    ich habe nun CrashRpt eingesetzt und das hat mir bereits prima geholfen!

    Einmal jedoch ist jetzt ein Crash entsprungen, dessen Ursprung angeblich in der CrashRpt1401.dll liegt... logischerweise gab es da nichts zu debuggen und die Fehlerursache war "0x00000000: Der Vorgang wurde erfolgreich durchgeführt". Als Fehlertyp wurde mir angegeben "C++ new operator failed". Damit kann ich wohl nicht viel anfangen...

    Hoffe also, dass die Dumps nicht allzu häufig in den CrashRpt selbst laufen. 🙂

    Beste Grüße,
    Eisflamme

    0
Anmelden zum Antworten