GFlags-Einstellung zum Auffangen von Heap-Fehlern (außer Page Heap)?

9

An einer Produktionsstätte stürzt unsere Anwendung (*) wiederholt, aber nicht reproduzierbar ab. Das Analysieren der Absturzabbilder zeigt deutlich, dass es sich um eine Heap-Beschädigung handelt: Die Abstürze befinden sich an einem anderen Ort, greifen jedoch immer auf Verletzungen innerhalb von kernel32!HeapFree / ntdll!RtlpLowFragHeapFree zu. Win Dbg !analyze -v meldet auch eine Heap-Beschädigung.

Bisher haben wir versucht, die Anwendung mit GFlags Option Page Heap . Das Problem besteht darin, dass der Arbeitsspeicher-Overhead von Page Heap so hoch ist, dass die Anwendung nicht mehr ausgeführt werden kann (Grenzwert des virtuellen Speichers für den 32-Bit-Prozess).

Also, können wir nicht Seite Heap verwenden. Welche anderen Flags wären nützlich, um sie hinzuzufügen so dass wir entweder

  • bekomme einen Absturz auf der Korruptionsseite
  • oder zumindest können mehr Informationen aus einem Absturzabbild abgerufen werden, das schließlich generiert wird, wenn wir in HeapFree ?
  • abstürzen

Wir probieren gerade die Flaggen aus:

in der Hoffnung, dass der nächste Crash-Dump etwas mehr Information darüber enthalten wird, was schief gelaufen ist.

Ich habe diese Flags berücksichtigt, habe sie aber vorerst weggelassen:

Ein Problem, das ich (auch) habe, ist, dass ich nicht sicher bin, wie diese Flags helfen, wenn eine Speicherbeschädigung auftritt. Page Heap wird offensichtlich eine Zugriffsverletzung erzeugen, wenn etwas in die Guard-Seiten schreibt, aber wie funktionieren die anderen Flags?

Muss ich die App mit Application Verifier für diese anderen Flags ausführen, um zu helfen? Oder wird eine Ausnahme ausgelöst, wenn der Prüfcode etwas entdeckt?

Welche Kombination dieser Flags ist am sinnvollsten, damit die Anwendung in der Produktion noch mit OK-Leistung und Speicherverbrauch ausgeführt werden kann?

(*): Es handelt sich um eine 32-Bit-Windows-Desktop-Anwendung in der industriellen Automatisierung. In diesem Fall läuft es auf Win7 64bit (was auf vielen anderen Seiten gut funktioniert).

    
Martin Ba 26.09.2013, 08:35
quelle

2 Antworten

1
  1. IMHO: Der einfachste Weg, all diese Prüfungen zu kontrollieren, ist der ApplicationVerifier. Du hast eine perfekte Benutzeroberfläche und kannst mit allen Flaggen spielen.
  2. Heap Free Checking ist eine gute Flagge ohne zu viel Aufwand. Wenn also ein Heap-Block schlecht modifiziert wird und der Block freigegeben wird, erhalten Sie einen Bruch in den Debugger. Wenn die Beschädigung in der Nähe der Zuweisung und Freigabe des Blocks auftritt, kann dies hilfreich sein.
  3. AFAIK "Heap-Parameter-Chechking" ist nur eine einfache "Heap-Validierung auf Abruf". Ich hatte nie Erfolg damit.
  4. Das Prüfen und Markieren von Heap-Tails ist einfach und schnell. Funktioniert manchmal für mich.

Sie wissen, dass Sie dies auf einer Anwendungsbasis auch mit gflags steuern können.

gflags.exe / i Testapp.exe e0

Aber: Der beste Weg, solche Probleme zu finden, ist die vollständige Verwendung der Debug-CRT ... wenn es für Sie möglich ist. Wenn Sie also die Debug-Version in der Produktionsumgebung verwenden können, tun Sie es. Im Debug-CRT hast du wieder viele Flags, die du verwenden und einstellen kannst ....

    
xMRi 26.09.2013, 13:28
quelle
6

"Seitenhäufung aktivieren" auf der grafischen Benutzeroberfläche von gflags ermöglicht die vollständige Überprüfung des Seitenspeichers, die das beschriebene Problem verursachen kann. Die gflags-Befehlszeile bietet Ihnen mehr Kontrolle und ermöglicht die Aktivierung der Standard -Seitenspeicherung, die zwar weniger Arbeitsspeicher benötigt, aber weniger leistungsstark ist. Die Befehlszeile bietet Ihnen auch die Möglichkeit, eine Mischung aus Standard und Voll zu verwenden, indem Sie die Optionen / size, / dlls und / address verwenden.

Hier sind die Optionen, die in der Hilfedatei debugger.chm aufgelistet sind:

%Vor%     
Marc Sherman 26.09.2013 13:19
quelle