loadlibrary problem

[Sauerkrautpoet]

ich habe eine anwendung die sich aus einem unterverzeichnis dll-dateien sucht und siese dynamisch lädt.
nun habe ich bei 2 dll´s das problem, dass ich sie nicht laden kann. alle anderen (um die 20 dlls) kann ich einwandfrei laden.
ich bekomme bei den 2 betroffenen bibliotheken jedes mal die fehlermeldung:
"EApplication Error: ein anwendungsobjekt kann nicht in einem shared object erzeugt werden."
das lustige an dem fehler ist die tatsache, dass alle projekte nach dem gleichen muster gestrickt sind. und nur bei 2en machts BÄNG.
der fehler tritt genau beim befehl:

Delphi-Quellcode:

        try

      dllid := LoadLibrary(PChar(filename));

    except
      MessageBox(0,'Beim Einlesen einer Bibliothek kam es zu einem Fehler!', '', MB_ICONQUESTION or MB_OK);
      result:=0;
    end;

frage nun: warum kann ich 20 dlls importieren aber 2 nicht.

kann es irgendwie am dllentrypoint liegen?

[mkinzler]

Wie sieht die Dll aus? Gibt es einen Unterschied zwichen den 2 und den restlichen?

[Sauerkrautpoet]

Zitat:

Zitat von mkinzler

Wie sieht die Dll aus? Gibt es einen Unterschied zwichen den 2 und den restlichen?

exakt nach dem gleichen muster gestrickte dll:
beinhaltet ne form und wird über ne function exportiert

[ste_ett]

Erzeugst du die Form vollkommen unabhänig vom Hauptprogramm oder benutzt du irgendwas aus dem Hauptprogramm?

[Luckie]

Windows API Funktionen werfen keine Exception, wenn sie fehlschlagen, sondern geben meist einen Fehlercode zurück, den man auswerten kann, um festzustellen, warum die Funktion fehlgeschlagen ist:

Delphi-Quellcode:

hLib := LoadLibrary(...);
if hLib = 0 then
begin
  s := SysErrorMessage(GetLastError());
  ShowMessage(s);
end;

[Sauerkrautpoet]

@ste_ett:
ich nutze nichts aus dem hauptprogramm, jedes form hat sein eigenes datenmodul auf das es zugreift.

@Luckie:
errormessage: "eine dll initialisierungsroutine ist fehlgeschlagen"

ich bin genauso schlau (oder auch nicht) wie vorher :(

[Muetze1]

Mit anderen Worten: Der Code im Initialization Teil bzw. zwischen Begin/End. in der DLL bzw. die Procedure die du in diesem Teil der DLLProc Variablen zugewiesen hast, gibt einen Fehler zurück.

Andere Möglichkeit: Die DLL benötigt eine statisch gelinkte andere DLL, welche sie nicht finden kann. Du kannst die statischen Abhängigkeiten von anderen DLL's einfach über das mitgelieferte TDump Tool von Borland rausfinden. Dieses findest du im Normalfall im BIN Ordner deiner Delphi Installation. Das Tool benötigt die DLL als Parameter und gibt dir die Informationen zu der DLL aus (z.b. in Datei umleiten zum lesen). Unter "Imports" werden alle von fremden DLLs statisch gelinkte Funktionen aufgelistet und in welcher DLL sie sein sollten.

[OldGrumpy]

Weitere Möglichkeit zum Anschauen der DLLs: Der Dependency Walker - ein manchmal wirklich unverzichtbares Tool :)

Der zeigt Dir dann auch gleich welche DLLs von wo aus angezogen werden, sehr nützlich bei Versionskonflikten. Listet ausserdem auch alle jeweils ex- und importierten Funktionen an.

[Sauerkrautpoet]

Zitat:

Zitat von Muetze1

...mitgelieferte TDump Tool von Borland rausfinden. ...

dafür habe ich bereits dependency walker..so richtig voran bringt mich das auch nicht, weil keine imports gefunden werden, nur meine 3 exports.

EDIT:
@oldgrumpy: danke für den tipp, das tool habe ich bereits ;)

[OldGrumpy]

Alternativ kannste mir eine der DLLs auch mal zugänglich machen, dann schau ich mal rein, wo das Ding auf die Nase fällt. Btw, GAR KEINE Imports? Das wäre aber doch schon etwas ungewöhnlich :) Unter w2k ist dem OS-Loader so ein Executable z.B. so suspekt dass das Laden verweigert wird :) (Genauer: In den Imports muss eine Systemkomponente auftauchen, ich bin mir gerade nicht sicher obs user32.dll oder kernel32.dll war, müsste ich mal nachschauen)

[Olli]

Zitat:

Zitat von OldGrumpy

Alternativ kannste mir eine der DLLs auch mal zugänglich machen, dann schau ich mal rein, wo das Ding auf die Nase fällt. Btw, GAR KEINE Imports? Das wäre aber doch schon etwas ungewöhnlich :) Unter w2k ist dem OS-Loader so ein Executable z.B. so suspekt dass das Laden verweigert wird :) (Genauer: In den Imports muss eine Systemkomponente auftauchen, ich bin mir gerade nicht sicher obs user32.dll oder kernel32.dll war, müsste ich mal nachschauen)

Kernel32! Die wird benötigt, weil Win32 eben "nur" eines der vielen Subsysteme ist. Unter NT/2K/XP/2K3/Vista geht es jedenfalls nicht, daß man eine Anwendung ohne Importe hat. Unter 9x/Me sollte es keine Probleme machen.

[OldGrumpy]

Das geht schon sehr gut, diverse Exe-Packer und -Crypter, usw. arbeiten z.B. nach dem Prinzip, die haben keine Importtable im PE-Image sondern generieren die zur Laufzeit dynamisch. Und ab XP aufwärts kann ich sehr wohl wieder eine Exe haben die gar keine statischen Imports hat... Nur bei W2K ist der Loader so penibel.

[Olli]

Zitat:

Zitat von OldGrumpy

Das geht schon sehr gut, diverse Exe-Packer und -Crypter, usw. arbeiten z.B. nach dem Prinzip, die haben keine Importtable im PE-Image sondern generieren die zur Laufzeit dynamisch. Und ab XP aufwärts kann ich sehr wohl wieder eine Exe haben die gar keine statischen Imports hat... Nur bei W2K ist der Loader so penibel.

Laufzeit und Loader sind aber unterschiedliche Dinge. Wie gesagt, komischerweise ging es bei mir bisher auf keinem NT-System. Kannst mir ja gern mal die EXE zukommen lassen - würde mir das gern mal mit Debugger, Disassembler usw. anschauen. Das Problem ist nämlich, daß Win32-Prozesse eine Initialisierung seitens des Loaders durchlaufen, die es notwendig macht, daß Kernel32 schon vor der Ausführung des Hauptthreads geladen sein muß.

[OldGrumpy]

Anbei die vermutlich kleinste Exe der Welt ;) Ohne Import der kernel32.dll - und unter W2k (SP4 getestet) geht sie nicht, weil der Loader "user32.dll" bei den Imports zwingend erwartet, das "user32" reicht nicht aus. Unter XP kein Problem :)

[Olli]

Zitat:

Zitat von OldGrumpy

Anbei die vermutlich kleinste Exe der Welt ;) Ohne Import der kernel32.dll - und unter W2k (SP4 getestet) geht sie nicht, weil der Loader "user32.dll" bei den Imports zwingend erwartet, das "user32" reicht nicht aus. Unter XP kein Problem :)

Da ging wohl was verloren, die DP schmeißt mich heute regelmäßig raus ...

Es mag die kleinste EXE-Datei sein, aber nicht die kleinste PE-Datei. Sie ist nämlich ohnehin ungültig - daß sie funzt hat sie wohl exakt dieser Eigenschaft zu verdanken.

[OldGrumpy]

Warum ist sie ungültig? Wäre sie das, müsste sie ja vom Loader abgelehnt werden ;)

[rd5pro]

In einer der beiden DLLs dürfe wohl unter USES... eine Unit auftauchen, die für das bLOCKierEN verantwortlich sein dürfte.

Roland

[Olli]

Zitat:

Zitat von OldGrumpy

Warum ist sie ungültig?

Schau dir die Datei in einem Hexeditor an und vergleich sie mit den PE-Spezifikationen.

Zitat:

Zitat von OldGrumpy

Wäre sie das, müsste sie ja vom Loader abgelehnt werden ;)

Sehr interessante Theorie. Nach dieser Theorie sind Sicherheitslücken in Software dann wohl Standardverhalten, welches der Softwaredesigner nur vergessen ht in die Spezifikation aufzunehmen. :|

Übrigens, der W2K-PE-Loader lädt solche Dateien generell nicht. Da du ja nun offensichtlich aus Deduktion Schlüsse ziehst, ist mein Schluß - nach Deduktion - daß der Loader die Datei ablehnt. :stupid:

[Sauerkrautpoet]

folgende strukturelle frage:

ich habe ein funktionsmodul und ein datenmodul welches in der defekten dll ist. das funktionsmodul benutzt (uses) das datenmodul. das ist der einzige unterschied zu allen anderen dlls (die haben nur datenmodule, da nicht so massig viele funktionen benötigt werden).
sieht dann ungefähr so aus:
DLL-Form >>funktionen>>daten
>>I/O-Form(Reports)>>Reportdaten
darf ich die abhängigkeiten der module nicht so sehr auftröseln? kann ich mir garnicht vorstellen...

ich bekomm noch nen mittelschweren anfall :(



@old-grumpy: hat sich was mit meinen gesendeten dateien was ergeben?

[Olli]

Ein wenig mehr Code (z.B. die "DllMain") könnte u.U. helfen das Problem zu identifizieren.

[Sauerkrautpoet]

fehler identifiziert:

im uses teil war QGRAPHICS eingebunden, diese verursachte den fehler...

thema gegessen!