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

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:

• Heap-Tagging aktivieren
• Überprüfung des Heap-Tail aktivieren

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:

• Überprüfung der Heap-Parameter aktivieren ... I würde ziemlich viel Overhead erwarten, wenn das System jedes Mal prüft, wenn eine Heap-Funktion
aufgerufen wird
• Heap-freie Überprüfung aktivieren ... nicht sicher, ob das mir wirklich etwas kaufen würde
• Aktivierung der Heap-Validierung bei Aufruf ... hier warnen sogar die Docs vor dem hohen Aufwand

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).}