VS Tipps & Tricks: Heap Bugs finden (Teil 2)

Einige Hilfsmittel um einen Heap-Fehler zu finden habe ich in meinem letzten Beitrag ja beschrieben.

Eigentlich wünscht sich der Entwickler nichts mehr, als dass ein falscher Zugriff auf den Heap, sofort einen Break im Debugger auslöst. Die Methoden, die ich bisher gezeigt habe (AfxCheckMemory, _CrtCheckMemory, _CrtSetDbgFlag) können das nicht direkt , aber zumindest helfen sie den Fehler einzukreisen.

Ein unverzichtbarer Helfer, der sofort solch einen Break auslösen kann, ist der Application Verifier, den ich bereits in einem älteren Artikel als Freund und Helfer vorgestellt habe.

Seit Visual Studio 2005 kann man direkt Parameter für den Application Verifier im Projekt einstellen und auch direkt den Debug-Prozess mit dem Application Verifier starten (Umschalt+Alt+F5).
An den Standardeinstellungen im Projekt braucht man hier gar nichts zu ändern:
Conserve Memory – No
Protection Location – Je nach Testfall (man sollte mit beiden Einstellungen mal debuggen)
Alle anderen Einstellungen Verification Layers Settings – auf Enable

Mit dem Application Verifier lässt sich der so genannte Paged Heap nutzen, der Guard Pages anlegt hinter oder vor den allokierten Speicherbereichen (siehe auch GFLAGS.EXE). Der Vorteil: Man erhält sofort eine Access Violation, wenn man den Speicherbereich überschreitet.

Mein kleines Demoproramm

#include <windows.h>
#include <tchar.h>
#include <crtdbg.h>
int _tmain(int argc, _TCHAR* argv[])
{
  char *pCorrupt = new char[100];
  ZeroMemory(pCorrupt,106); // -- This will corrupt the heap
  char *pOther = new char[100];
  ZeroMemory(pOther,100);
  delete [] pOther;
  delete [] pCorrupt;
  return 0;
}

crashed mit der Nutzung des Application Verifiers sofort und man kann im Call Stack die Zeile 7 ausmachen.
Genial ist besonders, dass der Application Verifier auch mit der Release Version sofort die Zeile 7 als Ursache identifiziert. Gerade wenn man also nicht auf die Debug-CRT zurückgreifen kann, ist der Application Verifier ein super Hilfsmittel.

Der Nachteil: Die Guard Pages liegen nicht exakt und direkt hinter dem allokierten Bereich, sondern auf der nächsten Page Boundary. Deshalb crashed mein Sample auch nicht wenn man den Speicher um nur 1 Byte überschreitet.

Aber der Application Verifier ist zum Testen ein absolutes Muss, weil auch falsche Handles erkannt werden und auch der Lock Verfification Layer für die Qualitätssicherung einfach nützlich zum entwanzen sind. (siehe auch Application Verifier Einstellungen in der MSDN).

Hinweis ❗

Auf Windows XP und Windows Server 2003 erhält man ohne administrative Rechte die folgende Fehlermeldung:

Access denied. You need administrative credentials to use Application Verifier on image <App_Name.exe> on machine <Machine_Name>. Contact your system administrator for assistance

Unter Windows Vista oder Windows Server 2008 erhält man die flogende Fehlermeldung wenn der Application Verifier nicht elevated gestartet wird:

Access denied. You need administrative credentials to use Application Verifier on image <App_Name.exe> on machine <Machine_Name> or per user verifier settings should be enabled by the administrator. Please refer to documentation for more information.

Durch einen simplen Eintrag in der Registry lässt sich aber auch als normaler Benutzer, ohne administrative Rechte, der Application Verifier nutzen, man erzeugt einen DWORD Eintrag in der Registry mit dem Wert 1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manger\ImageExecutionOptions
Nach einem Reboot kann man nun einfach den Application Verifier auch non-elevated, als normaler Benutzer nutzen.

4 Gedanken zu „VS Tipps & Tricks: Heap Bugs finden (Teil 2)“

  1. Hallo Martin,

    gibt es auch eine Möglichkeit den AppVerifier als Stand Alone Installation in das normales VS 2008 Prof zu integrieren, so dass ich beim Starten des Debuggers den AppVerifier hinzuschalten kann?

  2. Das kann ich Dir leider nicht sagen. Ich habe die Team-Suite. Ist aber möglich, dass dies automatisch passiert wenn Du ihn installierst.
    VErsuch es doch mal und antworte hier im Kommentarbereich. Das ist ja auch eine interessante Info.
    Wenn nicht ist das auch nicht tragisch. Denn der Application Verifier lässt sich auch so einfach parametrieiseren. Man muss dann nur die ausführbare Datei direkt angeben.

  3. Ich habe den 32 Bit AppVerifier als externes Tool bei VS2008 Prof unter Vista eingebunden. Dabei habe ich jetzt je ein Kommando für die das Aktivieren und das Deaktivieren angelegt.

    AppVerifier aktivieren
    Command: C:\Windows\SysWOW64\appverif.exe
    Arguments: /verify $(TargetPath)
    Initial Directory: $(TargetDir)

    AppVerifier deaktivieren
    Command: C:\Windows\SysWOW64\appverif.exe
    Arguments: -disable * -for $(TargetPath)
    Initial Directory: $(TargetDir)

    Da ich auf meinem 64 Bit Vista den AppVerifier in der 32 Bit und der 64 Bit Version installiert habe, wurde ohne Pfadangabe zuerst die 64Bit Variante im system32 Verzeichnis gefunden, was bei 32 Bit Programmen aber nicht hilft. Auf 32 Bit Systemen ist die Pfadangabe überflüssig.

    Es werden so nur die grundlegenden Checks aktiviert, aber man kann über die Kommandozeilenparameter auch die erweiterten Optionen des AppVerifier einschalten. Der Test mit deinem Beispiel hat das erwartete Ergebnis gebracht.

    Was mich noch stört, ist der Elevation Prompt, der trotz ImageExecutionOptions und Reboot weiterhin erscheint.

Schreibe einen Kommentar zu Martin Richter Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

I accept that my given data and my IP address is sent to a server in the USA only for the purpose of spam prevention through the Akismet program.More information on Akismet and GDPR.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.