Was diese Hex-Strings sind, die ich auf Call-Stack sehe in Visual Studio

Question

ich diesen Hexstring sehen, die auf jede dll in dem Call-Stack von Visual Studio zu gehören scheinen nicht:

000000001665b7e0() 
0000000000000935() 
0000094500000001() 
000000001665b9a4() 

Normalerweise würde ich sehen etwas wie:

libabc.dll!myclass:myfunction() Line76 

Was bedeuten sie und wie mache ich ihnen eine Bedeutung?

Answer 1

Das sind in der Tat Funktionen, aber niemand hat "Brotkrumen" verlassen, die Ihr Debugger verwenden kann, um diese Adressen in einen Funktionsnamen zu übersetzen.

In diesem Fall befindet sich das Mapping zwischen 000000001665b7e0 und einem Funktionsnamen entweder in einer Symboldatei, die Sie nicht haben, einer Symboldatei, die Ihr Debugger nicht kennt, einer Symboldatei, die Ihr Debugger nicht lesen kann Zuordnung existiert nicht.

Was können Sie dagegen tun?

Finden Sie die Symbolinformationen für diese Funktion und zeigen Sie Ihr Entwicklungssystem darauf oder ignorieren Sie, dass Sie diese Informationen nicht haben.

Die erste ist schwierig, weil Sie keine Ahnung haben, was die Funktion ist. Möglicherweise müssen Sie einen Shotgun-Ansatz verwenden, alle Bibliotheken hinzufügen, aber Sie können den Umfang der Suche reduzieren, wenn Sie wissen, welche Bibliotheken Ihr Programm verwendet.

Letzteres ist eine praktikable Option, denn wenn Sie keinen Zugriff auf die Debugging-Informationen haben, sind die Chancen ziemlich gut, dass Sie nichts über Fehler machen können, die von jemandem gemacht werden, der den Code geschrieben hat. Vielleicht kannst du ihnen eine böse E-Mail schreiben. Für eine etablierte Bibliothek ist es wahrscheinlicher, dass kein Fehler in der Bibliothek vorhanden ist und Ihr Programm die Bibliothek falsch verwendet. Überprüfen Sie die Bibliotheksdokumentation und debuggen Sie zuerst Ihren Code. Wenn Sie die Möglichkeit von Fehlern an Ihrem Ende beseitigt haben, dann fangen Sie an, den Code von Drittanbietern zu untersuchen. Bei einer etablierten Bibliothek gibt es oft einen Kern von Entwicklern, der helfen kann, einen Bibliotheksfehler zu bestätigen und zu lösen.

Warum dies geschieht:

Der Computer kümmert sich nicht darum, was die Leute Dinge nennen. Der Computer kümmert sich nur darum, wo die Dinge im Speicher sind. Um also die kleinste Ausgabedatei zu ermöglichen, bauen die Entwicklungssysteme (AKA "IDE", "Compiler" und "Werkzeugkette" mit unterschiedlicher Genauigkeit) Werkzeuge auf, die normalerweise alle ausreißen das Zeug, das nicht notwendig ist, um das Programm zu starten. Die netten, menschenlesbaren Namen, die vernünftige Programmierer geben, geben Funktionen, Variablen, Klassen und was hast du als eines der ersten Dinge, die es zu tun gibt.

Das Entwicklungssystem ermöglicht Ihnen normalerweise, diese Adresssymbolzuordnung beizubehalten, um das Debuggen zu vereinfachen. Wie Sie gesehen haben, sind rohe Hex-Zahlen nicht sehr nützlich, wenn man sie nicht mit erkennbaren Begriffen abgleichen kann, um nach Dokumentation zu suchen. Abhängig vom Build-System kann diese Information in der ausführbaren Datei oder der Bibliothek verbleiben (was zu einer viel größeren Ausgabedatei führt) oder sie kann als optionale Symbolinformationsdatei auf der Seite erscheinen. Diese Zuordnungsdateien sind oft spezifisch für das Entwicklungssystem und nicht von anderen Entwicklungssystemen lesbar.