Wer ruft unser _purecall auf?



  • Wir haben hier nen reichlich seltsamen Fall. Wie sehen öfters Crashes wo ein Programm mit unseredll!_purecall wegsemmelt. _purecall in unserer DLL kommt dabei ganz normal aus der Visual Studio CRT, die halt einfach nur statisch in unseredll reingelinkt ist.

    Das komische dabei ist: der Aufruf kommt nicht aus unserer DLL sondern aus einer Windows DLL die vermutlich MSVCRT!_purecall aufruft (zumindest importiert sie MSVCRT!_purecall). MSVCRT!_purecall ruft dann RaiseException(STATUS_NOT_IMPLEMENTED, ...) auf - soweit so gut. Nur wo ich im Moment nicht weiterkomme ist: wie kommt MSVCRT!_purecall dann zu der _purecall Funktion in unserer DLL?

    Unsere DLL exportiert _purecall nicht. Unsere DLL enthält keine direkte Referenz zu _purecall (nur die üblichen indirekten die in die VTables reingeneriert werden). Die CRT Enthält was ich erkennen konnte auch keine Referenz auf _purecall, die implementiert das bloss damit es halt aus VTables referenziert werden kann.

    Ich poste das hier in der Hoffnung dass jmd. das Phänomen kennt bzw. irgendwas dazu weiss was ich nicht weiss. z.B. einen Weg wie man _purecall indirekt aufrufen kann. (Ausser natürlich wirklich einen "pure call" zu machen - was ich in dem Fall ausschliessen würde, weil unseredll!_purecall das erste und einzige unseredll Frame im Callstack von den Dumps ist.)



  • Lies mal die Antwort von "Len Holgate" in Where do “pure virtual function call” crashes come from?



  • @Th69 Danke, weiss ich alles. Ich sehe keinen Zusammenhang mit dem von mir beschriebenen Problem.
    Das Problem ist: irgendwer ruft "unsere" _purecall auf, der unsere _purecall gar nicht kennen sollte.

    Also unsere DLL wird in einen fremden Prozess geladen, der von unserer DLL gar nix weiss. Trotzdem bekommen wir von dem über Umwege über ein paar Windows-Standard DLLs einen Aufruf in die private, nicht exportierte _purecall Funktion unserer DLL.

    Der Callstack dieser Crashes ist auch nicht ungewöhnlich, da findet man genügend Beispiele im Internjetz - ist ein klassischer Fehler der gerne mit SharpDX D2D gemacht wird. Nur in den Beispielen findet man als Top-Frame in den Crashes immer sowas wie MSVCR120_CLR0400!purecall. In unserem Fall steht da aber UNSERE_DLL!purecall. Und ich checke nicht woher er das UNSERE_DLL!purecall bekommt, das dürfte er gar nicht kennen. Weil der Crash wie gesagt ja nicht aus unserer DLL kommt.


Anmelden zum Antworten