FreeLibrary vs implizite DLL entladen

Implementierte ich eine DLL einschließlich der DllMain () - entry-Funktion:-

BOOL APIENTRY DllMain( HMODULE hModule,
  DWORD  ul_reason_for_call,
  LPVOID lpReserved
  )
{
    case DLL_PROCESS_ATTACH:
    /* here im doing file memory mapped through CreateFileMapping() API 
       and using it through MapViewOfFile() API
       storing some data structure in the file mapped area */
    ...
    case DLL_THREAD_ATTACH:
    ...
    case DLL_THREAD_DETACH:
    ...
    case DLL_PROCESS_DETACH:
    /* Here unmapping first through UnmapViewOfFile() API
       then tries to access the stroed data structure which is illegal 
       as we have already closed the file mapping
       This is the buggy code. The order should be first access the mapped memory 
       region and then unmap it */
       cout <<" some message"<<endl;
    ...

}

Leider machte ich einen Fehler in DLL_PROCESS_DETACH Fall und den Zugriff auf illegale memorey (access violation).

Machte ich ein Beispielprogramm lädt die Bibliothek mit LoadLibrary () - Funktion, verwendet die Funktion Bibliothek und schließlich rufen Sie FreeLibrary() und zurück.

Wenn ich ausgeführt, dieses Programm, ich habe nicht bekommen irgendeine Fehlermeldung.
Aber wenn ich entfernen Sie FreeLibrary(), in diesem Fall die DLL_PROCESS_DETACH-Fall ausgeführt wird implizit und dieses mal gibt es Fehler-dialog-box zu erwähnen, dass es Zugriffsverletzung.

Warum Aufruf von FreeLibrary() unterdrücken diesen Fehler? ODER es intern diese Ausnahme behandelt?
Was ist der empfohlene Weg.

Update: ich habe die details für das ANFÜGEN und TRENNEN. Wahrscheinlich wird es helfen, warum bin ich nicht im klaren über das Verhalten beobachtet.
Mit FreeLibrary () - Aufruf, ich habe keine Fehlermeldung, aber die cout-Nachricht nicht angezeigt wurde. Es scheint abgestürzt zu, aber nicht bnotified.
Aber wenn ich entfernen Sie FreeLibrary(), in diesem Fall die DLL_PROCESS_DETACH-Fall ausgeführt wird implizit und gibt Zugriffsverletzung Dialogfeld.
Idealerweise im ersteren Fall als gut, es sollte den Fehler anzeigen. Also ich vermute, dass die FreeLibrary() unterdrückt diese access violation Fehler.

InformationsquelleAutor Adil | 2010-04-28

c++dll winapi

2

Auf der MSDN-Seite für DllMain ein Angebot hat, die helfen könnten zu erklären, was mit Ihnen geschieht.

Beim Umgang mit DLL_PROCESS_DETACH, eine DLL sollte Kostenlose Ressourcen wie heap-Speicher nur, wenn die DLL entladen wird dynamisch (die parameter lpReserved ist NULL). Wenn der Prozess beendet wird (die lpvReserved parameter ist nicht NULL) werden alle threads im Prozess, außer den aktuellen thread entweder bereits verlassen oder wurden explizit beendet durch Aufruf der Funktion ExitProcess, die möglicherweise verlassen einige Prozess-Ressourcen wie heaps in einem inkonsistenten Zustand. In diesem Fall ist es nicht sicher für die DLL zu bereinigen, die Ressourcen. Stattdessen wird die DLL sollte es dem Betriebssystem wieder die Erinnerung.

Also, wenn Sie den Aufruf von FreeLibrary es ist im wesentlichen ein sauberes Herunterfahren. Alles in einem gültigen Zustand noch. Alle threads die Dll erstellt werden, sind immer noch rund. Dessen Speicher ist immer noch rund.

Aber wenn Sie nur das Programm schließen (und nicht FreeLibrary aufrufen), dann ist es mehr wie ein not-shutdown (denken Sie abstürzt). Die Dll wird informiert, die von der OS eher als die app. Wenn diese die Folge eines Unfalls, dann in der Hoffnung der Speicher ist immer noch gültig, ist das nicht eine tolle Idee. Und der Stapel ist eh Weg.

Also meine Vermutung ist, Sie laufen in dieses problem, weil die nicht-befreiten Bibliotheken entladen sind anders.
- Was Sie sayign ist wahr, aber in meinem Fall noch nicht klar für mich. ich habe einige details für das ANFÜGEN und TRENNEN von Fall in die post. Bitte sehen, hoffe, es hilft, meine Zweifel. im TRENNEN der Fall der Fall-code wird ausgeführt, unabhängig davon, ob OS informiert die TRENNEN-Fall oder die Anwendung selbst. Die Sache ist illegal memory-Zugriff erfolgt in beiden situation.
- Ich sah nur in Ihre Veränderungen. Könnten Sie mir zeigen, welche Linie die Zugriffsverletzung tritt auf? Aber auch, wenn Sie mir zeigen, die Chancen sind, meine Antwort wird sein "Das Objekt, das Sie den Zugriff auf nicht mehr gültigen Speicher." (Offensichtlich...das ist es, was eine Zugriffsverletzung ist) 😀 ich lese einen tollen Beitrag über dieses eine Weile zurück: Es eingekocht um zu sparen, eine shadow-Kopie der Datei (wie eine Art wie Word der Fall ist). So, wenn Ihre app abstürzt oder der Strom ausfällt sind die Dinge nicht verloren gehen. Aber noch wichtiger ist, es lässt Sie einfach Abstürzen. Die Dinge werden anmutig von design. Hoffe, das hilft.
- Butmy Frage die noch immer unbeantwortet sind 🙂 es gibt keinen Unterschied in der code Ausführung, wie ich schon erwähnte habe ich unmap und dann versucht, auf die Datei zugeordnete Speicher, die illegal ist. im Falle von FreeLibrary(), die nächste Anweisung nach dem Zugriff auf den Speicher nicht ausgeführt wurde und im hintergrund Programm ausgeführt. in Fall der impliziten Aufruf von DETACH, Zugriffsverletzung-Fehler-dialog-box erscheint und dann erst wurde mir klar. Also mein Punkt, warum der gleiche dialog wurde nicht angezeigt, in FreeLibrary () - Aufruf. Man kann nicht sagen, dass auch nach der Abkopplung, der memory-access legal ist in diesem Fall 🙂
- Oh, Moment mal, anscheinend habe ich verpasst, dass ein Teil. Du meinst, es gibt eine Zugriffsverletzung in beiden Fällen. Aber es sagt nichts über die Zugriffsverletzung in der FreeLibrary Fall? Hrmm ich bin mir nicht sicher...das ist merkwürdig. Auch seltsam leise diese Zeile ignorieren und fortfahren. Ignorieren Sie die return-Fehler-code? Das würde Sinn machen, warum es ignoriert und geht weiter.
- Jetzt haben Sie es richtig 🙂 Aber nicht sicher, warum der access violation Fehler nicht aufgetaucht ist, im Falle von FreeLibrary () - Aufruf. Nein, ich bin nicht zu ignorieren return-code. "FreeLibrary" true " zurück in den buggy TRENNEN case code.
InformationsquelleAutor ProgramMax
0

Zur Zeit der Aufruf von FreeLibrary, andere Teile des Programms wurden alle kartiert in Ihren virtuellen Speicher. Wenn Ihre dll wurde automatisch freigegeben, nachdem andere Teile des Programms bereits heruntergefahren worden, dann weniger Teile des Programms wurden noch abgebildet in Ihren virtuellen Speicher.

Also an der Zeit, die Sie FreeLibrary aufgerufen, Ihre Fehler in der DLL_PROCESS_DETACH Fall wohl Speicher zugegriffen, die im Einsatz war, durch einen anderen Teil des Programms.
- Lässt vermuten, dass in DLL_PROCESS_DETACH ich habe den Speicher frei und dann Zugriff auf Sie. Also was Ihr sagt ist hier nicht der Fall.
- Vielleicht solltest du deinen post eigentlichen code, so dass wir nicht haben, zu erraten?
- Hinzufügen der vollständige Quellcode wird zu groß. ich habe einige details in der post. Bitte sehen, hoffe, es hilft, meine Zweifel.
InformationsquelleAutor Windows programmer

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.