Warum muss dll neu compiliert werden? Sonst Exception beim Aufruf.
-
Hallo *,
ich habe ein größeres Projekt auf Visual Studio 2005 übernommen. Es besteht auch vielen dlls und einer Aufruf-exe. Nachdem ich an der Exe etwas verändert hatte, bekam ich bei fast allen dll-Aufrufen Exceptions geworfen. Ich nahm daraufhin an, dass durch die Recompilierung der exe die Schnittstellen exe - dll nicht mehr zusammen passten und compilierte die dll ebenfalls. Nun läuft sie wieder...
Mein Problem ist jetzt: Jemand hat wohl irgendwann mal diese dll repariert, jedoch den SourceCode nicht im VCS hinterlegt, d.h. ich habe mir wieder alte Fehler eincompiliert. Die zu finden scheint mir fast aussichtslos, weil das Know-How für das angesteuerte Gerät gar nicht mehr vorhanden ist.
Also meine Frage: Woran könnte es liegen, dass erst nach einer Neucompilierung der dll die Funktion vorhanden ist, d.h. keine Exceptions mehr kommen? Liegt es an einer neuen IDE (Visual Studio 2005, das hatte ich allerdings vorher auch schon mal verwendet)? Kann es an neuer Hardware liegen (die ist ausgetauscht, evt. 64/32 bit Problem???)?
Bin für alle Ideen dankbar, Kernfrage für mich ist, warum gibt's mit neuer exe und alter dll Exceptions?
Danke,
Stephan
-
Was für Exceptions?
(ISO) C++ oder C++/CLI (.NET)?
-
Hmmm, da bin ich schon mal überfragt, woran sehe ich das?
Ich bekomme zwei Exceptions (nacheinander). Die erste sagt mir "Die Anweisung "xxx" verweist auf Speicher in "xxx". Der Vorgang "read" konnte nicht auf dem Speicher durchgeführt werden.".
Die zweite: "Die Ausnahme "unknown software exception" ("xxx") ist in der Anwendung an der Stelle "xxx" aufgetreten".
Wobei "xxx" jeweils 8-stellige Hexzahlen sind. Überschrift ist jeweils "Fehler in Anwendung"... Hilft das?Stephan
-
Also meine Frage: Woran könnte es liegen, dass erst nach einer Neucompilierung der dll die Funktion vorhanden ist, d.h. keine Exceptions mehr kommen?
Vermutlich hat sich im Interface (den Header-Files) was geändert.
z.B. könnten Strukturen die übergeben werden geändert worden sein.Ich denke ihr werdet kaum drum herum kommen das nichtmehr vorhandene Wissen über das zu steuernde Gerät wieder aufzubauen.
Oder mal Backups von alten Workstations durchsehen ob sich irgendwo ne Working-Copy mit den nicht committeten Änderungen findet.
U.a. aus dem Grund machen wir auch oft ein Backup von Rechnern wenn bei uns jmd. kündigt (bevor das Image frisch drübergespielt wird), und heben das Backup dann min. 1-2 Jahre auf.
-
Ja, an die Header und Strukturen hatte ich auch schon gedacht, aber m. E. hat sich tatsächlich seit der letzten Änderung nix daran getan. De facto wurde lediglich die Versionsnummer getauscht und eine ocx Komponente, die aber mit den betreffenden dlls gar nix zu tun hat. Und in den letzten Versionen wurde immer wieder die fertige dll verwendet. Es gibt sogar ein cvs, aber der Entwickler hat vor 10(?) Jahren aufgehört und im Nachgang nochmal etwas nachgebessert. Ich nehme an, er hat damals aufgrund des einfach Vorgehens einfach die fertige dll übermittelt.
Was sich allerdings tatsächlich geändert hat ist die Build-Umgebung, weil ich auf einen neuen Rechner umgestiegen bin. Und da hatte ich die Hoffnung evt. die Ursache finden und beseitigen zu können um doch die funktionierende Zeitbomben-dll zu verwenden...?
Stephan
-
Naja gut, andere Build Umgebung kann alles ändern, vor allem wenn in der DLL C++ Typen im Interface verwendet werden. Ganz speziell wenn STL Klassen mit im Spiel sind.
Du könntest versuchen die damalige Build Umgebung nachzustellen (ne VM bietet sich an, die könnt ihr dann wegsichern für's nächste mal).
-
Ok, das mit der VM habe ich jetzt schon gemacht.
Da ich VMWare eh für Testzwecke im Einsatz habe, war das kein großes Ding. Aber jetzt ans Eingemachte, wie kann ich jetzt vorgehen und herausfinden, wo das Problem liegt? Da fehlt mir der Ansatz, möglicherweise ist's ja nur eine Compileroptimierung die jetzt anders gesetzt ist, wie bekomme ich sowas raus?Stephan
-
Also den Compiler + Service Pack Version solltest du schon kennen, sonst wird es ziemlich .... "interessant"
Bzw. guck mal welche Runtime DLL die fragliche "DLL ohne (aktuellen) Source" verwendet.
