Debuggen in DLL



  • Hallo,

    meine Firma hat vor einigen Jahren eine Library für eine Barcodeabhandlung käuflich erworben. Die dll haben wir in unserem Produkt über einen Verweis eingebunden und seither auch keine Probleme gehabt.

    Nun haben wir jedoch das Problem, dass merkwürdigerweise ein einziger PDF417 Barcode nicht dargestellt werden kann und das auch nur unter einer ganz bestimmten Konstellation.

    Um zu ermitteln, wie es dazu kommt, muss ich innerhalb der verwiesenen Quellen debuggen, was aber wohl nicht geht. Bei der Online-Recherche, wie ich das machen kann habe ich mehrere Hinweise gefunden, dass dazu sogenannte pdb Dateien vorhanden sein müssen?
    Problem ist ja aber, dass ich ausschließlich die DLL zur Verfügung habe.
    Habe ich da überhaupt ne Chance?



  • Falls native DLL:

    Mit Source Files und PDBs kannst du debuggen.
    Mit nur Source Files (und ohne PDB) kannst du evtl. die DLL neu bauen, und bekommst dann ein zu der neu gebauten DLL passendes PDB.

    Ohne Source Files kannst du es ziemlich vergessen. Da stimmt dann allein schon die Callstackanzeige nicht (weil der Debugger nicht erraten kann wie viel Daten vor der nächsten Rücksprungadresse auf dem Stack liegen), und du bekommst statt C(++) Source auch bloss ne Disassembly.

    => Kannst du ziemlich vergessen.

    Falls .NET DLL:

    Versuch mal mit einem Decompiler die DLL in ein compilierbares Projekt zu verwandeln.

    Allgemein:
    Es gibt fertige, freie, open source Barcode-Decoder Libraries. z.B. ZXing .Net. Wäre vielleicht ne Überlegung wert umzusteigen.



  • Falls .NET DLL:

    Versuch mal mit einem Decompiler die DLL in ein compilierbares Projekt zu verwandeln.

    da kannst .NET reflector nehmen:) wenn glück hast is der code nich obfuscated



  • .NET Reflector ist $$$.
    Ich verwende aktuell ILSpy, das ist gratis.



  • Stimmt, hatte ne uralt version das war ne trial version glaub ich!

    ILSpy.. danke fürn Tip:) 👍



  • ...ich nutze C# nur zur Erstellung einer GUI für ein eigentlich in C geschriebenes Programm, das ich in eine DLL gepackt habe.
    Wenn das Programm noch nicht so groß ist, kann ich alles, was in der C-DLL mit "printf" ausgegeben wird im Debugger sehen.
    Aber jetzt wo das Programm langsam etwas unübersichtlich groß wird, schmeißt mir der Debugger die Zeilen am Anfang weg.
    Ich weiß auch, dass man in einer DLL kein printf o.Ä. nutzen sollte und wenn das Programm fertig ist und die DLL geboxt wird, werde ich die auch alle über eine Compilerdiriktive rauswerfen. Aber für den Entwicklungsprozess mal eine Frage: Ist es möglich die Ausgaben der DLL in das C# Programm umzuleiten um sie dort z.B. in einer ListBox Zeile für Zeile auszugeben?

    Zur Umleitung von cout habe ich schon etwas gefunden. Aber meine DLL ist wirklich C (ohne ++). Ich denke, dass das so nicht funktionieren wird wie hier beschrieben:
    https://social.msdn.microsoft.com/Forums/en-US/729db35a-1508-48c9-a9f5-5724b515068b/redirection-of-stdout-and-stderr-from-a-dll?forum=vclanguage

    Außerdem ist die DLL schon ziemlich fortgeschritten und ich möchte sie ungern nochmal total umbauen. Den Vorschlag, dass C das in eine Datei schreibt und C# diese ausliest... finde ich etwas unästhetisch, würde aber zur Not dann auch gehen.

    Vielen Dank für Anregungen.
    Gruß, CJens



  • Wo wäre das Problem mit OutputDebugString bzw. System.Diagnostics.Debug.WriteLine ?



  • hustbaer schrieb:

    .NET Reflector ist $$$.

    Wie findest du ILSpy im Vergleich zu .NET Reflector? Ich habe mir für letzteres nämlich mal 'ne Lizenz geholt, weil die damalige Version von ILSpy immer so grottig lahm und buggy war.



  • Da Reflector $$$ ist hab ich den nicht probiert, kann daher nicht vergleichen.

    ILSpy ist mMn. schön flott. Buggy.... pfuh. Ja, sicher, wenn man die Liste an offenen Tickets durchgeht, da gibt's schon etliche Bugs.
    So Buggy dass man nicht damit arbeiten könnte ist es aber nicht. Also da crasht nicht dauernd was oder kommt totaler Unsinn raus.

    Wo ich dagegen kein gutes Gefühl hätte wäre wenn ich ne Assembly damit auseinandernehmen und wieder compilieren müsste, und mich dann blind darauf verlassen dass keine Fehler passiert sind.

    Zum gucken was in bestimmten Assemblies abgeht ist ILSpy aber sehr gut geeignet.



  • Vielen Dank für alle Tips.
    Da ich nicht ganz Bewandt mit dem Thema bin, hatte ich den Weg gewählt, die DLL über einen Decompiler auszulesen und habe die dann manuell kopiert und somit das Programm komplett neu gebaut. Dadurch kann ich nun fröhlich frei im Quellcode debuggen 🙂


Log in to reply