DLL aus einer DLL heraus laden geht nicht

[Der aus dem Westen ...]

Folgendes: Ich habe eine eigene DLL, die von einem Programm eingelesen wird. In dieser meinen DLL befindet sich unter anderem ein Funktionsaufruf von LoadLibraryA, den ich mit einem char*-Parameter, welcher der Name der einzuladenden DLL ist, aufrufe.

Das Einladen meiner eigenen DLL klappt hervorragend, und ich kann auch die Funktionen (mit GetProcAddress(HMODULE__*,LPCSTR)) rausfinden. Aber sobald ich die Funktion meiner DLL aufrufe, die LoadLibraryA aufruft und mir ein Handle zurückliefern soll (kann ich nicht direkt machen, in der Funktion wird noch allerlei anderes gemacht, welche ich unmöglich im Programm, welches meine DLL aufruft, implementieren kann), bekomme ich 0 zurück.

Ich habe genug physikalischen und virtuellen Speicher, und die DLL ist ganz sicher vorhanden - im selben Ordner wie meine DLL, die ja eingeladen wird. Aber das Handle, welches ich zurückbekomme, zeigt immer auf 0. GetLastError hat mir den Fehlercode 1114 - A dynamic link library (DLL) initialization routine failed zurückgeliefert.

Denkanstöße, was ich falsch gemacht haben könnte, sind willkommen. Ach ja, und hier der Code. Wie gesagt, die DLL ist da:

HMODULE DLLHandle=LoadLibraryA("API_MS_WIN_CORE_DEBUG_L1_1_0.DLL");
if(!DLLHandle)
    return NULL;

[Martin Richter]

Was hast Du mit der DLL denn bitte vor?
Was ist das für eine DLL?

Der error code sagt, dass die DLL im DllMan FALSE zurück gegeben hat, also von Dir nicht geladen werden will. Evtl. ist das eine DLL Du nurmit einem bestimmten Aktivierungskontext geladen werden darf... (Manifest)...

[Der aus dem Westen ...]

Martin Richter schrieb:

Was hast Du mit der DLL denn bitte vor?
Was ist das für eine DLL?

Eine Windows-DLL mit Debug-Funktionen. Die vier darin enthaltenen Funktionen sind:

DebugBreak
IsDebuggerPresent
OutputDebugStringA
OutputDebugStringW

Eigentlich ist es nur eine von vielen DLLs, die Windows-Funktionen entält. Aber ich muss diese manuell einladen, auslesen und wieder ausladen, anders geht es hier leider nicht (ziemlich schwierig zu erklären, selbst ich verstehe es manchmal nicht ganz).

Martin Richter schrieb:

Der error code sagt, dass die DLL im DllMan FALSE zurück gegeben hat, also von Dir nicht geladen werden will. Evtl. ist das eine DLL Du nurmit einem bestimmten Aktivierungskontext geladen werden darf... (Manifest)...

Jetzt wo du's sagst ... ich habe noch nie bei der Betrachtung der DLLs von Windows (die ich nacheinander einbinden will, aber wie gesagt, die Erklärung dauert ziemlich lange) eine Manifestsektion gesehen.

Jetzt habe ich allerdings keine Ahnung, wie ich der DLL ein Manifest zu fressen gebe ...

[Jochen Kalmbach]

Der aus dem Westen ... schrieb:

Martin Richter schrieb:

Was hast Du mit der DLL denn bitte vor?
Was ist das für eine DLL?

Eine Windows-DLL mit Debug-Funktionen. Die vier darin enthaltenen Funktionen sind:
DebugBreak
IsDebuggerPresent
OutputDebugStringA
OutputDebugStringW

Hä!?
Und warum verwendest Du diese Funktionen nicht direkt??? Warum lädst Du eine undokumentierte DLL?

[Der aus dem Westen ...]

Jochen Kalmbach schrieb:

Hä!?
Und warum verwendest Du diese Funktionen nicht direkt??? Warum lädst Du eine undokumentierte DLL?

Weil diese DLLs Funktionen beinhalten, die ich brauche.

[KN4CK3R]

wenn du nur die Funktionen
DebugBreak
IsDebuggerPresent
OutputDebugStringA
OutputDebugStringW

brauchst, dann rufe die doch einfach auf? Dazu brauchst du die DLL nicht extra einbinden, bzw. Windows macht es automatisch.

greetz KN4CK3R

[Der aus dem Westen ...]

KN4CK3R schrieb:

wenn du nur die Funktionen
DebugBreak
IsDebuggerPresent
OutputDebugStringA
OutputDebugStringW

brauchst, dann rufe die doch einfach auf? Dazu brauchst du die DLL nicht extra einbinden, bzw. Windows macht es automatisch.

greetz KN4CK3R

Wenn es so einfach wäre, würde ich es ja machen. Aber dummerweise ist es eben nicht so einfach.

Ich sage soviel: ich kann keine *.LIBs einbinden, um die DLLs dann zur Laufzeit einladen zu lassen, das geht bestimmter Gründe wegen nicht. Glaubt mir, das habe ich mir nicht ausgesucht, das ist einfach so. Und deshalb bin ich auf die Funktionen der Windows-API angewiesen, die mir eine DLL einladen und ein Handle zurückliefern.

[Der aus dem Westen ...]

Kleiner Edit:

Sagen wir einmal so, ich habe ein Programm, dessen Quellcode ich nicht besitze, aber in dem es mir "irgendwie" (und das "irgendwie" tut hier wirklich nichts zur Sache, aber Assembler ist es nicht) möglich ist, Maschinencodefunktionen aufzurufen. Und im Maschinencode befinden sich Verweise auf LoadLibrary, FreeLibrary, GetProcAddress usw.

Jetzt brauche ich weitere Funktionen, kann sie aber nicht einfach so (auf C/C++-Ebene) mit einer *.LIB einbinden - ich muss mich auf die Verweise von LoadLibrary & Co verlassen. Das klappt ganz gut, nur wenn die DLL nicht will ... und deshalb bin ich hier.

[Jochen Kalmbach]

Dann verwendet aber bitte die *offiziellen* Methoden!
Und das ist "LoadLibrary" mit "kernel32.dll" und dann GetProcAddress!

Siehe doku:
http://msdn.microsoft.com/en-us/library/ms680345(VS.85).aspx

[Der aus dem Westen ...]

Jochen Kalmbach schrieb:

Dann verwendet aber bitte die *offiziellen* Methoden!
Und das ist "LoadLibrary" mit "kernel32.dll" und dann GetProcAddress!

Siehe doku:
http://msdn.microsoft.com/en-us/library/ms680345(VS.85).aspx

Bitte sag nicht, dass Kernel32.DLL alle Funktionen kapselt ...

[Der aus dem Westen ...]

Im übrigen: auch die Kernel32.DLL funktioniert nicht ... ^^

[Martin Richter]

Machst Du etwa einen LoadLibrary aus einer DllMain heraus?
Das würde sich verbieten.

Ansonsten ist das linken zur Kernel32.dll ein Witz. Die ist nämlich immergeladen und im Prozess.
Ein GetModuleHandle sollte es also auch tun.

[Der aus dem Westen ...]

Martin Richter schrieb:

Machst Du etwa einen LoadLibrary aus einer DllMain heraus?
Das würde sich verbieten.

Nein, das ist eine eigenständige Funktion. Meine DLL wird eingeladen (LoadLibrary gibt mir ein Handle auf meine DLL zurück, ist also nicht NULL), die Funktionsadressen werden ermittelt, und erst dann wird die Funktion, die die Windows.DLL einlesen soll, aufgerufen. DllMain (oder DllEntryPoint?) wurde hier schon lange aufgerufen, und im übrigen dachte ich immer, dass diese Funktion automatisch zur DLL hinzugefügt wird.

Ich habe mir jetzt auch einmal die Kernel32.DLL unter einem Editor angeschaut. Kein Manifest ... das würde vielleicht erklären, warum LoadLibrary NULL zurücklifert. Denn mit anderen DLLs, die von mir erstellt wurden, gibt es keine Schwierigkeiten.

Martin Richter schrieb:

Ansonsten ist das linken zur Kernel32.dll ein Witz. Die ist nämlich immergeladen und im Prozess.
Ein GetModuleHandle sollte es also auch tun.

Das könnte tatsächlich helfen. Das Problem ist nur, dass ich nicht weiß, ob die Kernel32.DLL alle Funktionen, die ich brauche, enthält. Wie gesagt, ich habe sie mir mal angeschaut, und sie enthält ja diese Verweise auf Sub-DLLs, von denen scheinbar noch keiner was gehört hat. Und in diesen Sub-DLLs habe ich Funktionen gefunden, die ich noch nicht in der Kernel32.DLL finden konnte.

Werden diese Sub-DLLs automatisch auch eingeladen, wenn die Haupt-DLL Verweise besitzt, oder werden bloss die benötigten Funktionen eingeladen?

[Martin Richter]

Und warum linkst Du nicht einfach implizit. Warum der Umstand mit GetProcAddr?

[Der aus dem Westen ...]

Martin Richter schrieb:

Und warum linkst Du nicht einfach implizit. Warum der Umstand mit GetProcAddr?

Wie gesagt, es ist mir nicht möglicht, implizit einzubinden. Das GEHT mit den Möglichkeiten, die ich besitze, einfach nicht - es sei denn, ich arbeite mich wochenlang in Assembler ein.

Mein Problem ist, dass ich lediglich auf einzelne Funktionen des Maschinencodes eines Programms, dessen Quellcode ich nicht habe, zugreifen kann. Neue Funktionen könnte ich also entweder mit einem Assemblerstudium ODER mit dem Umweg über LoadLibrary, GetProcAddress usw. hinzufügen, und neue Funktionen brauche ich.

Das Projekt ist nicht pures C/C++, da spielen noch andere Sachen eine Rolle.

Zurück zu meiner Frage: wenn eine DLL Verweise auf Funktionen in anderen DLLs besitzt, wird dann lediglich der Code der Funktion oder die komplette DLL eingebunden?

Außerdem noch etwas: ist es möglich, die Kernel32.DLL von beispielsweise Windows 7 durch die Kernel32.DLL von Windows XP zu ersetzen? Wenn nicht (durch inkompatibilität, was weiß ich), gibt es eine Möglichkeit, die neuere, erweiterte DLL vor die DLL im Windows-Ordner zu linken?

[Martin Richter]

Für mich klingt das in keiner Weise mehr legal.
EOD für mich.

[Der aus dem Westen ...]

Martin Richter schrieb:

Für mich klingt das in keiner Weise mehr legal.
EOD für mich.

Tatsächlich ist es sehr legal, wird sogar durch eine Lizenz gedeckt. Solange es nicht kommerziell ist und ich dafür sorge, dass der Maschinencode gebraucht wird, ist und bleibt es legal, sonst hätte ich diesen Thread wohl kaum hier, sondern im Gully-Board oder sonst wo eröffnet ...

[Der aus dem Westen ...]

EDIT: Und ich verändere den Maschinencode nicht, ich rufe ihn auf. Aber ich will nicht zu viel verraten, sonst ... ach, ich weiß nicht. Jedenfalls ist es legal, sonst würde ich es nicht machen. Auch ich habe Prinzipien.

[lolorizationationat0r]

lol was soll da nicht legal sein?
Solange du nix verbreitest, darfst du mit deinen Bits im RAM/Flash machen, was du willst. EGAL WER was anderes sagt ZOMG!!!
Oder lasst ihr euch gerne pseudo-einschränken?

[Nick Unbekannt]

Vielleicht solltest du doch mal dein Problem näher erläutern. Soweit wie du du das bist jetzt geschildert hast, klingt das ganze nach übelsten Rumgehacke ohne wirklichen Sinn. Es ist problemlos möglich alle benötigten Funktionen in deinem Programm sauber zu kapseln und davon aus dann dein eigentliches Problem zu lösen.
Btw. ist es tatsächlich nicht legal oder von einer Lizenz gedeckt Teile von Windows ohne Erlaubnis zu verbreiten. Wobei ich noch weniger verstehe, warum du spezielle Windows-Funktionen benötigst?