Kritischer Fehler erkannt c0000374 - C++ - dll zurückgegeben Zeiger aus zugewiesenen Arbeitsspeicher auf C#

Ich habe eine c++ dll, die dienen einige Funktionen in meinen c# - Anwendung.
Hier versuche ich zu Lesen, laden Sie Sie in den Speicher und dann wieder einige Informationen, wie die Zeiger auf geladene Daten und die Anzahl der Speicherblöcke zu c#. Die Dll liest die Datei in den Speicher erfolgreich, doch auf die Rückkehr in das Hauptfenster der Anwendung, das Programm stürzt ab, wegen Heap-Beschädigung(Kritischer Fehler erkannt c0000374).

Der code ist ziemlich einfach und unkompliziert und ich habe getan, einige ähnliche Dinge, bevor Sie mit kein problem, Aber ich konnte nicht herausfinden, was das problem macht hier, ich habe versucht, Speicher mit "new, malloc und GlobalAlloc", aber auch nicht helfen. Codes sind wie folgt:

C++ MyDll:

typedef unsigned long         U32;

extern "C" __declspec(dllexport) int ReadFile(LPSTR Path, U32** DataPtr, U32* Count)
{
   FILE *fp;
   U32 *Data;
   CString tempStr(Path);
   long fSize;

   if(!(fp = fopen(tempStr, "rb"))) {
    return 0;
   }

   //Obtain File Size;
   fseek(fp, 0, SEEK_END);
   fSize =  ftell(fp);
   rewind(fp);

   Data = (U32 *)GlobalAlloc(0, fSize);
   if(Data == NULL) {
            fclose(fp);
            return -1;
    }

    //Copy file into the buffer.
        if(!(*Count = fread(Data, sizeof(U32), fSize / sizeof(U32), fp))) {
           fclose(fp);
           free(Data);
           return -2;
        }

   *DataPtr = (U32 *)Data;
       return 1;
}

C# - Anwendung:

        [DllImport(@"MyDll.dll", CallingConvention= CallingConvention.Cdecl)]
    private static extern int ReadFile([MarshalAs(UnmanagedType.LPStr)]string Path, out IntPtr dataPtr, out uint Count);

private void readDump(string Path)
{
    uint count = 0;
    IntPtr Data = new IntPtr();

   try{
       if(ReadFile(Path, out Data, out count) == 1) //The Program crashes just right after this statement
       {
           //Do Something ...
       }
    }
    catch() {}

}

Das Programm stürzt bei beiden debug und release Modus. Es sei denn, ich unterbreche das Programm im debug-Modus nach dem laden der Datei und rufen Sie ein paar Blöcke von Speicher in "Visual Studio Direktfenster".
Die Größe der Dateien, die geladen werden, sind etwa 64 MB und wir haben mehr als 2 GB ungenutzten ram auf dem PC.

UPDATE: habe ich festgestellt, dass einige Programme von Drittanbietern, die Sie vor der Arbeit, Absturz mit "Exception Code: c0000005", und einige andere seltsame Dinge passiert, unter Windows 7 (Host). also getestet habe ich den code in einer anderen installation von windows und alles scheint zu funktionieren, wie Sie sollten. Also wahrscheinlich hängt es mit den Windows-7. Nun, wie könnte ich das problem beheben? "sfc /scannow" konnte nicht finden jedes Problem.

fSize / 4 ist falsch, es wird nicht 4 sein, wenn Sie, sagen wir, GCC. Ich nehme an, dies geht bergab, weil man vergessen hat, die CallingConvention-Eigenschaft im [DllImport] - Attribut, es ist Cdecl. Es gibt gar keinen Punkt im code schreiben, wie das FileStream-tun es genauso gut.
Vielen Dank für dein Kommentar, ich habe "fSize / 4" bis "fSize/sizeof(U32)" und "[DllImport(PCIiDllAddress)]" , [DllImport(PCIiDllAddress, CallingConvention= CallingConvention.Cdecl)], aber problem besteht immer noch. Ich habe gute Gründe das zu tun, einige Arbeitsplätze, die in c++, (das ist nicht mein vollständiger code).
C++ hat nie viel Mühe verdirbt den Haufen. Ich denke das problem liegt im code, den wir nicht sehen können. Unit-test das heck aus dem code, bevor Sie versuchen, interop mit.
Alle code, den Sie hier sehen, Abstürze ohne Unterschied.
Ich habe versucht, frei const char*s. Seit fast einem Jahr habe ich gefunden free zu ignorieren konstanter Zeiger, so habe ich nicht vorsichtig mit der Verwendung free auf Speicher, der beiden gewesen sein könnte oder nicht konstant war. Aus irgendeinem Grund free ignoriert nicht länger die Konstante Zeiger sondern macht etwas seltsames mit Ihnen. Vielleicht versucht er es freigeben ausführbaren Bild, oder vielleicht war es absichtlich werfen der heap corruption Fehler (vielleicht ist es auch gedacht, irgendwas muss schief gelaufen sein, wenn jemand versuchen würde das löschen eines Zeigers von dieser Art).

InformationsquelleAutor 2i3r | 2014-05-05

Schreibe einen Kommentar