GFlags festlegen zu erwischen heap-Beschädigung (mit Ausnahme der Seite Heap)?
Auf einer Produktionsstätte unserer Anwendung(*) stürzt regelmäßig ab, aber nicht reproduzierbar. Die Analyse der crash-dumps zeigt deutlich, dass es einen Haufen Korruption: Die Abstürze sind bei anderen Ort, aber immer Zugriffsverletzungen innerhalb kernel32!HeapFree/ntdll!RtlpLowFragHeapFree. Win Dbg !analyze -v auch Berichte zu einer heap-Beschädigung.
Was wir bisher ausprobiert haben, ist zum ausführen der Anwendung mit der GFlags option Seite Heap. Das problem ist, dass der Speicherbedarf der Seite Heap ist so, dass die Anwendung nicht mehr betreiben (schlagen virtual memory limit für die 32-bit-Prozess).
So, wir nicht verwenden, Seite Heap. Die anderen flags wäre nützlich, hinzufügen, so dass wir entweder
- Holen Sie sich ein crash an der Korruption Seite
- oder zumindest können Sie mehr info aus einem crash-dump, wird schließlich erzeugt, wenn wir Abstürzen in
HeapFree?
Sind wir derzeit erproben die Fahnen:
in der Hoffnung, dass der nächste crash dump enthält ein paar mehr Informationen, was falsch gelaufen ist.
Als ich diese Fahnen, aber ließ sich für jetzt:
- Aktivieren heap parameter überprüfen ... Ich würde erwarten, dass einiges an Aufwand, wenn das system prüft jedes mal, wenn ein heap-Funktion aufgerufen wird
- Kostenlose heap-überprüfung aktivieren ... nicht sicher, ob das tatsächlich kaufen würden Sie mir etwas
- Aktivieren der heap-überprüfung auf Abruf ... hier sind sogar die docs warnen vor den hohen Aufwand
Ein problem, das ich (auch) haben, ist, dass ich bin mir nicht sicher, wie diese Fahnen, die helfen, wenn eine Speicherbeschädigung auftreten. Seite Heap offensichtlich wird eine Zugriffsverletzung generiert, wenn Sie schreibt etwas in die guard-Seiten, aber wie gehen die anderen flags funktionieren?
Muss ich die app starte mit Application Verifier für diese anderen Flaggen, um zu helfen? Oder wird eine Ausnahme ausgelöst, wenn die überprüfung der code erkennt etwas?
Welche Kombination dieser flags macht am meisten Sinn, so dass die Anwendung weiterhin ausgeführt, mit OK performance-und memory-Verbrauch in der Produktion?
(*) : Es ist eine 32bit Windows-desktop-Anwendung in der industriellen Automatisierung. Läuft auf Win7 64bit in diesem Fall (der es einfach gut tut, an eine ganze Menge von anderen Seiten).
- Tatsächlich glaube ich, dass die
Page Heapoption würde Ihre beste Wette. Wenn Sie dies nicht bereits getan haben, könnten Sie versuchen, um Ihren Prozess large adress aware. Hoffentlich gibt Sie genug Speicher, um tatsächlich die Flagge.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Sie haben eine perfekte Benutzeroberfläche und Sie können spielen, um mit allen flags.
Wissen Sie, dass Sie kontrollieren können dies auf einer pro-Anwendung base auch mit gflags.
gflags.exe /ich Testapp.exe e0
Aber: Der beste Weg zu finden, solche Probleme vollständig mit der Debug-CRT... wenn es für Sie möglich ist. Also, wenn es eine chance gibt, verwenden Sie die Debug-Version in der Produktionsumgebung, tun Sie es.
Innerhalb der Debug-CRT Sie wieder eine Menge von flags, die Sie verwenden können, und legen....
"Seitenheap zu aktivieren" aus der gflags-GUI können voll Seite heap-überprüfung führen können, das problem, das Sie beschreiben. Die gflags-Befehl-Zeile gibt Ihnen mehr Kontrolle und ermöglicht es Ihnen, standard Seite heap-überprüfung, die verwendet weniger Speicher, aber ist weniger leistungsfähig. Die Befehlszeile bietet Ihnen auch die Möglichkeit zur Verwendung einer Mischung von standard-und full-mithilfe der /Größe /dlls und /Adresse Optionen.
Hier sind die Optionen aufgeführt, die in den debugger.chm-Hilfe-Datei: