Verwendung von "Pageheap.exe" in Windows XP und Windows 2000

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 286470 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Dieser Artikel ist eine Übersetzung des folgenden englischsprachigen Artikels der Microsoft Knowledge Base:
286470 How to use Pageheap.exe in Windows XP and Windows 2000
Bitte beachten Sie: Bei diesem Artikel handelt es sich um eine Übersetzung aus dem Englischen. Es ist möglich, dass nachträgliche Änderungen bzw. Ergänzungen im englischen Originalartikel in dieser Übersetzung nicht berücksichtigt sind. Die in diesem Artikel enthaltenen Informationen basieren auf der/den englischsprachigen Produktversion(en). Die Richtigkeit dieser Informationen in Zusammenhang mit anderssprachigen Produktversionen wurde im Rahmen dieser Übersetzung nicht getestet. Microsoft stellt diese Informationen ohne Gewähr für Richtigkeit bzw. Funktionalität zur Verfügung und übernimmt auch keine Gewährleistung bezüglich der Vollständigkeit oder Richtigkeit der Übersetzung.
Alles erweitern | Alles schließen

Auf dieser Seite

Zusammenfassung

In diesem Artikel wird die Verwendung des Dienstprogramms "Page Heap" (Pageheap.exe) in Microsoft Windows XP und Microsoft Windows 2000 behandelt.

Weitere Informationen

"Pageheap.exe" setzt Seitenheap-Flags, die dabei helfen, mit Heaps in Zusammenhang stehende Schäden zu erkennen. Außerdem hilft es dabei, Lecks in Programmen zu erkennen, die unter Windows 2000 Professional Service Pack 2 (SP2) und Windows XP Professional ausgeführt werden.

"Pageheap.exe" führt eine Softwareüberprüfungsebene (Seitenheap-Manager) zwischen der Anwendung und dem System ein und überprüft dann alle dynamischen Speicheroperationen (Zuweisungen, Speicherfreigaben und sonstige Heap-Operationen). Wenn der Seitenheap-Manager aktiviert ist, wird die zu testende Anwendung unter einem Debugger gestartet. Wenn ein Problem erkannt wird, hält der Debugger den Prozess an.

Wichtig: "Pageheap.exe" gibt nicht an, um was für ein Problem es sich handelt, bringt jedoch das System zum Absturz, wenn ein Problem entdeckt wird. Das Programm aktiviert eine Überprüfungsebene, die in den Systembibliotheken des Typs "Ntdll.dll" in Windows 2000 Professional SP2 und Windows XP Professional bereits vorhanden ist. Unter früheren Versionen von Microsoft Windows funktioniert "Pageheap.exe" nicht.

Wenn die zu testende Anwendung nicht unter einem Debugger gestartet wird und ein Fehler auftritt, stürzt die Anwendung ohne jegliche Fehlermeldung ab.

Konzepte

Ein häufiges Problem bei der Anwendungsentwicklung sind Heap-Beschädigungen. Dazu kommt es in der Regel, wenn eine Anwendung einen Heap-Speicherblock einer bestimmten Größe zuordnet und dann in Speicherbereiche schreibt, die außerhalb der angeforderten Größe des Heapblocks liegen. Zu Heap-Beschädigungen kann es auch kommen, wenn eine Anwendung in einen Speicherblock schreibt, der bereits freigegeben wurde.

Zwei Konzepte sind von zentraler Bedeutung dafür, die Befehle in Verbindung mit "Pageheap.exe" und die Verwendung dieses Programms zu verstehen:
  • Beschädigte Heapblöcke werden entweder dadurch entdeckt, dass eine Seite, auf die nicht zugegriffen werden kann, an das Ende des zugeordneten Bereichs gesetzt wird, oder indem man die Füllmuster überprüft, wenn der Block freigegeben wurde.
  • Es gibt zwei Heaps (Vollseiten-Heap und normaler Seitenheap) für jeden Heap, der in einem Prozess erstellt wird, für den der Seitenheap aktiviert ist.
    • Ein Vollseiten-Heap deckt Beschädigungen in Heapblöcken auf, indem eine Seite, auf die nicht zugegriffen werden kann, an das Ende des zugeordneten Bereichs gesetzt wird. Der Vorteil dieser Vorgehensweise liegt darin, dass Sie einen "Sudden Death" erreichen. Dies bedeutet, dass die Zugriffsverletzung durch den Prozess exakt an der Fehlerquelle erfolgt. Dadurch wird das Debuggen erheblich erleichtert. Der Nachteil besteht darin, dass für jede Zuordnung mindestens eine Seite an zugesichertem Speicher benötigt wird. Bei einem viel Speicher erfordernden Prozess können die Systemressourcen so schnell erschöpft sein.
    • Ein normaler Seitenheap kann in Situationen eingesetzt werden, in denen aufgrund von Einschränkungen in Bezug auf den verfügbaren Speicher der Vollseiten-Heap nicht verwendet werden kann. Bei einem normalen Seitenheap werden die Füllmuster überprüft, wenn ein Heapblock freigegeben wird. Der Vorteil dieser Methode besteht darin, dass sie den Speicherverbrauch drastisch reduziert. Der Nachteil ist, dass Beschädigungen nur dann erkannt werden, wenn ein Block freigegeben wird. Dadurch wird das Debuggen erschwert.

Website für den Download des Dienstprogramms "Pageheap.exe"

Klicken Sie zum Herunterladen des neuesten Pakets mit Debug-Programmen auf den folgenden Link:
http://www.microsoft.com/whdc/devtools/debugging/default.mspx


Wählen Sie das aktuelle Release der Debug-Programme aus. Wählen Sie bei der Installation die Option Benutzerdefiniert aus, und installieren Sie die Programme dann in einem Ordner mit einem entsprechenden Namen. Installieren Sie die Programme beispielsweise in einem Ordner mit dem Namen "C:\Debug" oder "C:\Debugprogramme".

Wahl einer Methode zur Untersuchung von Heapblock-Beschädigungen

Die meisten Heapblock-Beschädigungen können mit einer der beiden folgenden Methoden erkannt werden:
  • Vollseiten-Heap: Setzen Sie eine Seite, auf die nicht zugegriffen werden kann, an das Ende des zugeordneten Bereichs.
  • Normaler Seitenheap: Überprüfen Sie die Füllmuster, wenn ein Heapblock freigegeben wird.

Vollseiten-Heap

Dieser sollte wegen der hohen Speicheranforderungen nur für einzelne Prozesse oder unter gewissen Umständen für umfangreiche Prozesse aktiviert werden. Er kann nicht für das gesamte System aktiviert werden, weil es sehr schwierig ist, zu ermitteln, wie groß die Auslagerungsdatei sein muss. Wenn Sie bei einem systemweiten Vollseiten-Heap eine zu kleine Auslagerungsdatei verwenden, kann das System nicht mehr gestartet werden.

Der Vorteil eines Vollseiten-Heaps ist, dass die Zugriffsverletzung durch den Prozess exakt an der Fehlerquelle erfolgt. Dadurch wird das Debuggen erleichtert. Um Fehlern und ihrer Ursache auf den Grund zu gehen, verwenden Sie zunächst einen normalen Seitenheap, mit dem Sie den Bereich ermitteln, in dem der Prozess fehlschlägt. Verwenden Sie dann einen Vollseiten-Heap für einzelne umfangreiche Prozesse einer bestimmten Klasse von Zuordnungen (zum Beispiel einen bestimmten Größenbereich oder eine bestimmte Bibliothek).

Normaler Seitenheap

Ein normaler Seitenheap kann für das Testen umfangreicher Prozesse verwendet werden und erfordert wesentlich weniger Speicher als ein Vollseiten-Heap. Bei einem normalen Seitenheap verzögert sich die Erkennung von Fehlern jedoch bis zur Freigabe der Blöcke, wodurch das Debuggen erschwert wird.

Im Allgemeinen sollte ein normaler Seitenheap für ein erstes Testen umfangreicher Prozesse verwendet werden. Wenn dabei Probleme erkannt werden, aktivieren Sie den Vollseiten-Heap für eine bestimmte Klasse von Speicherzuordnungen innerhalb dieser Prozesse.

Ein normaler Seitenheap kann unbesorgt systemweit und für alle Prozesse aktiviert werden. Dies ist sehr nützlich für Testvorrichtungen, die eine allgemeine Systemüberprüfung vornehmen, die nicht auf bestimmte Komponenten fokussiert ist. Ein normaler Seitenheap kann auch für einen einzelnen Prozess aktiviert werden.

Verwendung von "GFlags" für einen systemweiten Seitenheap

Das Dienstprogramm GFlags wird verwendet, um einen systemweiten Seitenheap zu aktivieren. Damit der GFlags-Befehl wirksam wird, müssen Sie nach der Ausgabe des Befehls Ihren Computer neu starten.

Gehen Sie folgendermaßen vor, um einen normalen, systemweiten Seitenheap zu aktivieren:
  1. Geben Sie den folgenden Befehl in die Befehlszeile ein: gflags -r +hpa

  2. Starten Sie den Computer neu.
Gehen Sie folgendermaßen vor, um einen normalen, systemweiten Seitenheap zu deaktivieren:
  1. Geben Sie den folgenden Befehl in die Befehlszeile ein: gflags -r -hpa

  2. Starten Sie den Computer neu.
Hinweis: Die Verwendung anderer GFlags-Einstellungen beim Aktivieren eines Seitenheaps ist nicht sinnvoll. Werden andere Einstellungen aktiviert, die scheinbar im Zusammenhang mit dem Heap stehen, können aufgrund von Konflikten zwischen dem Seitenheap-Manager und diesen "harmlosen" Heap-Flags Seitenheap-Fehler entstehen.

Verwendung von "GFlags" bei einem Seitenheap für einen einzelnen Prozess

Sie können das Dienstprogramm "Pageheap" darauf konfigurieren, einen ganz bestimmten Prozess zu überwachen Gehen Sie hierzu folgendermaßen vor:
  1. Wechseln Sie in der Eingabeaufforderung das Verzeichnis, in dem Sie die Debugging-Programme installiert haben.
  2. Geben Sie in die Eingabeaufforderung Folgendes ein, und drücken Sie anschließend die [EINGABETASTE]:
    Gflags.exe ?p /enable lsass.exe
    Hinweis: lsass.exe steht für den Namen des Prozesses, den Sie mit dem Dienstprogramm "Pageheap" überwachen möchten.
  3. Wenn Sie die Überwachung durch das Dienstprogramm "Pageheap" nicht mehr benötigen, deaktivieren Sie die Überwachung. Geben Sie hierzu den folgenden Befehl in eine Eingabeaufforderung ein, und drücken Sie anschließend die [EINGABETASTE]:
    Gflags.exe -p /disable lsass.exe
    Hinweis: lsass.exe steht für den Namen des Prozesses, den Sie mit dem Dienstprogramm "Pageheap" überwachen möchten.
  4. Geben Sie in einer Eingabeaufforderung den folgenden Befehl ein, und drücken Sie anschließend die [EINGABETASTE], um alle Programme auflisten zu lassen, für die zurzeit die Seitenheap-Überprüfung aktiviert ist:
    Gflags.exe -p

Nicht ausgerichtete Zuordnungen

Die Windows-Heapmanager (alle Versionen) haben immer gewährleistet, dass die Heap-Zuweisungen eine auf 8 Byte ausgerichtete Startadresse hatten (bei 64-Bit-Plattformen 16-Byte). Auch das Dienstprogramm "Pageheap" gewährleistet dies. Dies ist jedoch nicht möglich, wenn die Zuweisung direkt am Ende der Seite enden soll. Das exakte Ende der Zuweisung zum Seitenende ist erforderlich, damit Fehler durch eine Abweichung um ein Byte einen Lese- oder Schreibzugriff auf die Seite auslösen, auf die nicht zugegriffen kann, und somit einen sofortigen Fehler verursachen.

Falls die durch den Benutzer angeforderte Größe des Blocks nicht auf 8 Byte ausgerichtet ist, kann der Seitenheap nicht beide Anforderungen erfüllen. Eine Ausrichtung der Startadresse auf 8 Byte und eine gleichzeitige Ausrichtung auf das Seitenende sind nicht möglich. Die Lösung besteht darin, die erste Anforderung zu erfüllen und den Start des Blocks auf 8 Byte auszurichten. Verwenden Sie dann ein kleines Füllmuster zwischen dem Ende des Blocks und dem Anfang der nicht zugriffsfähigen Seite. Auf 32-Bit-Plattformen kann dieses Füllmuster zwischen 1 und 7 Byte lang sein. Dieses Füllmuster wird nach der Freigabe überprüft.

Falls eine sofortige Fehlererkennung für diese Zuweisungen erforderlich ist, die andernfalls ein Füllmuster am Ende hätten, lassen Sie den Seitenheap-Manager die 8-Byte-Ausrichtungsregel ignorieren und nehmen Sie eine Ausrichtung auf das Seitenende vor, indem Sie die Parameter /unaligned und /full verwenden. Für weitere Informationen sehen Sie sich den Parameter /unaligned an.

Hinweis: Manche Programme gehen von einer Ausrichtung auf 8 Byte aus und funktionieren dann nicht mehr einwandfrei mit dem Parameter /unaligned. Eines dieser Programme ist Microsoft Internet Explorer.

Nicht zugewiesene Seiten bei Zuweisungen für einen Vollseiten-Heap

Bei der Implementierung eines Vollseiten-Heaps werden für jede Zuweisung, die kleiner als eine Seite ist, zwei Seiten zugewiesen. Eine Seite wird für die Benutzerzuweisung verwendet, während die andere als nicht zugriffsfähige Seite an das Ende des Puffers gesetzt wird.

Überläufe am Ende des Puffers können entdeckt werden, indem man eine Zone reservierten virtuellen Speichers statt einer nicht zugriffsfähigen, zugewiesenen Seite verwendet. Es kommt zu einem Ausnahmefehler in Form einer Zugriffsverletzung, wenn der Prozess diesen reservierten virtuellen Speicher berührt. Bei dieser Vorgehensweise kann der Speicherverbrauch um bis zu 50 Prozent reduziert werden. Für weitere Informationen sehen Sie sich die Angaben zum Parameter /decommit an.

Bewusste Einführung von Fehlern

Sie können den Seitenheap-Manager so steuern, dass bestimmte Zuweisungen absichtlich fehlschlagen. Dies ist hilfreich, um Situationen mit knappem Speicherplatz zu simulieren, ohne tatsächlich alle Systemressourcen zu verbrauchen.

Geben Sie eine Zahl zwischen 1 und 10.000 an, die die Wahrscheinlichkeit repräsentiert, dass eine Zuweisung fehlschlägt. Bei einem Wahrscheinlichkeitswert von 10.000 ist sichergestellt, dass alle Zuweisungen fehlschlagen. Bei einem Wahrscheinlichkeitswert von 2.000 schlagen 20 Prozent aller Zuweisungen fehl.

Der Seitenheap-Manager trifft spezielle Vorkehrungen, um eine Einführung von Fehlern während der ersten 5 Sekunden der Prozesslebensdauer und in die Codepfade der Windows NT-Ladeprogramme (zum Beispiel "LoadLibrary", "FreeLibrary") zu verhindern. Falls 5 Sekunden nicht ausreichen, um einen vollständigen Start Ihres Prozesses zu ermöglichen, können Sie für den Anfang des Prozesses einen höheren Zeitüberschreitungswert festlegen. Für weitere Informationen sehen Sie sich die Angaben zum Parameter /fault an.

Wenn Sie den Parameter /fault verwenden und der getestete Prozess einen Fehler aufweist, wird ein Ausnahmefehler ausgelöst. Im Allgemeinen liegt die Ursache hierfür darin, dass der Zuweisungsvorgang NULL zurückgegeben hat und die Anwendung später versucht, auf den zugewiesenen Speicher zuzugreifen. Da die Zuweisung jedoch fehlgeschlagen ist, kann auf den Speicher nicht zugegriffen werden und es kommt zu einer Zugriffsverletzung.

Der andere Grund für einen Ausnahmefehler ist, dass die Anwendung versucht, den Zuweisungsfehler zu beheben, einige Ressourcen jedoch nicht freigibt. Dieses Problem äußert sich als nicht freigegebener Speicher und ist schwieriger zu debuggen.

Der Seitenheap-Manager führt beginnend mit dem Moment der Fehlereinführung ein Protokoll der Stapelnachverfolgungen, um die Diagnose derartiger Fehlfunktionen zu erleichtern. Diese Nachverfolgungen können Sie mit dem folgenden Debugger-Befehl anzeigen lassen:

!heap -p -f [NUMBER-OF-TRACES]

Standardmäßig werden nur die letzten vier Nachverfolgungen angezeigt.

Automatisches Anhängen eines Debuggers beim Starten der Anwendung

Manche Anwendungen können nur schwer über eine Eingabeaufforderung gestartet werden oder werden von anderen Prozessen initialisiert. Legen Sie für diese Anwendungen fest, dass bei jedem Start automatisch ein Debugger an sie angehängt wird. Dies ist sinnvoll, wenn der Seitenheap für diesen Prozess aktiviert ist und Heapfehler auftreten. Für weitere Informationen sehen Sie sich die Angaben zum Parameter /debug an.

"Pageheap.exe" ist effektiv, wenn es zur Überprüfung von Speicherzuweisungsprozessen verwendet wird, einschließlich neuer und gelöschter C++-Zuweisungen, sofern die benutzerdefinierten Zuweisungs-/Freigabefunktionen die Schnittstellen des NT-Heapmanagements (wie "RtlAllocateHeap" und "RtlFreeHeap") abfragen. Bei den folgenden Funktionen ist dies gewährleistet:
  • Funktionen wie HeapAlloc, HeapFree, HeapReAlloc: Diese Funktionen werden von "kernel32.dll" exportiert und fragen direkt die NT-Heapschnittstellen ab.
  • Funktionen wie GlobalAlloc, GlobalFree, GlobalReAlloc: Diese Funktionen werden von "kernel32.dll" exportiert und fragen entweder direkt oder indirekt die NT-Heapschnittstellen ab.
  • Funktionen wie LocalAlloc, LocalFree, LocalReAlloc: Diese Funktionen werden von "kernel32.dll" exportiert und fragen entweder direkt oder indirekt die NT-Heapschnittstellen ab.
  • Die Funktionen malloc, free, realloc, msize, expand: Diese Funktionen werden von "msvcrt.dll" exportiert und fragen entweder direkt oder indirekt den NT-Heap ab. Dies war nicht immer so. Die C-Laufzeitbibliothek hatte bisher eine andere Heap-Implementierung, die aktuelle C-Laufzeitbibliothek fragt den NT-Heap jedoch direkt ab.
  • Die Operatoren new, delete, new[ ] , delete[ ]: Diese Funktionen werden von "msvcrt.dll" exportiert und fragen entweder direkt oder indirekt den NT-Heap ab.
Alle sonstige Zuweisungs-/Freigabefunktionen sind wahrscheinlich benutzerdefiniert und es ist nicht gewährleistet, dass sie den NT-Heap direkt oder indirekt abfragen. Nur eine Überprüfung des Quellcodes oder das Ausführen unter einem Debugger können die tatsächliche Implementierung offenlegen.

Vermeiden Sie die Verwendung statischer Verknüpfungen. Manche Anwendungen sind statisch mit älteren Versionen der C-Laufzeitbibliothek verknüpft. Diese älteren Versionen fragen Windows NT-Heap-APIs nicht ab, und "Pageheap.exe" kann für die Überprüfung dieser Zuweisungen nicht verwendet werden. Durch dynamische Verknüpfungen ist gewährleistet, dass Sie die neueste C-Laufzeitbibliothek (msvcrt.dll) erhalten.

Von "Pageheap.exe" gefundene Fehlertypen

"Pageheap.exe" erkennt die meisten Fehler mit Bezug zum Heap; das Programm ist jedoch auf Heap-Beschädigungen und nicht auf Speicherlecks fokussiert. "Pageheap.exe" hat beim Auffinden von Heap-Lecks nur eingeschränkten Erfolg, verfügt jedoch über die dafür erforderliche Funktionalität.

Einer der Vorteile von "Pageheap.exe" ist, dass viele Fehler in dem Moment erkannt werden, in dem sie auftreten. Ein Fehler durch eine Abweichung um ein Byte am Ende eines dynamisch zugewiesenen Puffers kann zum Beispiel eine sofortige Zugriffsverletzung auslösen. Nur wenige Typen von Fehlern können nicht sofort zum Zeitpunkt ihres Auftretens erkannt werden. In diesen Fällen verzögert sich der Fehlerbericht, bis der entsprechende Block freigegeben wird.
  • Ungültiger Heapzeiger: Alle Win32- und Windows NT-Heapschnittstellen nehmen als ersten Parameter einen Zeiger auf den Heap entgegen, in dem der Vorgang ausgeführt werden soll. Der Seitenheap-Manager erkennt einen ungültigen Heapzeiger in dem Moment, in dem der Aufruf erfolgt.
  • Ungültiger Heapblock-Zeiger: Nachdem ein Block zugewiesen wurde, kann er als Parameter für diverse Heapschnittstellen verwendet werden; insbesondere für Schnittstellen des Typs "free()". Der Seitenheap-Manager erkennt einen ungültigen Heapblock-Zeiger sofort. Im nachstehenden Abschnitt "Debuggen von Seitenheap-Fehlern" wird beschrieben, wie Sie feststellen können, ob die ungültige Adresse nur um einige Byte abweicht oder vollständig inkorrekt ist.
  • Nicht synchronisierter Multithread-Zugriff auf den Heap: Einige Anwendungen fragen den Heap von mehreren Threads aus ab. In einem solchen Szenario muss ein Flag gesetzt werden (durch den Benutzer), das die Anforderung einer Heapsperre auslöst. Der Seitenheap-Manager erkennt eine solche Zugriffsverletzung, bei der gleichzeitig zwei Threads versuchen, den Heap abzufragen.
  • Annahmen zur Neuzuweisung eines Blocks an derselben Adresse: Bei einer Neuzuweisung ist nicht garantiert, dass dieselbe Adresse zurückgegeben wird. Dies gilt insbesondere dann, wenn der Block durch die Neuzuweisung verkleinert wird. Einige Anwendungen gehen davon aus, dass bei einer Neuzuweisung dieselbe Adresse zurückgegeben wird. Der Seitenheap-Manager weist bei einer Neuzuweisung immer einen neuen Block zu und gibt den alten Block wieder frei. Der freie Block ist vor Lese- und Schreibzugriffen geschützt. Jeder Zugriff auf diesen Block würde also eine Zugriffsverletzung darstellen.
  • Doppelte Freigabe: Dieser Fehler, bei dem ein Block mehrmals freigegeben wird, tritt in einigen Anwendungen häufig auf. Ein solcher Fehler wird durch den Seitenheap-Manager sofort erkannt, weil der Block bei der zweiten Freigabe nicht die richtige Präfixkopfzeile hätte und unter den zugewiesenen Blocks nicht gefunden werden könnte. Im nachstehenden Abschnitt "Debuggen von Seitenheap-Fehlern" werden Möglichkeiten beschrieben, die Stapelnachverfolgungen des ersten Freigabevorgangs zu analysieren. Bei diesem Fehler kann es sich um eine Variante des Neuzuweisungsproblems handeln, weil die Anwendung glaubt, die Adresse des betreffenden Blocks freizugeben, dieser Block aber bereits im Rahmen der Neuzuweisung freigegeben wurde.
  • Zugriff auf einen Block nach der Freigabe: Freigegebene Speicherblöcke werden durch den Seitenheap-Manager für einen kurzen Zeitraum in einem Pool mit geschütztem Speicher verwahrt. Jeder Zugriff auf diese Blöcke wäre eine Zugriffsverletzung. Auf der Basis des "Lokalitätsprinzips" sollten die meisten Probleme erkannt werden, wenn der freigegebene Speicherpool groß genug ist. Wenn sich der freigegebene Block noch im geschützten Speicherpool befindet, wird der Fehler sofort erkannt. Wurde der Speicherbereich jedoch erneut verwendet, ist die Chance kleiner, den Fehler zu finden oder den Code zu identifizieren, der ihn verursacht hat.
  • Zugriff hinter dem Ende eines zugewiesenen Blocks: Der Seitenheap-Manager setzt direkt hinter den zugewiesenen Block eine Seite, auf die nicht zugegriffen werden kann. Jeder Zugriff auf Bereiche hinter dem Ende des Blocks führt zu einer Zugriffsverletzung. Manche Anwendungen erwarten, dass Zuweisungen auf 8 Byte ausgerichtet sind. Diese Ausrichtung wurde seit den Heap-Managern in Windows NT 3.5 unterstützt. Bei einer nicht auf 8 Byte ausgerichteten Anforderung erhält man zwar trotzdem eine auf 8 Byte ausgerichtete Adresse, dabei verbleiben jedoch einige Byte nach dem Ende des Blocks, auf die noch zugegriffen werden kann. Beschädigt die Anwendung nur diese wenigen Byte, kann der Fehler nur durch Überprüfung des Suffixmusters des Blocks bei dessen Freigabe gefunden werden.
  • Zugriff vor dem Anfang eines zugewiesenen Blocks: Der Seitenheap-Manager kann durch ein entsprechendes Flag instruiert werden, die nicht zugriffsfähige Seite an den Anfang des Blocks zu setzen und nicht an dessen Ende. Jeder Zugriff auf Bereiche vor dem Anfang des Blocks führt zu einer Zugriffsverletzung.
Tabelle minimierenTabelle vergrößern
FehlerNormaler SeitenheapVollseiten-Heap
Ungültiger HeapzeigerSofort erkanntSofort erkannt
Ungültiger Heapblock-ZeigerSofort erkanntSofort erkannt
Nicht synchronisierter ZugriffSofort erkanntSofort erkannt
Annahme zur Neuzuweisungsadresse90% bis zur tatsächlichen Freigabe90% sofort erkannt
Doppelte Freigabe90% sofort erkannt90% sofort erkannt
Neuverwendung nach der Freigabe90% bis zur tatsächlichen Freigabe90% sofort erkannt
Zugriff hinter dem Ende eines BlocksBei der Freigabe erkanntSofort erkannt
Zugriff vor dem Anfang eines BlocksBei der Freigabe erkanntSofort erkannt (spezielles Flag)

Debuggen von Seitenheap-Fehlern

Weitere Informationen zum Debuggen von Seitenheap-Fehlern finden Sie in der Application Compatibility Toolkit Reference, die im Application Compatibility Toolkit enthalten ist.

Informationen zur Syntax von "Pageheap.exe" und Beispiele für die Verwendung von "Pageheap.exe" finden Sie ebenfalls in der Application Compatibility Toolkit Reference, die im Application Compatibility Toolkit enthalten ist.

Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:
294895 So erhalten Sie das Windows Application Compatibility Toolkit

Eigenschaften

Artikel-ID: 286470 - Geändert am: Mittwoch, 6. Dezember 2006 - Version: 4.1
Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft Windows Server 2003, Standard Edition (32-bit x86)
  • Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
  • Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
  • Microsoft Windows XP Professional
  • Microsoft Windows XP Home Edition
  • Microsoft Windows 2000 Professional Edition
  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Datacenter Server
Keywords: 
kbinfo kbenv KB286470
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.

Ihr Feedback an uns

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com