Unerklärlicher Speicherfresser

[peterbelow]

Zitat von TurboMagic:

Single steppen auf meinem PC (die anderen Tests waren gestern auf dem PC eines Kollegen) im Vergleich zu seinem PC ergibt, dass bei mir das DIsassembly an der LEA Stelle von GetMem einen JMP zeigt, bei ihm jedoch LEA.
Siehe screenshots.

Was passiert hier?
Was haben wir irgendwo während des Programmumbaus vermurkst, das uns den Speicher irgendwie ruiniert?

Wenn ihr den exakt gleichen Sourcecode auf zwei verschiedenen Rechnern kompiliert und dann solche Unterschiede im erzeugten Binärkode findet würde ich mal den Problemrechner sehr gründlich auf Malware prüfen. Vergleicht auch, was auf beiden Rechnern in der IDE als add-ons und sonstigen 3rd-party packages installiert ist.

Da die Diskrepanz in einem Kode-Segment auftritt kann es eigentlich kein einfacher memory overwrite zur Laufzeit sein, da Kode-Segmente ja dort read-only sind und daher ein Schreibversuch zu einer access violation führen müßte. Die Änderung muss also schon beim Kompilieren oder Linken der Anwendung erfolgen, aber halt nur auf deinem Rechner, nicht dem deines Kollegen. An den precompilierten dcus der RTL kann es nicht liegen, sonst würde der Fehler auch in deinem Testprogramm auftreten.

[Stevie]

Zitat von peterbelow:

Das Log sah eigentich völlig normal aus, keine ungewöhnlichen Allokationen und der erste Eintrag der medium block list passt auch zu deinem Record.

Keineswegs, man sieht, dass die ganzen 10 Byte allokationen nirgendwo zu finden, sind - der erste Block müsste mindestens 896 Allokationen aufweisen.

Zitat von TurboMagic:

Single steppen auf meinem PC (die anderen Tests waren gestern auf dem PC eines Kollegen) im Vergleich zu seinem PC ergibt, dass bei mir das DIsassembly an der LEA Stelle von GetMem einen JMP zeigt, bei ihm jedoch LEA.

Ein Jump direkt als erste Anweisung, sieht nach einem Codepatch/Hook aus - Code mal durchsuchen danach (z.b. nach $E8 oder anderen Repräsentationen des jmp opcodes gefolgt von 4 Byte für die Zieladdresse) - suchen nach WriteProcessMemory kann auch was zutage fördern. Ob man einen Databreakpoint auf ausführbaren Speicher setzen kann, weiß ich nicht, aber wäre auch eine Möglichkeit den Verursacher zu finden.