LoadLibrary schlägt sporadisch fehl
-
@Pellaeon: Dann würde es aber immer haken und nicht sporadisch!
-
Martin Richter schrieb:
@Pellaeon: Dann würde es aber immer haken und nicht sporadisch!
hm stimmt, hätte den Post ganz lesen sollen und nicht nur überfliegen^^
Aber ich würd trotzdem mal nachschauen, was an "Fremd-DLLs" nachgezogen wird.
-
Sind es Deine DLL's. Dann würde mich mal interessieren was Du in Deinem DLL-Main drin hast. Kann es sein, dass es Speicherknapphat oder andere ressourcen sind?
-
Hallo connan
"was machst du damit es wieder Wochen läuft"
tja, recht seltsam, aber wir haben von einem IO Gerät die Registry exportiert und !!! vollständig auf ein NIO Gerät eingespielt, danach geht's wieder ne Weile ...
Gruss Frank
-
Die Software Konstruktion (eigene Software) ist wie folgt:
Haupprogramm -> dll_1 -> dll_2
dll_1 ist statisch gebunden, über das *.lib file.
dll_2 wir von dll_1 dynamisch (zur Laufzeit) mit LoadLibary geladen.Ich habe noch etwas geforscht und rausgefunden,
dass im DllMain kein LoadLibary ausgeführt oder initiert werden darf.dll_2 ruft im DllMain WSAStartup auf.
WSAStartup führt zum dynamischen Laden einer winsockX.dll.
Das funktioniert auch (wenn man den returns glauben kann)Im Moment tippe ich darauf das dies das Problem ist.
Ich bin dabei den Aufruf von WSAStartup heraus zu nehmen.
Auch das Sporadische kann ich damit erklären:
Das Programm wird mit mehreren Programmen (fast) gleichzeitig gestartet.
Je nach Timing führt WSAStartup zum vollstängien Laden der
winsockX.dll oder eben nur zum erneuten instanzieren.Mal sehen ob es das Problem ist,
ich kann es leider nicht bei mir reproduzieren
Gruss Frank
-
Frank Erdorf schrieb:
dll_2 ruft im DllMain WSAStartup auf.
WSAStartup führt zum dynamischen Laden einer winsockX.dll.Nun wundert mich nichts!
In DllMain darf man:
1. Kein LoadLibrary aufrufen
2. Keine anderen Funktionen starten, die andere DLLs laden
3. Keine anderen Funktionen außer den niederwertigen Kernel Funktionen ausführen.
4. Das schließt auch ein, dass keine DLL Funktionen aufgerufen werden die per Delayload gebunden sind!Siehe ausführlicher Thread hier:
http://groups.google.com/group/microsoft.public.de.vc/browse_thread/thread/f21bc077f3cb6c63Siehe auch MSDN Doku: Dllmain
http://msdn2.microsoft.com/en-us/library/ms682583.aspx
-
Schmeiss das WSAStartup ins Hauptprogramm oder DLL 1.
-
Hallo zusammen, das Problem ist gelöst:
1. WSAStartup ins Hauptprogramm
2. WSAStartup aus dem DllMain herausgenommen und später zur Laufzeit ausgeführt.
3. einfache Wiederholung von LoadLibary im Fehlerfall.Insgesamt bleibt die Sache verwunderlich, weil in meinem Fehlerfall:
Zwar das LoadLibary NULL liefert,
aber die dll geladen wurde, das DllMain angesprungen wurde und
sogar WSAStartup erfolgreich war.Das alles sieht eher nach einem BUG aus, der mehr oder weniger gut aus dokumentiert wurde.
Bei WSA Startup steht weder das es intern ein LoadLibary macht noch das es nicht ins DllMain gehört...
Und das Fehlerverhalten ist nicht deterministisch,
- ich würde ja verstehen wenn das 2. LoadLibary einen Fehler liefert ...Vielen Dank an alle, Gruss Frank
-
Naja, es wird in der Doku zu DllMain ja ausdrücklich davor gewarnt...
Calling imported functions other than those located in Kernel32.dll may result in problems that are difficult to diagnose. For example, calling User, Shell, and COM functions can cause access violation errors, because some functions in their DLLs call LoadLibrary to load other system components. Conversely, calling those functions during termination can cause access violation errors because the corresponding component may already have been unloaded or uninitialized.
Und da WSAStartup nunmal nicht in KERNEL32 sondern in WS2_32.DLL beheimatet ist...
Ist also kein BUG, bloss da MS auch weiss dass so viele Programmierer sich nicht an die Regeln halten, ham sie halt ihr Möglichstes getan damit es in den meisten Fällen "trotzdem funktioniert".
-
Gegen WSASTartup in DLLMain Spricht IMHO nichts. Das macht sogar MS in seinen MDAC Tools und bzgl. dazu gab es mal einen Bugfix (der aber mit dem Problem hier nichts zu tun hat).
Dein Problem ist (so ich Deine Schilderung verstanden habe), dass Du selbst LoadLibrary aus der ersten DLL aufrufst. Das ist das Problem! Denn in diesem Fall kann es sein, dass eine DllMain Routine der bereits geladenen DLLs noch nicht gelaufen ist!
