Anwendungsüberprüfung – Stoppcodes – Grundlagen

Die folgenden Stoppcodes sind in den Grundlagen der Tests enthalten.

Details zum Beenden von Ausnahmen

Versuchen Sie, Code im nicht ausführbaren Speicher (erste Chance) auszuführen.

Dieser Stopp wird generiert, wenn die Anwendung versucht, Code aus einer Adresse auszuführen, die nicht ausführbar oder kostenlos ist. So debuggen Sie diesen Stopp:

• u <parameter2> – Aufheben der Assemble the culprit code
• .exr <parameter3> – Anzeigen der Ausnahmeinformationen
• .cxr-Parameter4>< – Anzeigen der Ausnahmekontextinformationen
• kb – Zeigt die Stapelablaufverfolgung für die Zeit an, zu der die Ausnahme ausgelöst wurde.

• Parameter 1 - Adresse, auf die zugegriffen wird.
• Parameter 2 - Code, der ungültigen Zugriff ausführt.
• Parameter 3 - Ausnahmedatensatz. Verwenden Sie ".exr", um sie anzuzeigen.
• Parameter 4 - Kontextdatensatz. Verwenden Sie .cxr, um sie anzuzeigen.

• Testschicht: Ausnahmen
• Stopp-ID: FIRST_CHANCE_ACCESS_VIOLATION_CODE
• Stoppcode: 650
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Handles Stop Details

Ungültige Handle-Ausnahme für die aktuelle Stapelablaufverfolgung.

Dieser Stopp wird generiert, wenn die Funktion oben im Stapel ein ungültiges Handle an Systemroutinen übergeben hat. In der Regel wird ein einfacher "kb"-Befehl erkennen, was der Wert des übergebenen Handles ist (es muss sich um einen der Parameter - in der Regel der erste - sein). Wenn der Wert null ist, ist dies eindeutig falsch. Wenn der Wert in Ordnung ist, müssen Sie die Debuggererweiterung "!htrace" verwenden, um einen Verlauf der Vorgänge zu diesem Handlewert abzurufen. In den meisten Fällen wird der Handlewert nach dem Schließen verwendet.

• Parameter 1 - nicht verwendet.
• Parameter 2 - Nicht verwendet.
• Parameter 3 - Nicht verwendet.
• Parameter 4 – nicht verwendet.

• Testschicht: Griffe
• Stopp-ID: INVALID_HANDLE
• Stoppcode: 300
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Ungültiger TLS-Index, der für die aktuelle Stapelablaufverfolgung verwendet wird.

Dieser Stopp wird generiert, wenn die Funktion oben im Stapel einen ungültigen TLS-Index an TLS-Systemroutinen übergeben hat. In der Regel zeigt ein einfacher Befehl "kb" an, was falsch ist. Der typische Fehler hier besteht darin, einen bestimmten Wert für einen TLS-Index anzunehmen, anstatt 'TlsAlloc' aufzurufen. Dies kann passieren, indem Sie davon ausgehen, dass Sie immer den Wert N erhalten und daher "TlsAlloc" nicht aufrufen müssen. Häufiger ist dies auf eine nicht initialisierte Variable zurückzuführen.

• Parameter 1 - Ungültiger TLS-Index.
• Parameter 2 - Niedrigerer Teil des Indexes erwartet.
• Parameter 3 - Nicht verwendet.
• Parameter 4 – nicht verwendet.

• Testschicht: Griffe
• Stopp-ID: INVALID_TLS_VALUE
• Stoppcode: 301
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Ungültige Parameter für waitForMultipleObjects-Aufruf.

Dieser Stopp wird generiert, wenn die Funktion oben im Stapel mit dem Namen "WaitForMultipleObjects" mit NULL als Adresse des Arrays von Handles wartet oder null als Anzahl der Handles. Ein einfacher Befehl "kb" zeigt die Funktion an, die diese API falsch aufruft.

• Parameter 1 - Adresse des Objekthandlesvektors.
• Parameter 2 - Anzahl der Ziehpunkte.
• Parameter 3 - Nicht verwendet.
• Parameter 4 – nicht verwendet.

• Testschicht: Griffe
• Stopp-ID: INCORRECT_WAIT_CALL
• Stoppcode: 302
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

NULL-Handle, das als Parameter übergeben wird. Ein gültiger Handle muss verwendet werden.

Dieser Stopp wird generiert, wenn die Funktion oben im Stapel ein NULL-Handle an Systemroutinen übergeben hat. Normalerweise zeigt ein einfacher Befehl "kb" den Wert des übergebenen Handles an (er muss einer der Parameter sein, in der Regel der erste).

• Parameter 1 -Verwenden des NULL-Handles 
• Parameter 2 - Nicht verwendet
• Parameter 3 - Nicht verwendet
• Parameter 4 - Nicht verwendet

• Testschicht: Griffe
• Stopp-ID: NULL_HANDLE
• Stoppcode: 303
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Warten auf ein Threadhandle in DllMain.

Dieser Stopp wird generiert, wenn der aktuelle Thread derzeit Code innerhalb der "DllMain"-Funktion einer der im aktuellen Prozess geladenen DLLs ausführt und "WaitForSingleObjects" oder "WaitForMultipleObjects" aufruft, um auf ein Threadhandle im selben Prozess zu warten. Dies führt wahrscheinlich zu einem Deadlock, da der Threadziehpunkt nicht signalisiert wird, es sei denn, der zweite Thread wird beendet. Wenn der zweite Thread "ExitThread" aufruft, versucht er, die DLL-Ladesperre abzurufen und dann "DllMain" (DLL_THREAD_DETACH) für alle DLLs im aktuellen Prozess aufzurufen. Da sich die Ladesperre im Besitz des ersten Threads befindet (der auf den Threadziehpunkt wartet), werden die beiden Threads inaktiv.

• Parameter 1 - Threadziehpunkt.
• Parameter 2 - Nicht verwendet.
• Parameter 3 - Nicht verwendet.
• Parameter 4 – nicht verwendet.

• Testschicht: Griffe
• Stopp-ID: WAIT_IN_DLLMAIN
• Stoppcode: 304
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Ungültiger Objekttyp für handle.

Dieser Stopp wird generiert, wenn der aktuelle Thread eine API mit einem Handle für ein Objekt mit einem falschen Objekttyp aufruft. Wenn Sie z. B. "SetEvent" mit einem Semaphorhandle als Parameter aufrufen, wird dieser Stopp generiert. So debuggen Sie diesen Stopp:

• kb - zum Anzeigen der aktuellen Stapelablaufverfolgung. Der Schuldige ist wahrscheinlich die DLL, die in verifier.dll
• du <parameter2> – zum Anzeigen des tatsächlichen Typs des Handles. Der Handlewert ist Parameter1. Im vorherigen Beispiel wird hier "Semaphor" angezeigt.
• du <parameter3> – zum Anzeigen des objekttyps, der von der API erwartet wird. Im vorherigen Beispiel lautet dieser Name "Event".
• !htrace <parameter1> - kann hilfreich sein, da die Stapelablaufverfolgung für die letzten Öffnen/Schließen-Vorgänge für dieses Handle angezeigt wird.

• Parameter 1 - Handle-Wert.
• Parameter 2 - Objekttypname. Verwenden von du zum Anzeigen
• Parameter 3 - Objekttypname erwartet. Verwenden von du zum Anzeigen
• Parameter 4 – nicht verwendet.

• Testschicht: Griffe
• Stopp-ID: INCORRECT_OBJECT_TYPE
• Stoppcode: 305
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Heaps Stop Details

Unbekannter Fehler.

Diese Meldung kann auftreten, wenn der aufgetretene Fehler nicht auf andere Weise klassifiziert werden kann. Wird zur zeit nicht verwendet.

• Parameter 1 - Nicht verwendet
• Parameter 2 - Nicht verwendet
• Parameter 3 - Nicht verwendet
• Parameter 4 - Nicht verwendet

• Testschicht: Haufen
• Stopp-ID: UNKNOWN_ERROR
• Stoppcode: 0x1
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Ausnahme für Zugriffsverletzungen.

Dies ist der häufigste Anwendungsprüferstopp. In der Regel wird sie durch einen Pufferüberlauffehler verursacht. Der Heap-Prüfer platziert eine nicht zugängliche Seite am Ende einer Heap-Zuordnung, und ein Pufferüberlauf führt zu einer Ausnahme, indem diese Seite berührt wird. Um diesen Stopp zu debuggen, identifizieren Sie die Zugriffsadresse, die die Ausnahme verursacht hat, und verwenden Sie dann den folgenden Debuggerbefehl:

• !heap -p -a ACCESS_ADDRESS - Dieser Befehl gibt Details zur Art des Fehlers und zu dem Heapblock überlauft. Außerdem wird die Stapelablaufverfolgung für die Blockzuordnung erteilt. Es gibt andere Ursachen für diesen Stopp, z. B. den Zugriff auf einen Heap-Block nach dem Freigeben. Derselbe Debuggerbefehl ist für diesen Fall nützlich.

• Parameter 1 - Ungültige Adresse, die die Ausnahme verursacht
• Parameter 2 - Codeadresse, die den ungültigen Zugriff ausführt
• Parameter 3 - Ausnahmedatensatz
• Parameter 4 - Kontextdatensatz

• Testschicht: Haufen
• Stopp-ID: ACCESS_VIOLATION
• Stoppcode: 0x2
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Multithread-Zugriff in einem Heap, der mit HEAP_NO_SERIALIZE Flag erstellt wurde.

Ein heap, der mit HEAP_NO_SERIALIZE Flag erstellt wurde, sollte nicht gleichzeitig von zwei Threads aus aufgerufen werden. Wenn eine solche Situation erkannt wird, erhalten Sie diese Meldung. Die typische Art und Weise, wie sich diese Situation in ein Programm einfügt, besteht darin, eine Verknüpfung mit einer Singlethread-Version der C-Runtime zu erstellen. Visual C++ kann z. B. statisch eine solche Bibliothek verknüpfen, wenn richtige Flags verwendet werden. Entwickler vergessen dann dieses Detail und verwenden mehrere Threads. Der Fehler ist sehr schwierig, im realen Leben zu debuggen, da es als mysteriöse Datenbeschädigungen angezeigt wird.

• Parameter 1 - Heap, in dem der Vorgang erfolgt.
• Parameter 2 - Thread-ID für den aktuellen Besitzer des heap kritischen Abschnitts.
• Parameter 3 - Thread-ID des aktuellen Threads, der versucht, den Heap einzugeben.
• Parameter 4 - Nicht verwendet

• Testschicht: Haufen
• Stopp-ID: UNSYNCHRONIZED_ACCESS
• Stoppcode: 0x3
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Extreme Größenanforderung.

Diese Nachricht wird generiert, wenn die Größe des Blocks in einem "HeapAlloc"- oder "HeapReAlloc"-Vorgang über einem angemessenen Wert liegt. Dieser Wert wird in der Regel auf 32-Bit-Plattformen 0x80000000 und auf 64-Bit-Plattformen deutlich größer.

• Parameter 1 - Heap, in dem der Vorgang erfolgt.
• Parameter 2 - Größe angefordert
• Parameter 3 - Nicht verwendet
• Parameter 4 - Nicht verwendet

• Testschicht: Haufen
• Stopp-ID: EXTREME_SIZE_REQUEST
• Stoppcode: 0x4
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Heap-Handle mit falscher Signatur.

Die Heapstrukturen werden mit einem magischen Wert markiert. Wenn das heap-Handle, das im Aufruf einer Heap-Schnittstelle verwendet wird, dieses Muster nicht aufweist, wird dieser Stopp generiert. Dieser Fehler kann auftreten, wenn die interne Heap-Struktur beschädigt wurde (zufällige Beschädigung) oder einfach ein falscher Wert als Heap-Handle verwendet wird. Verwenden Sie den folgenden Debuggerbefehl, um eine Liste der gültigen Heap-Handlewerte abzurufen:

• !heap -p

Beachten Sie: Wenn Sie einfach einen gültigen Heap-Handle mit einem anderen gültigen Handle in einem Heap-Vorgang wechseln, erhalten Sie diesen Stopp nicht (der Handle sieht schließlich gültig aus). Der Heap-Prüfer erkennt diese Situation jedoch und meldet sie mit SWITCHED_HEAP_HANDLE Stopp.

• Parameter 1 -Heap-Handle , das im Aufruf einer Heap-Schnittstelle verwendet wird
• Parameter 2 - Nicht verwendet
• Parameter 3 - Nicht verwendet
• Parameter 4 - Nicht verwendet

• Testschicht: Haufen
• Stopp-ID: BAD_HEAP_HANDLE
• Stoppcode: 0x5
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Beschädigter Heapzeiger oder falsche Heaps.

Dies geschieht in der Regel, wenn ein Block in einem Heap zugewiesen und in einem anderen freigegeben wird. Verwenden Sie den Debuggerbefehl "!heap -p", um eine Liste aller gültigen Heap-Handlewerte abzurufen. Das häufigste Beispiel ist eine msvcrt-Zuordnung, die mit "malloc" gekoppelt mit einem Kernel32-Deallocation mit "HeapFree" gekoppelt ist.

• Parameter 1 - Heap-Handle, das im Anruf verwendet wird.
• Parameter 2 - Heap-Block, der an der Operation beteiligt ist.
• Parameter 3 - Größe des Heapblocks.
• Parameter 4 - Heap, in dem der Block ursprünglich zugewiesen wurde.

• Testschicht: Haufen
• Stopp-ID: SWITCHED_HEAP_HANDLE
• Stoppcode: 0x6
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Heap-Block wurde bereits freigegeben.

Dies geschieht, wenn der Block zweimal freigegeben wird. Freigestellte Blöcke sind auf besondere Weise gekennzeichnet und werden für eine Weile in einer verzögerten kostenlosen Warteschlange herumgehalten. Wenn ein Bugprogramm versucht, den Block erneut freizugeben, wird dies abgefangen – vorausgesetzt, der Block wurde nicht von verzögerter freier Warteschlange abgequeuiert und sein Speicher für andere Zuordnungen wiederverwendet. Die Tiefe der verzögerungsfreien Warteschlange liegt in der Reihenfolge von Tausenden von Blöcken, daher gibt es gute Chancen, dass die meisten doppelten Freigänge abgefangen werden.

• Parameter 1 - Heap-Handle für den Heap, der den Block besitzt.
• Parameter 2 - Heap-Block wird wieder freigegeben.
• Parameter 3 - Größe des Heapblocks.
• Parameter 4 - Nicht verwendet

• Testschicht: Haufen
• Stopp-ID: DOUBLE_FREE
• Stoppcode: 0x7
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Beschädigter Heapblock.

Dies ist ein allgemeiner Fehler, der ausgegeben wird, wenn die Beschädigung im Heap-Block nicht in einer spezifischeren Kategorie platziert werden kann.

• Parameter 1 - Heap-Handle, das im Anruf verwendet wird.
• Parameter 2 - Heap-Block, der an der Operation beteiligt ist.
• Parameter 3 - Größe des Heapblocks.
• Parameter 4 - Reserviert

• Testschicht: Haufen
• Stopp-ID: CORRUPTED_HEAP_BLOCK
• Stoppcode: 0x8
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Versuchen Sie, prozess heap zu zerstören.

Es ist ein Fehler, den Standardprozess-Heap zu zerstören (der von der Schnittstelle 'GetProcessHeap()' zurückgegebene).

• Parameter 1 - Heap-Handle mit HeapDestroy verwendet.
• Parameter 2 - Nicht verwendet
• Parameter 3 - Nicht verwendet
• Parameter 4 - Nicht verwendet

• Testschicht: Haufen
• Stopp-ID: DESTROY_PROCESS_HEAP
• Stoppcode: 0x9
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Unerwartete Ausnahme im Heap-Code ausgelöst.

Dieser Stopp wird generiert, wenn beim Ausführen des Heap-Managers-Codes eine Zugriffsverletzung in unzulässigen Situationen ausgelöst wird. Es gibt einige Situationen, in denen dies ok ist, z. B. beim Aufrufen von "HeapValidate()" oder "HeapSize()". Die Informationen zum Ausnahmedatensatz (dritter Parameter) können verwendet werden, um den genauen Kontext der Ausnahme zu finden. Verwenden Sie dazu die folgenden Debuggerbefehle:

• dd parameter2 L2
• EXR-first_dword
• .cxr-second_dword

In der Regel geschieht dieser Stopp, wenn es eine zufällige Beschädigung in den internen Heapstrukturen gibt.

• Parameter 1 - Heap, der an der Operation beteiligt ist.
• Parameter 2 - Ausnahmedatensatz.
• Parameter 3 - Kontextdatensatz.
• Parameter 4 - Ausnahmecode (C0000005 – Zugriffsverletzung)

• Testschicht: Haufen
• Stopp-ID: UNEXPECTED_EXCEPTION
• Stoppcode: 0xA
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Ausnahme ausgelöst beim Überprüfen des Heap-Blockheaders.

Diese Situation geschieht, wenn wir wirklich keine bestimmte Art von Beschädigung für den Block bestimmen können. Tritt beispielsweise auf, wenn die an einen heapfreien Vorgang übergebene Heap-Blockadresse auf einen nicht zugänglichen Speicherbereich verweist (beschädigter Zeiger, nicht initialisierter Zeiger usw.).

• Parameter 1 - Heap-Handle für den Heap, der den Block besitzt.
• Parameter 2 - Heap-Block, der beschädigt ist.
• Parameter 3 - Größe des Blocks oder Null, wenn die Größe nicht bestimmt werden kann.
• Parameter 4 – nicht verwendet.

• Testschicht: Haufen
• Stopp-ID: CORRUPTED_HEAP_BLOCK_EXCEPTION_RAISED_FOR_HEADER
• Stoppcode: 0xB
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Ausnahme ausgelöst, während der Heapblock überprüft wird.

Diese Situation geschieht, wenn wir wirklich keine bestimmte Art von Beschädigung für den Block bestimmen können. Beispielsweise erhalten Sie dies, wenn Sie während eines heapfreien Vorgangs eine Adresse übergeben, die auf einen nicht zugänglichen Speicherbereich verweist. Dies kann auch für doppelte freie Situationen passieren, wenn wir den Block unter den Heapblöcken der ganzen Seite nicht finden und es als Heapblock für helle Seiten untersuchen.

• Parameter 1 - Heap-Handle, das im Anruf verwendet wird.
• Parameter 2 - Heap-Block, der an der Operation beteiligt ist.
• Parameter 3 - Größe des Heapblocks.
• Parameter 4 - Reserviert.

• Testschicht: Haufen
• Stopp-ID: CORRUPTED_HEAP_BLOCK_EXCEPTION_RAISED_FOR_PROBING
• Stoppcode: 0xC
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Heapblock beschädigt nach dem Freigeben.

Dies geschieht, wenn ein Speicherblock nach dem Freigeben in einen Speicherblock geschrieben wird.

• Parameter 1 - Heap-Handle für den Heap, der den Block besitzt.
• Parameter 2 - Heap-Block, der beschädigt ist.
• Parameter 3 - Größe des Blocks oder Null, wenn die Größe nicht bestimmt werden kann.
• Parameter 4 – nicht verwendet.

• Testschicht: Haufen
• Stopp-ID: CORRUPTED_HEAP_BLOCK_HEADER
• Stoppcode: 0xD
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Beschädigtes Infixmuster für freigegebenen Heap-Block.

Freigegebene Blöcke werden manchmal als nicht zugänglich gekennzeichnet, und ein Programm, das sie berührt, verletzt (unterschiedliche Überprüfungsstopp). In anderen Fällen (z. B. ein Helles Seitenhap) wird der Block mit einem magischen Muster markiert und für eine Weile aufbewahrt. Irgendwann in einer FIFO-Mode werden die Blöcke wirklich frei. Zu diesem Zeitpunkt wird das Infixmuster überprüft und wenn es geändert wurde, erhalten Sie diese Unterbrechung. Der Stapel im Unterbrechungsmoment ist nicht relevant. Sie müssen die Art des Blocks und des Codes ermitteln, den Code überprüfen, der möglicherweise falsch ist.

• Parameter 1 - Heap-Handle für den Heap, der den Block besitzt.
• Parameter 2 - Heap-Block wird freigegeben.
• Parameter 3 - Größe des Heapblocks.
• Parameter 4 - Reserviert.

• Testschicht: Haufen
• Stopp-ID: CORRUPTED_FREED_HEAP_BLOCK
• Stoppcode: 0xE
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Beschädigtes Suffixmuster für Heapblock.

Dies geschieht in der Regel bei Pufferüberlauffehlern. Manchmal platziert der Anwendungsprüfer nicht zugängliche Seiten am Ende der Zuordnung und Pufferüberläufe führt zu einer Zugriffsverletzung, und manchmal folgt der Heapblock einem magischen Muster. Wenn dieses Muster geändert wird, wenn der Block freigegeben wird, erhalten Sie diese Unterbrechung. Diese Unterbrechungen können recht schwierig zu debuggen sein, da Sie nicht den tatsächlichen Moment haben, in dem Beschädigungen aufgetreten sind. Sie haben nur Zugriff auf den kostenlosen Moment (d. h., "hier beendet") und die Zuordnungsstapel-Ablaufverfolgung ('!heap -p -a HEAP_ADDRESS')

• Parameter 1 - Heap-Handle, das im Anruf verwendet wird.
• Parameter 2 - Heap-Block, der an der Operation beteiligt ist.
• Parameter 3 - Größe des Heapblocks.
• Parameter 4 - Reserviert.

• Testschicht: Haufen
• Stopp-ID: CORRUPTED_HEAP_BLOCK_SUFFIX
• Stoppcode: 0xF
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Beschädigter Startstempel für heap-Block.

Dies geschieht für Pufferunterläufe.

• Parameter 1 - Heap-Handle, das im Anruf verwendet wird.
• Parameter 2 - Heap-Block, der an der Operation beteiligt ist.
• Parameter 3 - Größe des Heapblocks.
• Parameter 4 - Beschädigter Stempelwert.

• Testschicht: Haufen
• Stopp-ID: CORRUPTED_HEAP_BLOCK_START_STAMP
• Stoppcode: 0x10
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Beschädigter Endstempel für heap-Block.

Dies geschieht für Pufferunterläufe.

• Parameter 1 - Heap-Handle, das im Anruf verwendet wird.
• Parameter 2 - Heap-Block, der an der Operation beteiligt ist.
• Parameter 3 - Größe des Heapblocks.
• Parameter 4 - Beschädigter Stempelwert.

• Testschicht: Haufen
• Stopp-ID: CORRUPTED_HEAP_BLOCK_END_STAMP
• Stoppcode: 0x11
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Beschädigtes Präfixmuster für Heapblock.

Dies geschieht für Pufferunterläufe.

• Parameter 1 - Heap-Handle, das im Anruf verwendet wird.
• Parameter 2 - Heap-Block, der an der Operation beteiligt ist.
• Parameter 3 - Größe des Heapblocks.
• Parameter 4 - Reserviert.

• Testschicht: Haufen
• Stopp-ID: CORRUPTED_HEAP_BLOCK_PREFIX
• Stoppcode: 0x12
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

First chance access violation for current stack trace.

Dies ist der häufigste Anwendungsprüferstopp. In der Regel wird sie durch einen Pufferüberlauffehler verursacht. Der Heap-Prüfer platziert eine nicht zugängliche Seite am Ende einer Heap-Zuordnung, und ein Pufferüberlauf führt zu einer Ausnahme, indem diese Seite berührt wird. Um diesen Stopp zu debuggen, identifizieren Sie die Zugriffsadresse, die die Ausnahme verursacht hat, und verwenden Sie dann den folgenden Debuggerbefehl:

• !heap -p -a ACCESS_ADDRESS

Dieser Befehl enthält Details zur Art des Fehlers und zum Überlauf des Heap-Blocks. Außerdem wird die Stapelablaufverfolgung für die Blockzuordnung übergeben. Es gibt mehrere andere Ursachen für diesen Stopp, z. B. den Zugriff auf einen Heap-Block nach dem Freigeben. Derselbe Debuggerbefehl ist für diesen Fall nützlich.

• Parameter 1 - Ungültige Adresse, die die Ausnahme verursacht.
• Parameter 2 - Codeadresse, die den ungültigen Zugriff ausführt.
• Parameter 3 - Ausnahmedatensatz.
• Parameter 4 - Kontextdatensatz.

• Testschicht: Haufen
• Stopp-ID: FIRST_CHANCE_ACCESS_VIOLATION
• Stoppcode: 0x13
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Ungültige Anzahl der Prozess-Heaplisten.

Diese Meldung kann auftreten, wenn beim Aufrufen von GetProcessHeaps der Seitenhap-Manager einige interne Inkonsistenzen erkennt. Dies kann durch eine zufällige Beschädigung im Prozessbereich verursacht werden.

• Parameter 1 - Ist-Heapanzahl.
• Parameter 2 - Seitenhapanzahl.
• Parameter 3 - Nicht verwendet
• Parameter 4 - Nicht verwendet

• Testschicht: Haufen
• Stopp-ID: CORRUPTED_HEAP_LIST
• Stoppcode: 0x14
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Details zum Leckstopp

Eine Heap-Zuordnung wurde geleert.

Dieser Stopp wird generiert, wenn die Besitzer-DLL der Zuordnung dynamisch entladen wurde, während Ressourcen besitzen.

• Parameter 1 - Adresse der durchleckten Zuordnung. Führen Sie !heap -p -a <Adresse> aus, um zusätzliche Informationen zur Zuordnung zu erhalten.
• Parameter 2 - Adresse an die Zuordnungsstapelablaufverfolgung. Führen Sie dps-Adresse< aus, um den Zuordnungsstapel >anzuzeigen.
• Parameter 3 - Adresse des Besitzer-DLL-Namens. Führen Sie die Du-Adresse <> aus, um den DLL-Namen zu lesen.
• Parameter 4 - Base der Besitzer-DLL. Führen Sie .reload <dll_name> = <Adresse> aus, um die Besitzer-DLL neu zu laden. Verwenden Sie "lm", um weitere Informationen zu den geladenen und entladenen Modulen zu erhalten.

• Testschicht: Leck
• Stopp-ID: ZUTEILUNG
• Stoppcode: 0x900
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Ein HANDLE wurde geleert.

Dieser Stopp wird generiert, wenn die Besitzer-DLL des Handles während der Besitzerressourcen dynamisch entladen wurde. Führen Sie zum Debuggen dieses Stopps den Parameter !htrace1 aus, um zusätzliche Informationen zum Handle abzurufen.

• Parameter 1 - Wert des durchleckten Ziehpunkts. Führen Sie das !htrace-Handle <> aus, um zusätzliche Informationen zum Handle abzurufen, wenn die Handle-Ablaufverfolgung aktiviert ist.
• Parameter 2 - Adresse an die Zuordnungsstapelablaufverfolgung. Führen Sie dps-Adresse< aus, um den Zuordnungsstapel >anzuzeigen.
• Parameter 3 - Adresse des Besitzer-DLL-Namens. Führen Sie die Du-Adresse <> aus, um den DLL-Namen zu lesen.
• Parameter 4 - Base der Besitzer-DLL. Führen Sie .reload <dll_name> = <Adresse> aus, um die Besitzer-DLL neu zu laden. Verwenden Sie "lm", um weitere Informationen zu den geladenen und entladenen Modulen zu erhalten.

• Testschicht: Leck
• Stopp-ID: GRIFF
• Stoppcode: 0x901
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Ein HKEY wurde geleert.

Dieser Stopp wird generiert, wenn die Besitzer-DLL des Registrierungsschlüssels während des Besitzes von Ressourcen dynamisch entladen wurde.

• Parameter 1 - Wert des geleckten HKEY.
• Parameter 2 - Adresse an die Zuordnungsstapelablaufverfolgung. Führen Sie dps-Adresse< aus, um den Zuordnungsstapel >anzuzeigen.
• Parameter 3 - Adresse des Besitzer-DLL-Namens. Führen Sie die Du-Adresse <> aus, um den DLL-Namen zu lesen.
• Parameter 4 - Base der Besitzer-DLL. Führen Sie .reload <dll_name> = <Adresse> aus, um die Besitzer-DLL neu zu laden. Verwenden Sie "lm", um weitere Informationen zu den geladenen und entladenen Modulen zu erhalten.

• Testschicht: Leck
• Stopp-ID: REGISTRIERUNG
• Stoppcode: 0x902
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Eine virtuelle Reservierung wurde geleert.

Dieser Stopp wird generiert, wenn die Besitzer-DLL der virtuellen Reservierung dynamisch entladen wurde, während Ressourcen besitzen.

• Parameter 1 - Durchleckige Reservierungsadresse.
• Parameter 2 - Adresse an die Zuordnungsstapelablaufverfolgung. Führen Sie dps-Adresse< aus, um den Zuordnungsstapel >anzuzeigen.
• Parameter 3 - Adresse des Besitzer-DLL-Namens. Führen Sie die Du-Adresse <> aus, um den DLL-Namen zu lesen.
• Parameter 4 - Base der Besitzer-DLL. Führen Sie .reload <dll_name> = <Adresse> aus, um die Besitzer-DLL neu zu laden. Verwenden Sie "lm", um weitere Informationen zu den geladenen und entladenen Modulen zu erhalten.

• Testschicht: Leck
• Stopp-ID: VIRTUAL_RESERVATION
• Stoppcode: 0x903
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Ein BSTR wurde geleeckt.

Dieser Stopp wird generiert, wenn die Besitzer-DLL der SysString während der Besitzerressourcen dynamisch entladen wurde.

• Parameter 1 - Adresse des geleeckten BSTR. Führen Sie !heap -p -a <Adresse> aus, um zusätzliche Informationen zur Zuordnung zu erhalten.
• Parameter 2 - Adresse an die Zuordnungsstapelablaufverfolgung. Führen Sie dps-Adresse< aus, um den Zuordnungsstapel >anzuzeigen.
• Parameter 3 - Adresse des Besitzer-DLL-Namens. Führen Sie die Du-Adresse <> aus, um den DLL-Namen zu lesen.
• Parameter 4 - Base der Besitzer-DLL. Führen Sie .reload <dll_name> = <Adresse> aus, um die Besitzer-DLL neu zu laden. Verwenden Sie "lm", um weitere Informationen zu den geladenen und entladenen Modulen zu erhalten.

• Testschicht: Leck
• Stopp-ID: SYSSTRING
• Stoppcode: 0x904
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Die Registrierung einer Energiebenachrichtigung wurde nicht aufgehoben.

Dieser Stopp wird generiert, wenn die DLL für die Energiebenachrichtigung registriert und dynamisch entladen wurde, ohne die Registrierung aufzuheben.

• Parameter 1 - Adresse der Power Notification-Registrierung.
• Parameter 2 - Adresse an die Registrierungsstapelablaufverfolgung. Führen Sie dps-Adresse< aus, um den Zuordnungsstapel >anzuzeigen.
• Parameter 3 - Adresse des Besitzer-DLL-Namens. Führen Sie die Du-Adresse <> aus, um den DLL-Namen zu lesen.
• Parameter 4 - Base der Besitzer-DLL. Führen Sie .reload <dll_name> = <Adresse> aus, um die Besitzer-DLL neu zu laden. Verwenden Sie "lm", um weitere Informationen zu den geladenen und entladenen Modulen zu erhalten.

• Testschicht: Leck
• Stopp-ID: POWER_NOTIFICATION
• Stoppcode: 0x905
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Sperrt Details beenden

Thread kann keinen kritischen Abschnitt besitzen.

Dieser Stopp wird generiert, wenn ein Thread (Thread-ID ist Parameter1) beendet, angehalten oder sich in einem Zustand befindet (Arbeitsthread hat eine Arbeitsaufgabe beendet), in der er keinen kritischen Abschnitt enthalten kann. Der aktuelle Thread ist der Schuldige. Verwenden Sie zum Debuggen dieses Stopps die folgenden Debuggerbefehle:

• kb – zum Abrufen der aktuellen Stapelablaufverfolgung. Wenn der aktuelle Thread der Besitzer des kritischen Abschnitts ist, wird "ExitThread" wahrscheinlich aufgerufen. Der aktuelle Thread sollte den kritischen Abschnitt vor dem Beenden freigegeben haben. Wenn der aktuelle Thread TerminateThread oder SuspendThread aufruft, sollte dies für einen Thread, der einen kritischen Abschnitt enthält, nicht ausführen.
• !cs -s <Parameter2> – Dumpinformationen zu diesem kritischen Abschnitt.
• ln parameter2> – zum Anzeigen von Symbolen in der Nähe der Adresse des kritischen < Abschnitts. Dies sollte dazu beitragen, den geleckten kritischen Abschnitt zu identifizieren.
• dps parameter4> – um die Stapelablaufverfolgung für diese initialisierung des kritischen Abschnitts abzubilden < .

• Parameter 1 - Thread-ID.
• Parameter 2 - Kritische Abschnittsadresse.
• Parameter 3 - Kritischer Abschnitt Debuginformationsadresse.
• Parameter 4 - Kritische Abschnittsinitialisierungsstapelablaufverfolgung.

• Testschicht: Schlösser
• Stopp-ID: EXIT_THREAD_OWNS_LOCK
• Stoppcode: 0x200
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Entladen von DLL-Dateien, die einen aktiven kritischen Abschnitt enthalten.

Dieser Stopp wird generiert, wenn eine DLL eine globale Variable mit einem kritischen Abschnitt enthält und die DLL entladen wird, der kritische Abschnitt jedoch nicht gelöscht wurde. Verwenden Sie zum Debuggen dieses Stopps die folgenden Debuggerbefehle:

• du <parameter3> - to dump the name of the culprit DLL.
• .reload dllname oder .reload dllname = <parameter4> - um die Symbole für diese DLL neu zu laden.
• !cs -s <Parameter1> – Dumpinformationen zu diesem kritischen Abschnitt.
• ln parameter1> – zum Anzeigen von Symbolen in der Nähe der Adresse des kritischen < Abschnitts. Dies sollte dazu beitragen, den geleckten kritischen Abschnitt zu identifizieren.
• dps parameter2> – zum Abbilden < der Stapelablaufverfolgung für diese kritische Abschnittsinitialisierung.

• Parameter 1 - Kritische Abschnittsadresse.
• Parameter 2 - Kritische Abschnittsinitialisierungsstapelablaufverfolgung.
• Parameter 3 - DLL-Name-Adresse.
• Parameter 4 - DLL-Basisadresse.

• Testschicht: Schlösser
• Stopp-ID: LOCK_IN_UNLOADED_DLL
• Stoppcode: 0x201
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Freigeben eines Heapblocks, der einen aktiven kritischen Abschnitt enthält.

Dieser Stopp wird generiert, wenn eine Heap-Zuordnung einen kritischen Abschnitt enthält, die Zuordnung freigegeben wird und der kritische Abschnitt nicht gelöscht wurde. Verwenden Sie zum Debuggen dieses Stopps die folgenden Debuggerbefehle:

• !cs -s <(Parameter1)> – Dumpinformationen zu diesem kritischen Abschnitt.
• ln parameter1> – zum Anzeigen von Symbolen in der Nähe der Adresse des kritischen < Abschnitts. Dies sollte dazu beitragen, den geleckten kritischen Abschnitt zu identifizieren.
• dps parameter2> – zum Abbilden < der Stapelablaufverfolgung für diese kritische Abschnittsinitialisierung.
• < Parameter3> und <Parameter4> können helfen zu verstehen, wo dieser Heap-Block zugeordnet wurde (die Größe der Zuordnung ist wahrscheinlich signifikant).

• Parameter 1 - Kritische Abschnittsadresse.
• Parameter 2 - Kritische Abschnittsinitialisierungsstapelablaufverfolgung.
• Parameter 3 - Heap-Blockadresse.
• Parameter 4 - Heap-Blockgröße.

• Testschicht: Schlösser
• Stopp-ID: LOCK_IN_FREED_HEAP
• Stoppcode: 0x202
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Doppelt initialisierter oder beschädigter kritischer Abschnitt.

In der Regel wird dieser Stopp generiert, wenn ein kritischer Abschnitt mehrmals initialisiert wurde. In diesem Fall sind Parameter3 und Parameter4 die Stapelablaufverfolgungsadressen für zwei dieser Initialisierungen. Manchmal ist es möglich, diesen Stopp zu erhalten, wenn der kritische Abschnitt oder seine Debuginformationsstruktur beschädigt wurde. In diesem zweiten Fall ist es möglich, dass Parameter3 und Parameter4 ungültig und nutzlos sind. So debuggen Sie diesen Stopp:

• !cs -s -d <Parameter2> – Dumpinformationen zu diesem kritischen Abschnitt.
• ln parameter1> – zum Anzeigen von Symbolen in der Nähe der Adresse des kritischen < Abschnitts. Dies kann dazu beitragen, den kritischen Abschnitt zu identifizieren, wenn es sich um eine globale Variable handelt.
• dps parameter3> and dps <<parameter4> - to identify the two code paths for initializing this critical section.

• Parameter 1 - Kritische Abschnittsadresse.
• Parameter 2 - Adresse der Debuginformationsstruktur, die in der aktiven Liste gefunden wurde.
• Parameter 3 - First initialization stack trace.
• Parameter 4 - Second initialization stack trace.

• Testschicht: Schlösser
• Stopp-ID: LOCK_DOUBLE_INITIALIZE
• Stoppcode: 0x203
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Freier Arbeitsspeicher, der einen aktiven kritischen Abschnitt enthält.

Dieser Stopp wird generiert, wenn der Speicher, der einen kritischen Abschnitt enthält, freigegeben wurde, der kritische Abschnitt jedoch nicht mithilfe von DeleteCriticalSection gelöscht wurde. Verwenden Sie zum Debuggen dieses Stopps die folgenden Debuggerbefehle:</p.>

• !cs -s -d <Parameter2> – Dumpinformationen zu diesem kritischen Abschnitt.
• dps parameter3> – um den Codepfad für die Initialisierung dieses kritischen Abschnitts < zu identifizieren.

In den meisten Fällen erkennt der Sperrprüfer sofort verlorene kritische Abschnitte, die in einer Heap-Zuordnung, einem DLL-Bereich, einer virtuellen Speicherzuweisung oder einem mapViewOfFile zugeordneten Speicherbereich enthalten sind, und gibt in diesen Fällen verschiedene Stopps aus. Es gibt also nur sehr wenige Fälle für diesen Prüferstopp. Die Sperre muss sich in einem Speicherbereich befinden, der vom Kernelmoduscode freigegeben oder von APIs wie VirtualFreeEx prozessübergreifend freigegeben wird. In der Regel tritt dieser Stopp auf, wenn ein vorheriger Stopp (z. B. LOCK_IN_FREED_HEAP oder LOCK_IN_UNLOADED_DLL) fortgesetzt wurde, indem er in der Debuggerkonsole auf "g" trifft.

• Parameter 1 - Kritische Abschnittsadresse.
• Parameter 2 - Kritischer Abschnitt Debuginformationsadresse.
• Parameter 3 - Kritische Abschnittsinitialisierungsstapelablaufverfolgung.
• Parameter 4 – nicht verwendet.

• Testschicht: Schlösser
• Stopp-ID: LOCK_IN_FREED_MEMORY
• Stoppcode: 0x204
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Beschädigter kritischer Abschnitt.

Dieser Stopp wird generiert, wenn das DebugInfo-Feld des kritischen Abschnitts auf freien Speicher verweist. In der Regel befindet sich eine andere gültige DebugInfo-Struktur in der aktiven kritischen Abschnittsliste. Ohne Beschädigung sollten die beiden Zeiger identisch sein. Verwenden Sie zum Debuggen dieses Stopps die folgenden Debuggerbefehle:

• !cs -s -d <Parameter3> – Dumpinformationen zu diesem kritischen Abschnitt basierend auf dem aktuellen Inhalt der Debuginformationsstruktur in der aktiven Liste (diese Struktur ist selten beschädigt, sodass diese Informationen normalerweise vertrauenswürdig sind).
• !cs -s <Parameter1> – Dumpinformationen zu diesem kritischen Abschnitt basierend auf dem aktuellen Inhalt der kritischen Abschnittsstruktur (die Struktur ist bereits beschädigt, sodass diese Informationen manchmal NICHT vertrauenswürdig sind).
• dps parameter4> – um den Codepfad für die Initialisierung dieses kritischen Abschnitts < zu identifizieren.

Dump the critical section at address <parameter1> and look for the corruption pattern. Mit guten Symbolen für ntdll.dl können Sie die folgenden Befehle verwenden:

• dt ntdll!_RTL_CRITICAL_SECTION LOCK_ADDRESS
• dt ntdll!_RTL_CRITICAL_SECTION_DEBUG DEBUG_ADDRESS

• Parameter 1 - Kritische Abschnittsadresse.
• Parameter 2 - Ungültige Debuginformationsadresse dieses kritischen Abschnitts.
• Parameter 3 - Adresse der Debuginformationen, die in der aktiven Liste gefunden wurden.
• Parameter 4 - Initialisierungsstapelablaufverfolgung.

• Testschicht: Schlösser
• Stopp-ID: LOCK_CORRUPTED
• Stoppcode: 0x205
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Ungültiger Thread für den Besitzer des kritischen Abschnitts.

Dieser Stopp wird generiert, wenn die Besitzerthread-ID im aktuellen Kontext ungültig ist. So debuggen Sie diesen Stopp:

• !cs -s <Parameter1> – Dumpinformationen zu diesem kritischen Abschnitt.
• ln parameter1> – zum Anzeigen von Symbolen in der Nähe der Adresse des kritischen < Abschnitts. Dies sollte dazu beitragen, den kritischen Abschnitt zu identifizieren.

• Parameter 1 - Kritische Abschnittsadresse.
• Parameter 2 - Besitzerthread.
• Parameter 3 - Besitzerthread erwartet.
• Parameter 4 - Wichtige Abschnitt Debuginformationsadresse.

• Testschicht: Schlösser
• Stopp-ID: LOCK_INVALID_OWNER
• Stoppcode: 0x206
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Ungültige Anzahl kritischer Abschnitts rekursion.

Dieser Stopp wird generiert, wenn das Rekursionsanzahlfeld der kritischen Abschnittsstruktur im aktuellen Kontext ungültig ist. So debuggen Sie diesen Stopp:

• !cs -s <Parameter1> – Dumpinformationen zu diesem kritischen Abschnitt.
• ln parameter1> – zum Anzeigen von Symbolen in der Nähe der Adresse des kritischen < Abschnitts. Dies sollte dazu beitragen, den kritischen Abschnitt zu identifizieren.

• Parameter 1 - Kritische Abschnittsadresse.
• Parameter 2 - Rekursionsanzahl.
• Parameter 3 - Rekursionsanzahl erwartet.
• Parameter 4 - Wichtige Abschnitt Debuginformationsadresse.

• Testschicht: Schlösser
• Stopp-ID: LOCK_INVALID_RECURSION_COUNT
• Stoppcode: 0x207
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Löschen eines kritischen Abschnitts mit ungültiger Sperranzahl.

Dieser Stopp wird generiert, wenn ein kritischer Abschnitt im Besitz eines Threads ist, wenn er gelöscht wird oder wenn der kritische Abschnitt nicht initialisiert ist. So debuggen Sie diesen Stopp:

• !cs -s <Parameter1> – Dumpinformationen zu diesem kritischen Abschnitt. Wenn der besitzereigene Thread 0 ist, wurde der kritische Abschnitt nicht initialisiert.
• ln parameter1> – zum Anzeigen von Symbolen in der Nähe der Adresse des kritischen < Abschnitts. Dies sollte dazu beitragen, den kritischen Abschnitt zu identifizieren.

• Parameter 1 - Kritische Abschnittsadresse.
• Parameter 2 - Lock count.
• Parameter 3 - Anzahl der Sperren erwartet.
• Parameter 4 - Besitzerthread.

• Testschicht: Schlösser
• Stopp-ID: LOCK_INVALID_LOCK_COUNT
• Stoppcode: 0x208
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Kritischer Abschnitt überlastet oder beschädigt.

Dieser Stopp wird generiert, wenn ein kritischer Abschnitt mehrmals freigegeben wird, als der aktuelle Thread sie abgerufen hat. So debuggen Sie diesen Stopp:

• !cs -s <Parameter1> – Dumpinformationen zu diesem kritischen Abschnitt.
• !cs -s -d <Parameter4> – Dumpinformationen zu diesem kritischen Abschnitt.
• ln parameter1> – zum Anzeigen von Symbolen in der Nähe der Adresse des kritischen < Abschnitts. Dies sollte dazu beitragen, den kritischen Abschnitt zu identifizieren.

• Parameter 1 - Kritische Abschnittsadresse.
• Parameter 2 - Lock count.
• Parameter 3 - Anzahl der Sperren erwartet.
• Parameter 4 - Wichtige Abschnitt Debuginformationsadresse.

• Testschicht: Schlösser
• Stopp-ID: LOCK_OVER_RELEASED
• Stoppcode: 0x209
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Kritischer Abschnitt nicht initialisiert.

Dieser Stopp wird generiert, wenn ein kritischer Abschnitt verwendet wird, ohne initialisiert zu werden oder nachdem er gelöscht wurde. So debuggen Sie diesen Stopp:

• ln parameter1> – zum Anzeigen von Symbolen in der Nähe der Adresse des kritischen < Abschnitts. Dies sollte dazu beitragen, den kritischen Abschnitt zu identifizieren.

• Parameter 1 - Kritische Abschnittsadresse.
• Parameter 2 - Wichtige Abschnitt Debuginformationsadresse.
• Parameter 3 - Nicht verwendet.
• Parameter 4 – nicht verwendet.

• Testschicht: Schlösser
• Stopp-ID: LOCK_NOT_INITIALIZED
• Stoppcode: 0x210
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Der kritische Abschnitt wurde bereits initialisiert.

Dieser Stopp wird generiert, wenn ein kritischer Abschnitt vom aktuellen Thread erneut initialisiert wird. So debuggen Sie diesen Stopp:

• !cs -s <Parameter1> oder !cs -s -d <Parameter2> – Dumpinformationen zu diesem kritischen Abschnitt.
• ln parameter1 – zum Anzeigen von Symbolen in der Nähe der Adresse des kritischen <Abschnitts.> Dies kann dazu beitragen, den kritischen Abschnitt zu identifizieren, wenn es sich um eine globale Variable handelt.
• dps parameter3 – um den Codepfad für die erste Initialisierung dieses kritischen Abschnitts <zu identifizieren.>
• kb - um die aktuelle Stapelablaufverfolgung anzuzeigen, die diesen kritischen Abschnitt neu initialisiert.

• Parameter 1 - Kritische Abschnittsadresse.
• Parameter 2 - Wichtige Abschnitt Debuginformationsadresse.
• Parameter 3 - First initialization stack trace. Verwenden von Dps zum Abbilden, wenn kein NULL-Wert vorhanden ist
• Parameter 4 – nicht verwendet.

• Testschicht: Schlösser
• Stopp-ID: LOCK_ALREADY_INITIALIZED
• Stoppcode: 0x211
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Freigeben des virtuellen Speichers, der einen aktiven kritischen Abschnitt enthält.

Dieser Stopp wird generiert, wenn der aktuelle Thread VirtualFree für einen Speicherblock aufruft, der einen aktiven kritischen Abschnitt enthält. Die Anwendung sollte "DeleteCriticalSection" in diesem kritischen Abschnitt aufrufen, bevor dieser Speicher freigegeben wird.

• kb – um die aktuelle Stapelablaufverfolgung anzuzeigen, die VirtualFree aufruft. Die wahrscheinliche Ursache ist die DLL, die VirtualFree aufruft.
• !cs -s <Parameter1> – Dumpinformationen zu diesem kritischen Abschnitt.
• dps parameter2> – um den Codepfad für die Initialisierung dieses kritischen Abschnitts < zu identifizieren.

• Parameter 1 - Kritische Abschnittsadresse.
• Parameter 2 - Kritische Abschnittsinitialisierungsstapelablaufverfolgung.
• Parameter 3 - Speicherblockadresse.
• Parameter 4 - Speicherblockgröße.

• Testschicht: Schlösser
• Stopp-ID: LOCK_IN_FREED_VMEM
• Stoppcode: 0x212
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Aufheben der Zuordnung des Speicherbereichs, der einen aktiven kritischen Abschnitt enthält.

Dieser Stopp wird generiert, wenn der aktuelle Thread UnmapViewOfFile für einen Speicherblock aufruft, der einen aktiven kritischen Abschnitt enthält. Die Anwendung sollte "DeleteCriticalSection" in diesem kritischen Abschnitt aufrufen, bevor die Zuordnung dieses Speichers deaktiviert wird.

• kb - um die aktuelle Stapelablaufverfolgung anzuzeigen, die unmapViewOfFile aufruft. Die wahrscheinliche Ursache ist die DLL, die UnmapViewOfFile aufruft.
• !cs -s <Parameter1> – Dumpinformationen zu diesem kritischen Abschnitt.
• dps parameter2> – um den Codepfad für die Initialisierung dieses kritischen Abschnitts < zu identifizieren.

• Parameter 1 - Kritische Abschnittsadresse.
• Parameter 2 - Kritische Abschnittsinitialisierungsstapelablaufverfolgung.
• Parameter 3 - Speicherblockadresse.
• Parameter 4 - Speicherblockgröße.

• Testschicht: Schlösser
• Stopp-ID: LOCK_IN_UNMAPPED_MEM
• Stoppcode: 0x213
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Der aktuelle Thread besitzt keine kritischen Abschnitte.

Dieser Stopp wird generiert, wenn der aktuelle Thread LeaveCriticalSection aufruft, aber gemäß dem internen Verifier Bookkeeping keinen kritischen Abschnitt besitzt. Wenn \<parameter2\> null ist, ist dies wahrscheinlich ein Fehler im aktuellen Thread. Es versucht entweder, einen kritischen Abschnitt zu verlassen, den er nicht eingegeben hat, oder vielleicht wird "LeaveCriticalSection" mehrmals aufgerufen als "EnterCriticalSection" für denselben kritischen Abschnitt. Wenn \<parameter2\> nicht null ist (es handelt sich um eine negative ganze Zahl), sind die internen Prüfdatenstrukturen wahrscheinlich beschädigt.

• Parameter 1 - Kritische Abschnittsadresse.
• Parameter 2 - Anzahl der kritischen Abschnitte im Besitz des aktuellen Threads.
• Parameter 3 - Nicht verwendet
• Parameter 4 - Nicht verwendet

• Testschicht: Schlösser
• Stopp-ID: THREAD_NOT_LOCK_OWNER
• Stoppcode: 0x214
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Verwenden eines kritischen Abschnitts, der für eine andere DLL privat ist.

Dieser Stopp wird generiert, wenn der aktuelle Thread versucht, eine private Sperre zu verwenden, die sich in einer anderen DLL befindet. Beispielsweise versucht a.dll, einen kritischen Abschnitt einzugeben, der in ntdll.dlldefiniert ist. Private Sperren können nicht über DLLs hinweg verwendet werden.

• Parameter 1 - Kritische Abschnittsadresse.
• Parameter 2 - Nicht verwendet.
• Parameter 3 - Nicht verwendet
• Parameter 4 - Nicht verwendet

• Testschicht: Schlösser
• Stopp-ID: LOCK_PRIVATE
• Stoppcode: 0x215
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

SRWLock Stop Details

Die SRW-Sperre wird nicht initialisiert.

Dieser Stopp wird generiert, wenn ein Thread versucht, die SRW-Sperre (Param1) zu verwenden, die nicht initialisiert ist. Verwenden Sie zum Debuggen dieses Stopps "kb", um die aktuelle Stapelablaufverfolgung abzurufen. Hier wird die SRW-Sperre verwendet. Die SRW-Sperre sollte mithilfe von "InitializeSRWLock" initialisiert werden, bevor sie verwendet werden kann.

• Parameter 1 -SRW-Sperre 
• Parameter 2 - Nicht verwendet
• Parameter 3 - Nicht verwendet
• Parameter 4 - Nicht verwendet

• Testschicht: SRWLock
• Stopp-ID: NOT_INITIALIZED
• Stoppcode: 0x250
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Die SRW-Sperre wurde bereits initialisiert.

Dieser Stopp wird generiert, wenn die SRW-Sperre (Param1) neu initialisiert wird. Wenn die SRW-Sperre aktiv von anderen Threads verwendet wird, führt die erneute Initialisierung der Sperre zu unvorhersehbaren Verhaltensweisen durch die Anwendung, einschließlich Hängen und Abstürze. Die Initialisierungsstapelüberwachung kann einen Erwerb anzeigen, wenn die SRW-Sperre statisch initialisiert wurde. So debuggen Sie diesen Stopp:

• kb – zum Abrufen der aktuellen Stapelablaufverfolgung. Hier wird die SRW-Sperre neu initialisiert.
• dps <parameter3> – zum Abrufen der SRW-Sperrinitialisierungsstapelüberwachung. Diese Stapelablaufverfolgung kann einen Abrufen anzeigen, wenn die Sperre statisch initialisiert wurde.

• Parameter 1 -SRW-Sperre 
• Parameter 2 - ThreadId des Threads, der die SRW-Sperre initialisiert hat.
• Parameter 3 - Adresse der Initialisierungsstapelablaufverfolgung. Verwenden Sie dps-Adresse<>, um zu sehen, wo die SRW-Sperre initialisiert wurde.
• Parameter 4 - Nicht verwendet

• Testschicht: SRWLock
• Stopp-ID: ALREADY_INITIALIZED
• Stoppcode: 0x251
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Nicht übereinstimmende Acquire-Release auf der SRW-Sperre.

Dieser Stopp wird generiert, wenn die SRW-Sperre (Param1) mit einer falschen Release-API veröffentlicht wird. Wenn die SRW-Sperre für den freigegebenen Zugriff erworben wurde und mit der exklusiven Release-API freigegeben wird oder die SRW-Sperre für exklusiven Zugriff erworben wurde und mit der freigegebenen Release-API freigegeben wird. Dies kann zu unvorhersehbaren Verhaltensweisen durch die Anwendung führen, einschließlich Blockaden und Abstürze. So debuggen Sie diesen Stopp:

• kb – zum Abrufen der aktuellen Stapelablaufverfolgung. Hier wird die SRW-Sperre mit der falschen API freigegeben.
• dps <parameter3> – zum Abrufen der SRW-Sperrstapelablaufverfolgung.

• Parameter 1 -SRW-Sperre 
• Parameter 2 - ThreadId des Threads, der die SRW-Sperre abgerufen hat.
• Parameter 3 - Adresse der Abrufenstapelablaufverfolgung. Verwenden Sie dps-Adresse<>, um zu sehen, wo die SRW-Sperre erworben wurde.
• Parameter 4 - Nicht verwendet

• Testschicht: SRWLock
• Stopp-ID: MISMATCHED_ACQUIRE_RELEASE
• Stoppcode: 0x252
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Die SRW-Sperre wird rekursiv vom gleichen Thread abgerufen.

Dieser Stopp wird generiert, wenn die SRW-Sperre (Param1) rekursiv vom gleichen Thread abgerufen wird. Dies führt zu einem Deadlock, und der Thread würde unbegrenzt blockiert. Rekursives Erwerben einer SRW-Sperre im exklusiven Modus führt zu einem Deadlock. Rekursives Abrufen einer SRW-Sperre im freigegebenen Modus führt zu einem Deadlock, wenn ein Thread auf exklusiven Zugriff wartet. Betrachten Sie das folgende Beispiel: - Thread A erwirbt die SRW-Sperre im freigegebenen Modus - Thread B versucht, die SRW-Sperre im exklusiven Modus zu erwerben und wartet - Thread A versucht, die SRW-Sperre im freigegebenen Modus rekursiv zu erwerben. Dies wird erfolgreich sein, solange kein exklusiver Waiter vorhanden ist (in diesem Fall B). Da SRW-Sperren keine Writer-Starvation aufweisen, wartet Thread A hinter Thread B. Thread B wartet nun auf Thread A, das wiederum auf Thread B wartet, was zu einer Zirkelwarte und damit zu einem Deadlock führt. So debuggen Sie diesen Stopp:

• kb – zum Abrufen der aktuellen Stapelablaufverfolgung. Hier wird die SRW-Sperre rekursiv erworben.
• dps <parameter2> – zum Abrufen der Stapelablaufverfolgung für den ersten Erwerb.

• Parameter 1 -SRW-Sperre 
• Parameter 2 - Address of the first acquire stack trace. Verwenden Sie dps-Adresse<>, um zu sehen, wo die SRW-Sperre erworben wurde.
• Parameter 3 - Nicht verwendet
• Parameter 4 - Nicht verwendet

• Testschicht: SRWLock
• Stopp-ID: RECURSIVE_ACQUIRE
• Stoppcode: 0x253
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Der Thread, der beendet oder beendet wird, besitzt eine SRW-Sperre.

Dieser Stopp wird generiert, wenn der Thread (Param2), der die SRW-Sperre (Param1) besitzt, beendet oder beendet wird. Dies führt zu einer verwaisten SRW-Sperre, und die Threads, die versuchen, diese Sperre zu erwerben, würden unbegrenzt blockiert. So debuggen Sie seinen Stopp:

• kb – zum Abrufen der aktuellen Stapelablaufverfolgung. Hier wird der Thread beendet oder beendet.
• dps <parameter3> – zum Abrufen der SRW-Sperrstapelablaufverfolgung.

• Parameter 1 -SRW-Sperre 
• Parameter 2 - ThreadId des Threads, der beendet oder beendet wird.
• Parameter 3 - Adresse der Abrufenstapelablaufverfolgung. Verwenden Sie dps-Adresse<>, um zu sehen, wo die SRW-Sperre erworben wurde.
• Parameter 4 - Nicht verwendet

• Testschicht: SRWLock
• Stopp-ID: EXIT_THREAD_OWNS_LOCK
• Stoppcode: 0x254
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Die zu veröffentlichende SRW-Sperre wurde von diesem Thread nicht abgerufen.

Dieser Stopp wird generiert, wenn die SRW-Sperre (Param1) vom Thread (Param2) freigegeben wird, der die Sperre nicht erworben hat. Dies stellt eine schlechte Programmierpraxis dar, die schwer zu finden ist und zu unvorhersehbaren Verhaltensweisen durch die Anwendung führen kann. So debuggen Sie diesen Stopp:

• kb – zum Abrufen der aktuellen Stapelablaufverfolgung. Hier gibt der Thread die SRW-Sperre frei, die er nicht erworben hat.
• dps <parameter4> – zum Abrufen der SRW-Sperrstapelablaufverfolgung.

• Parameter 1 -SRW-Sperre 
• Parameter 2 - Current ThreadId.
• Parameter 3 - ThreadId des Threads, der die SRW-Sperre abgerufen hat.
• Parameter 4 - Adresse der Abrufenstapelablaufverfolgung. Verwenden Sie dps-Adresse<>, um zu sehen, wo die SRW-Sperre erworben wurde.

• Testschicht: SRWLock
• Stopp-ID: INVALID_OWNER
• Stoppcode: 0x255
• Schweregrad: Warnung
• Einmaliger Fehler: 
• Fehlerbericht: Keine
• Protokolldatei: ja
• Backtrace erstellen: Ja

Der freizugebende Speicher enthält eine aktive SRW-Sperre.

Dieser Stopp wird generiert, wenn die freizugebende Speicheradresse (Param1) eine aktive SRW-Sperre enthält, die noch verwendet wird. Dies kann zu unvorhersehbaren Verhaltensweisen durch die Anwendung führen, einschließlich Abstürze und Blockaden. So debuggen Sie diesen Stopp:

• kb – zum Abrufen der aktuellen Stapelablaufverfolgung. Hier wird der Speicher freigegeben, der eine aktive SRW-Sperre enthält.
• dps <parameter4> – zum Abrufen der SRW-Sperrstapelablaufverfolgung.

• Parameter 1 -SRW-Sperre 
• Parameter 2 - Adresse des freizugebenden Speichers.
• Parameter 3 - ThreadId des Threads, der die SRW-Sperre abgerufen hat.
• Parameter 4 - Adresse der Abrufenstapelablaufverfolgung. Verwenden Sie dps-Adresse<>, um zu sehen, wo die SRW-Sperre erworben wurde.

• Testschicht: SRWLock
• Stopp-ID: IN_FREED_MEMORY
• Stoppcode: 0x256
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Die geladene DLL enthält eine aktive SRW-Sperre.

Dieser Stopp wird generiert, wenn die DLL, die entladen wird (Param2) eine aktive SRW-Sperre (Param1) enthält, die noch verwendet wird. Dies kann zu unvorhersehbaren Verhaltensweisen durch die Anwendung führen, einschließlich Abstürze und Blockaden. So debuggen Sie diesen Stopp:

• kb – zum Abrufen der aktuellen Stapelablaufverfolgung. Hier wird die DLL entladen, die eine aktive SRW-Sperre enthält.
• du <parameter2> – um den Namen der DLL zu finden, die entladen wird.
• dps <parameter4> – zum Abrufen der SRW-Sperrstapelablaufverfolgung.

• Parameter 1 -SRW-Sperre 
• Parameter 2 - Adresse des Namens der DLL, die entladen wird. Verwenden Sie "du <address> ", um den Namen anzuzeigen.
• Parameter 3 - ThreadId des Threads, der die SRW-Sperre abgerufen hat.
• Parameter 4 - Adresse der Abrufenstapelablaufverfolgung. Verwenden Sie dps-Adresse<>, um zu sehen, wo die SRW-Sperre erworben wurde.

• Testschicht: SRWLock
• Stopp-ID: IN_UNLOADED_DLL
• Stoppcode: 0x257
• Schweregrad: Warnung
• Einmaliger Fehler: 
• Fehlerbericht: Keine
• Protokolldatei: ja
• Backtrace erstellen: Ja

Details zum Speicherstopp

Freigeben des virtuellen Speicherblocks mit ungültiger Größe oder Startadresse.

Dieser Stopp wird generiert, wenn die App-Überprüfung ein VirtualFree oder eine DLL-Entladung mit einer ungültigen Startadresse oder Größe der Speicherzuweisung erkennt. Im Falle des Entladens der DLL bedeutet dies wahrscheinlich eine Speicherbeschädigung in der geladenen DLL-Liste. Um diesen Stopp zu debuggen, sehen Sie sich die aktuelle Stapelablaufverfolgung und die Speicheradresse und die Größe an, die gerade freigegeben werden soll, und versuchen Sie zu ermitteln, warum sie ungültig sind.

• Parameter 1 - Zuordnungsbasisadresse.
• Parameter 2 - Größe des Speicherbereichs.
• Parameter 3 - Nicht verwendet.
• Parameter 4 – nicht verwendet.

• Testschicht: Gedächtnis
• Stopp-ID: INVALID_FREEMEM
• Stoppcode: 0x600
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Falscher virtueller Alloc-Aufruf.

Dieser Stopp wird generiert, wenn der App-Verifier einen VirtualAlloc-Aufruf mit einer ungültigen Startadresse oder -größe der Speicherzuweisung erkennt. Um diesen Stopp zu debuggen, sehen Sie sich die aktuelle Stapelüberwachung (kb) und die Speicheradresse und -größe an, die zugeordnet werden soll, und versuchen Sie zu ermitteln, warum sie ungültig sind.

• Parameter 1 - Zeiger auf die Zuordnungsbasisadresse.
• Parameter 2 - Zeiger auf die Größe des Speicherbereichs.
• Parameter 3 - Nicht verwendet
• Parameter 4 - Nicht verwendet

• Testschicht: Gedächtnis
• Stopp-ID: INVALID_ALLOCMEM
• Stoppcode: 0x601
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Falscher Aufruf der Kartenansicht.

Dieser Stopp wird generiert, wenn der App-Verifier einen MapViewOfFile-Aufruf mit einer ungültigen Basisadresse oder -größe der Zuordnung erkennt. Um diesen Stopp zu debuggen, sehen Sie sich die aktuelle Stapelüberwachung (KB) und die Speicheradresse und -größe an, die zugeordnet werden soll, und versuchen, zu bestimmen, warum sie ungültig sind.

• Parameter 1 - Zeiger zum Zuordnen der Basisadresse.
• Parameter 2 - Zeiger zum Anzeigen der Größe.
• Parameter 3 - Nicht verwendet.
• Parameter 4 – nicht verwendet.

• Testschicht: Gedächtnis
• Stopp-ID: INVALID_MAPVIEW
• Stoppcode: 0x602
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Ungültige Adresse wird angefordert.

Dieser Stopp wird generiert, wenn der App-Verifier einen IsBadXXXPtr-Aufruf mit einer ungültigen Adresse (z. B. eine Kernelmodusadresse anstelle einer normalen Benutzermodusadresse) erkennt, damit der Speicherpuffer geprüft wird. Um diesen Stopp zu debuggen, sehen Sie sich die aktuelle Stapelablaufverfolgung (kb) an, und versuchen Sie zu ermitteln, warum der Aufrufer der IsBadXXXPtr-Funktion mit einer ungültigen Adresse endete. Oft ist die Adresse nur falsch, z. B. ein nicht initialisierter Zeiger. MSDN Library listet einige Gründe auf, warum Anwendungen die IsBadXXXPtr-APIs nicht verwenden sollten: In einer präemptiven Multitaskingumgebung ist es möglich, dass ein anderer Thread den Zugriff des Prozesses auf den getesteten Speicher ändert. Die Ableitung potenziell ungültiger Zeiger kann die Stapelerweiterung in anderen Threads deaktivieren. Ein Thread, der seinen Stapel erschöpft, wenn die Stapelerweiterung deaktiviert wurde, führt zum sofortigen Beenden des übergeordneten Prozesses ohne Popupfehlerfenster oder Diagnoseinformationen. Threads in einem Prozess werden erwartet, dass sie so zusammenarbeiten, dass man keinen Arbeitsspeicher freigibt, den die andere benötigt. Die Verwendung dieser Funktion führt nicht dazu, dass dies erforderlich ist. Wenn dies nicht geschehen ist, schlägt die Anwendung möglicherweise unvorhersehbar fehl. Aus all diesen Gründen empfehlen wir, diese APIs niemals zu verwenden.

• Parameter 1 - Startadresse.
• Parameter 2 - Speicherblockgröße.
• Parameter 3 - Ungültige Adresse.
• Parameter 4 – nicht verwendet.

• Testschicht: Gedächtnis
• Stopp-ID: PROBE_INVALID_ADDRESS
• Stoppcode: 0x603
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Freier Arbeitsspeicher wird probieren.

Dieser Stopp wird generiert, wenn der App-Verifier einen IsBadXXXPtr-Aufruf für eine freie Speicherzuweisung erkennt. Dies ist sehr schlecht, da es möglich ist, dass dieser Speicher in einigen anderen Fällen bereits für eine andere Zuordnung wiederverwendet wurde. Da der aktuelle Codepfad (kb) nicht über diesen Speicher verfügt, könnte es dazu führen, dass der Speicher einer anderen Person beschädigt wird, was katastrophale Auswirkungen hat. Um diesen Stopp zu debuggen, sehen Sie sich die aktuelle Stapelablaufverfolgung (kb) an und versuchen, zu ermitteln, warum der Aufrufer der IsBadXXXPtr-Funktion zu einem freien Arbeitsspeicher gelangt ist. Die Adresse könnte einfach falsch (z. B. nicht initialisierter Zeiger) oder vielleicht bereits freizugebenden Speicher sein. Wenn der Speicher bereits von einer der VirtualFree- oder UnmapViewOfFile-APIs freigegeben wurde, sucht "!avrf -vs -a Parameter3" nach einem Protokoll von Stapelablaufverfolgungen der Codepfade, die diese Adresse zugeordnet/freigegeben haben, und zeigt diese Stapelablaufverfolgungen an, wenn sie verfügbar sind. Dies kann die Stapelablaufverfolgung anzeigen, die diesen Speicher freigegeben hat. Häufiger ist der Speicher eine bereits freigegebene Heap-Zuordnung. Um diese Möglichkeit zu überprüfen, sucht "!avrf -hp -a parameter3" nach einem Protokoll von Stapelablaufverfolgungen der Codepfade, die diese Adresse zugeordnet/freigegeben haben, und zeigt diese Stapelablaufverfolgungen an, wenn sie verfügbar sind. MSDN Library listet einige Gründe auf, warum Anwendungen die IsBadXXXPtr-APIs nicht verwenden sollten: In einer präemptiven Multitaskingumgebung ist es möglich, dass ein anderer Thread den Zugriff des Prozesses auf den getesteten Speicher ändert. Die Ableitung potenziell ungültiger Zeiger kann die Stapelerweiterung in anderen Threads deaktivieren. Ein Thread, der seinen Stapel erschöpft, wenn die Stapelerweiterung deaktiviert wurde, führt zum sofortigen Beenden des übergeordneten Prozesses ohne Popupfehlerfenster oder Diagnoseinformationen. Threads in einem Prozess werden erwartet, dass sie so zusammenarbeiten, dass man keinen Arbeitsspeicher freigibt, den die andere benötigt. Die Verwendung dieser Funktion führt nicht dazu, dass dies erforderlich ist. Wenn dies nicht geschehen ist, schlägt die Anwendung möglicherweise unvorhersehbar fehl. Aus all diesen Gründen empfehlen wir, diese APIs niemals zu verwenden.

• Parameter 1 - Startadresse.
• Parameter 2 - Speicherblockgröße.
• Parameter 3 - Adresse der freien Speicherseite.
• Parameter 4 – nicht verwendet.

• Testschicht: Gedächtnis
• Stopp-ID: PROBE_FREE_MEM
• Stoppcode: 0x604
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Probingen einer Schutzseite.

Dieser Stopp wird generiert, wenn die App-Prüfer einen IsBadXXXPtr-Aufruf für eine Speicherzuweisung erkennt, die mindestens eine GUARD_PAGE enthält. Dies ist sehr schlecht, da es sehr möglich ist, dass diese GUARD_PAGE das Ende des aktuellen Stapels eines Threads ist. Wie in der MSDN Library dokumentiert: Dereferencing potenziell ungültige Zeiger können die Stapelerweiterung in anderen Threads deaktivieren. Ein Thread, der seinen Stapel erschöpft, wenn die Stapelerweiterung deaktiviert wurde, führt zum sofortigen Beenden des übergeordneten Prozesses ohne Popupfehlerfenster oder Diagnoseinformationen. Um diesen Stopp zu debuggen, sehen Sie sich die aktuelle Stapelablaufverfolgung (kb) an, und versuchen Sie zu ermitteln, warum der Aufrufer der IsBadXXXPtr-Funktion eine GUARD_PAGE probiert hat. MSDN Library listet einige Gründe auf, warum Anwendungen die IsBadXXXPtr-APIs nicht verwenden sollten: In einer präemptiven Multitaskingumgebung ist es möglich, dass ein anderer Thread den Zugriff des Prozesses auf den getesteten Speicher ändert. Die Ableitung potenziell ungültiger Zeiger kann die Stapelerweiterung in anderen Threads deaktivieren. Ein Thread, der seinen Stapel erschöpft, wenn die Stapelerweiterung deaktiviert wurde, führt zum sofortigen Beenden des übergeordneten Prozesses ohne Popupfehlerfenster oder Diagnoseinformationen. Threads in einem Prozess werden erwartet, dass sie so zusammenarbeiten, dass man keinen Arbeitsspeicher freigibt, den die andere benötigt. Die Verwendung dieser Funktion führt nicht dazu, dass dies erforderlich ist. Wenn dies nicht geschehen ist, schlägt die Anwendung möglicherweise unvorhersehbar fehl. Aus all diesen Gründen empfehlen wir, diese APIs niemals zu verwenden.

• Parameter 1 - Startadresse.
• Parameter 2 - Speicherblockgröße.
• Parameter 3 - Adresse der Schutzseite.
• Parameter 4 – nicht verwendet.

• Testschicht: Gedächtnis
• Stopp-ID: PROBE_GUARD_PAGE
• Stoppcode: 0x605
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

NULL-Adresse wird probingen.

Dieser Stopp wird generiert, wenn der App-Verifier einen IsBadXXXPtr-Aufruf mit einer NULL-Adresse erkennt. Um diesen Stopp zu debuggen, sehen Sie sich die aktuelle Stapelablaufverfolgung (kb) an und versuchen, zu ermitteln, warum der Aufrufer der IsBadXXXPtr-Funktion mit der NULL-Adresse endete. Dies ist in der Regel das Zeichen einer Person, die den Rückgabewert einer der Speicherzuweisungsfunktionen nicht überprüft. Der folgende Code ist beispielsweise falsch:

void Use(PVOID p);

int main(void) {
    PVOID p;
    p = malloc(1024);
    Use(p);
    return 0;
}

void Use(PVOID p) {
    if (IsBadReadPtr(p)) {
        return;
    }
    // p is safe to be used here.
}

Dieser Code sollte wie folgt neu geschrieben werden:

int main (void) 
{ 
    PVOID p; 
    
    p = malloc (1024); 
    if (NULL == p)) { 
        return -1;
     } 

    Use (p); 

    return 0; 
} 

void Use (PVOID p) 
{
    // 
    // p is safe to be used here. 
    // 
} 

MSDN Library listet einige Gründe auf, warum Anwendungen die IsBadXXXPtr-APIs nicht verwenden sollten: In einer präemptiven Multitaskingumgebung ist es möglich, dass ein anderer Thread den Zugriff des Prozesses auf den getesteten Speicher ändert. Die Ableitung potenziell ungültiger Zeiger kann die Stapelerweiterung in anderen Threads deaktivieren. Ein Thread, der seinen Stapel erschöpft, wenn die Stapelerweiterung deaktiviert wurde, führt zum sofortigen Beenden des übergeordneten Prozesses ohne Popupfehlerfenster oder Diagnoseinformationen. Threads in einem Prozess werden erwartet, dass sie so zusammenarbeiten, dass man keinen Arbeitsspeicher freigibt, den die andere benötigt. Die Verwendung dieser Funktion führt nicht dazu, dass dies erforderlich ist. Wenn dies nicht geschehen ist, schlägt die Anwendung möglicherweise unvorhersehbar fehl. Aus all diesen Gründen empfehlen wir, diese APIs niemals zu verwenden.

• Parameter 1 - nicht verwendet.
• Parameter 2 - Nicht verwendet.
• Parameter 3 - Nicht verwendet.
• Parameter 4 – nicht verwendet.

• Testschicht: Gedächtnis
• Stopp-ID: PROBE_NULL
• Stoppcode: 0x606
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Speicherblock mit ungültiger Startadresse oder -größe wird probieren.

Dieser Stopp wird generiert, wenn der App-Verifier einen IsBadXXXPtr-Aufruf mit einer ungültigen Startadresse erkennt (z. B. eine Kernelmodusadresse anstelle einer normalen Benutzermodusadresse) oder eine ungültige Größe für den Speicherpuffer, der geprüft werden soll. Um diesen Stopp zu debuggen, sehen Sie sich die aktuelle Stapelablaufverfolgung (kb) an, und versuchen Sie zu ermitteln, warum der Aufrufer der IsBadXXXPtr-Funktion mit einer ungültigen Adresse oder Größe endete. Oft handelt es sich bei der Adresse oder Größe um einfache Scheine, z. B. nicht initialisierte Variablen. MSDN Library listet einige Gründe auf, warum Anwendungen die IsBadXXXPtr-APIs nicht verwenden sollten: In einer präemptiven Multitaskingumgebung ist es möglich, dass ein anderer Thread den Zugriff des Prozesses auf den getesteten Speicher ändert. Die Ableitung potenziell ungültiger Zeiger kann die Stapelerweiterung in anderen Threads deaktivieren. Ein Thread, der seinen Stapel erschöpft, wenn die Stapelerweiterung deaktiviert wurde, führt zum sofortigen Beenden des übergeordneten Prozesses ohne Popupfehlerfenster oder Diagnoseinformationen. Threads in einem Prozess werden erwartet, dass sie so zusammenarbeiten, dass man keinen Arbeitsspeicher freigibt, den die andere benötigt. Die Verwendung dieser Funktion führt nicht dazu, dass dies erforderlich ist. Wenn dies nicht geschehen ist, schlägt die Anwendung möglicherweise unvorhersehbar fehl. Aus all diesen Gründen empfehlen wir, diese APIs niemals zu verwenden.

• Parameter 1 - Startadresse.
• Parameter 2 - Speicherblockgröße.
• Parameter 3 - Nicht verwendet.
• Parameter 4 – nicht verwendet.

• Testschicht: Gedächtnis
• Stopp-ID: PROBE_INVALID_START_OR_SIZE
• Stoppcode: 0x607
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Entladen der DLL mit ungültiger Größe oder Startadresse.

Dieser Stopp wird generiert, wenn die App-Prüfer eine DLL-Entladung mit einer ungültigen Startadresse oder Größe des DLL-Speicherbereichs erkennt. Dies bedeutet wahrscheinlich eine Speicherbeschädigung innerhalb der internen ntdll.dll geladenen DLL-Liste.

• Parameter 1 - DLL-Speicherbasisadresse.
• Parameter 2 - DLL-Speicherbereichsgröße.
• Parameter 3 - DLL-Name-Adresse. Verwenden Sie "du", um es abzubilden.
• Parameter 4 – nicht verwendet.

• Testschicht: Gedächtnis
• Stopp-ID: INVALID_DLL_RANGE
• Stoppcode: 0x608
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Freigeben des Speicherblocks innerhalb des Stapeladressbereichs des aktuellen Threads.

Dieser Stopp wird generiert, wenn die App-Prüfer ein VirtualFree für einen Speicherblock erkennt, der tatsächlich Teil des Stapels des aktuellen Threads (!) ist. Um diesen Stopp zu debuggen, sehen Sie sich die aktuelle Stapelablaufverfolgung (kb) an und versuchen, zu verstehen, warum die Funktion, die VirtualFree aufgerufen hat, dachte, dass der Speicherblock dynamisch zugewiesen oder zugeordnet wurde, das aber tatsächlich Speicher aus dem Stapel zugeordnet war.

• Parameter 1 - Zuordnungsbasisadresse.
• Parameter 2 - Größe des Speicherbereichs.
• Parameter 3 - Stack Low Limit Address.
• Parameter 4 - Stack High Limit Address.

• Testschicht: Gedächtnis
• Stopp-ID: FREE_THREAD_STACK_MEMORY
• Stoppcode: 0x609
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Falscher FreeType-Parameter für den VirtualFree-Vorgang.

Dieser Stopp wird generiert, wenn die App-Prüfer ein VirtualFree mit einem falschen Wert für den FreeType-Parameter erkennt. Die beiden zulässigen Werte für diesen Parameter sind MEM_DECOMMIT und MEM_RELEASE. Wenn VirtualFree mit einem anderen Wert mit Ausnahme dieser beiden aufgerufen wird, kann VirtualFree den Arbeitsspeicher nicht freigeben. Um diesen Stopp zu debuggen, sehen Sie sich die aktuelle Stapelüberwachung (kb) an: Der Aufrufer von VirtualFree ist wahrscheinlich der Schuldige.

• Parameter 1 - Falscher Wert, der von der Anwendung verwendet wird.
• Parameter 2 - Richtiger Wert 1 erwartet.
• Parameter 3 - Richtiger Wert 2 erwartet.
• Parameter 4 – nicht verwendet.

• Testschicht: Gedächtnis
• Stopp-ID: INVALID_FREE_TYPE
• Stoppcode: 0x60A
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Versuchen Sie, virtuellen Speicherblock freizugeben, der bereits kostenlos ist.

Dieser Stopp wird generiert, wenn die App-Prüfer ein VirtualFree für eine adresse erkennt, die bereits kostenlos ist. Um diesen Stopp zu debuggen, sehen Sie sich die aktuelle Stapelablaufverfolgung (kb) an, und versuchen Sie zu ermitteln, warum der Speicher bereits frei ist, aber die Anwendung versucht, sie erneut freizugeben. '!avrf -vs -a Parameter1' sucht nach einem Protokoll von Stapelablaufverfolgungen der Codepfade, die diese Adresse zugeordnet/freigegeben haben, und zeigt diese Stapelablaufverfolgungen an, wenn sie verfügbar sind. Dies kann die Stapelablaufverfolgung anzeigen, die diesen Speicher freigegeben hat.

• Parameter 1 - Speicherblockadresse.
• Parameter 2 - Nicht verwendet.
• Parameter 3 - Nicht verwendet.
• Parameter 4 – nicht verwendet.

• Testschicht: Gedächtnis
• Stopp-ID: MEM_ALREADY_FREE
• Stoppcode: 0x60B
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Falscher Size-Parameter für den VirtualFree-Vorgang (MEM_RELEASE).

Dieser Stopp wird generiert, wenn die App-Überprüfung ein VirtualFree (MEM_RELEASE) mit einem Wert ungleich Null für den dwSize-Parameter erkennt. Bei Verwendung von MEM_RELEASE ist der einzige zulässige Wert für diesen Parameter 0. Wenn VirtualFree mit einem anderen Wert außer 0 aufgerufen wird, kann VirtualFree den Arbeitsspeicher nicht freigeben. Um diesen Stopp zu debuggen, sehen Sie sich die aktuelle Stapelüberwachung (kb) an: Der Aufrufer von VirtualFree ist wahrscheinlich der Schuldige.

• Parameter 1 - Falsche Größe, die von der Anwendung verwendet wird.
• Parameter 2 - Korrekte Größe (0) erwartet.
• Parameter 3 - Nicht verwendet.
• Parameter 4 – nicht verwendet.

• Testschicht: Gedächtnis
• Stopp-ID: INVALID_FREE_SIZE
• Stoppcode: 0x60C
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Unerwartete Ausnahme, die in der DLL-Einstiegspunktroutine ausgelöst wurde.

Dieser Stopp wird generiert, wenn die Dll-Einstiegspunktfunktion (DllMain) eine Ausnahme auslöst. Ein Beispiel dafür ist: Wenn DllMain(DLL_PROCESS_ATTACH) eine Ausnahme auslöst, wird das Windows DLL-Ladeprogramm: - Abfangen und Ausblenden der Ausnahme; - Entladen Sie die DLL, ohne ihre DllMain(DLL_PROCESS_DETACH) aufzurufen. In vielen Fällen hat die DLL bereits einige Ressourcen zugeordnet, dann hat sie die Ausnahme ausgelöst, und es hat keine Chance, diese Ressourcen auf DllMain (DLL_PROCESS_DETACH) freizugeben. So debuggen Sie diesen Stopp:

• Parameter 1 - DLL-Name (zum Abbilden verwenden).
• Parameter 2 - Ausnahmedatensatz. Verwenden Sie ".exr", um sie anzuzeigen.
• Parameter 3 - Kontextdatensatz. Verwenden Sie .cxr, um sie anzuzeigen.
• Parameter 4 - Verifier dll descriptor

• Testschicht: Gedächtnis
• Stopp-ID: DLL_UNEXPECTED_EXCEPTION
• Stoppcode: 0x60D
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Unerwartete Ausnahme, die in threadfunktion ausgelöst wird.

Dieser Stopp wird generiert, wenn eine Threadfunktion eine Ausnahme auslöst. Das ist schlecht, weil der gesamte Prozess getötet wird. So debuggen Sie diesen Stopp:

• < Parameter1> kann für den Ausnahmetyp von Bedeutung sein. Ein Ausnahmecode C0000005 bedeutet z. B. Zugriffsverletzung.
• .exr <parameter2> – zum Anzeigen der Ausnahmeinformationen.
• .cxr-Parameter3>< gefolgt von kb – zum Anzeigen der Ausnahmekontextinformationen

• Parameter 1 - Ausnahmecode.
• Parameter 2 - Ausnahmedatensatz. Verwenden Sie ".exr", um sie anzuzeigen.
• Parameter 3 - Kontextdatensatz. Verwenden Sie .cxr, um sie anzuzeigen.
• Parameter 4 – nicht verwendet.

• Testschicht: Gedächtnis
• Stopp-ID: THREAD_UNEXPECTED_EXCEPTION
• Stoppcode: 0x60E
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Unerwartete Ausnahme beim Ausführen des Arbeitsspeichers ausgelöst.

Dieser Stopp wird generiert, wenn während eines IsBadXXXPtr-Aufrufs eine Ausnahme angezeigt wird. Dies bedeutet, dass der Arbeitsspeicherpuffer, den wir probingen, tatsächlich nicht über den vom Aufrufer angenommenen Schutz verfügt oder dass der Speicher bereits freigegeben wurde usw. Weitere Beispiele für die Verwendung der IsBadXXXPtr-APIs finden Sie in der obigen Diskussion (PROBE_INVALID_ADDRESS, PROBE_FREE_MEM, PROBE_GUARD_PAGE, PROBE_NULL, PROBE_INVALID_START_OR_SIZE). So debuggen Sie diesen Stopp:

• < Parameter1> wird in der Regel C0000005, eine Zugriffsverletzung
• .exr-Parameter2>< – zum Anzeigen der Ausnahmeinformationen
• .cxr-Parameter3>< gefolgt von kb – zum Anzeigen der Ausnahmekontextinformationen und der Stapelablaufverfolgung zum Zeitpunkt, zu dem die Ausnahme ausgelöst wurde

• Parameter 1 - Ausnahmecode.
• Parameter 2 - Ausnahmedatensatz. Verwenden Sie ".exr", um sie anzuzeigen.
• Parameter 3 - Kontextdatensatz. Verwenden Sie .cxr, um sie anzuzeigen.
• Parameter 4 - Nicht verwendet

• Testschicht: Gedächtnis
• Stopp-ID: PROBE_UNEXPECTED_EXCEPTION
• Stoppcode: 0x60F
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Versuchen Sie, die NULL-Adresse zurückzusetzen.

Dieser Stopp wird generiert, wenn der App-Verifier einen VirtualFree -Aufruf (MEM_RESET) mit einem ersten NULL-Parameter erkennt. MEM_RESET sollte nur für bereits zugewiesenen Arbeitsspeicher verwendet werden, sodass NULL in diesem Fall kein gültiger erster Parameter ist.

• Parameter 1 - nicht verwendet.
• Parameter 2 - Nicht verwendet.
• Parameter 3 - Nicht verwendet.
• Parameter 4 – nicht verwendet.

• Testschicht: Gedächtnis
• Stopp-ID: INVALID_MEM_RESET
• Stoppcode: 0x610
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Freigeben des Heap-Speicherblocks innerhalb des Stapeladressbereichs des aktuellen Threads.

Dieser Stopp wird generiert, wenn der App-Prüfer für einen Speicherblock, der tatsächlich Teil des Stapels des aktuellen Threads (!) ist, ein HeapFree erkennt. Um diesen Stopp zu debuggen, sehen Sie sich die aktuelle Stapelablaufverfolgung (kb) an, und versuchen Sie zu verstehen, warum die Funktion, die HeapFree aufgerufen hat, dachte, dass der Speicherblock dynamisch zugewiesen oder zugeordnet wurde, aber tatsächlich speicherzuweisungen aus dem Stapel.

• Parameter 1 - Zuordnungsbasisadresse.
• Parameter 2 - Größe des Speicherbereichs.
• Parameter 3 - Stack Low Limit Address.
• Parameter 4 - Stack High Limit Address.

• Testschicht: Gedächtnis
• Stopp-ID: FREE_THREAD_STACK_MEMORY_AS_HEAP
• Stoppcode: 0x612
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Aufheben der Zuordnung des Speicherbereichs innerhalb des Stapeladressbereichs des aktuellen Threads.

Dieser Stopp wird generiert, wenn die App-Prüfer für einen Speicherblock, der tatsächlich Teil des Stapels des aktuellen Threads (!) ist, eine UnmapViewOfFile erkennt. Um diesen Stopp zu debuggen, schauen Sie sich die aktuelle Stapelablaufverfolgung (kb) an, und versuchen Sie zu verstehen, warum die Funktion, die unmapViewOfFile aufgerufen hat, dachte, dass der Speicherblock dynamisch zugeordnet oder zugeordnet wurde, aber tatsächlich Speicher aus dem Stapel zugeordnet war.

• Parameter 1 - Zuordnungsbasisadresse.
• Parameter 2 - Größe des Speicherbereichs.
• Parameter 3 - Stack Low Limit Address.
• Parameter 4 - Stack High Limit Address.

• Testschicht: Gedächtnis
• Stopp-ID: FREE_THREAD_STACK_MEMORY_AS_MAP
• Stoppcode: 0x613
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Falsche RTL_RESOURCE Adresse.

Dieser Stopp wird generiert, wenn die Anwendung versucht, NULL oder eine andere falsche Adresse (z. B. eine Kernelmodusadresse) als Adresse eines gültigen Objekts zu verwenden. RtlInitializeResource (NULL) ist ein falscher API-Aufruf, der diese Art des Überprüfungsstopps auslöst. *Parameter1* ist die falsche Adresse, und der Schuldige befindet sich in der Stapelablaufverfolgung (mit kb anzeigen).

• Parameter 1 - Adresse.
• Parameter 2 - Nicht verwendet.
• Parameter 3 - Nicht verwendet.
• Parameter 4 – nicht verwendet.

• Testschicht: Gedächtnis
• Stopp-ID: INVALID_RESOURCE_ADDRESS
• Stoppcode: 0x614
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Ungültige kritische Abschnittsadresse.

Dieser Stopp wird generiert, wenn die Anwendung versucht, NULL oder eine andere falsche Adresse (z. B. eine Kernelmodusadresse) als Adresse eines gültigen Objekts zu verwenden. EnterCriticalSection(NULL) ist ein falscher API-Aufruf, der diese Art von Überprüfungsstopp auslöst. *Parameter1* ist die falsche Adresse, und der Schuldige befindet sich in der Stapelablaufverfolgung (mit kb anzeigen).

• Parameter 1 - Adresse.
• Parameter 2 - Nicht verwendet.
• Parameter 3 - Nicht verwendet.
• Parameter 4 – nicht verwendet.

• Testschicht: Gedächtnis
• Stopp-ID: INVALID_CRITSECT_ADDRESS
• Stoppcode: 0x615
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Versuchen Sie, Code im nicht ausführbaren Speicher auszuführen.

Dieser Stopp wird generiert, wenn die Anwendung versucht, Code aus einer Adresse auszuführen, die nicht ausführbar oder kostenlos ist. So debuggen Sie diesen Stopp:

• u <parameter2> – zum Aufheben der Assemble the culprit code
• .exr-Parameter3>< – zum Anzeigen der Ausnahmeinformationen
• .cxr-Parameter4>< gefolgt von kb - zum Anzeigen der Ausnahmekontextinformationen und der Stapelablaufverfolgung für den Zeitpunkt, zu dem die Ausnahme ausgelöst wurde.

• Parameter 1 - Adresse, auf die zugegriffen wird.
• Parameter 2 - Code, der ungültigen Zugriff ausführt.
• Parameter 3 - Ausnahmedatensatz. Verwenden Sie ".exr", um sie anzuzeigen.
• Parameter 4 - Kontextdatensatz. Verwenden Sie .cxr, um sie anzuzeigen.

• Testschicht: Gedächtnis
• Stopp-ID: THREAD_UNEXPECTED_EXCEPTION_CODE
• Stoppcode: 0x616
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Unerwartete Ausnahme beim Initialisieren des Ausgabepuffers ausgelöst.

Dieser Stopp wird generiert, wenn beim Initialisieren eines puffers, der als Ausgabeparameter für eine Win32- oder CRT-API angegeben ist, eine Ausnahme abgerufen wird. Dies bedeutet in der Regel, dass die angegebene Ausgabepuffergröße falsch ist. So debuggen Sie diesen Stopp:

• .exr <parameter3> – zum Anzeigen der Ausnahmeinformationen.
• .cxr-Parameter4>< gefolgt von kb - zum Anzeigen der Ausnahmekontextinformationen und stapelüberwachung zum Zeitpunkt, zu dem die Ausnahme ausgelöst wurde.

• Parameter 1 - Puffer-Startadresse.
• Parameter 2 - Puffergröße.
• Parameter 3 - Ausnahmedatensatz. Verwenden Sie ".exr", um sie anzuzeigen.
• Parameter 4 - Kontextdatensatz. Verwenden Sie .cxr, um sie anzuzeigen.

• Testschicht: Gedächtnis
• Stopp-ID: OUTBUFF_UNEXPECTED_EXCEPTION
• Stoppcode: 0x617
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Unerwartete Ausnahme beim Versuch, die Größe des Heapblocks zu finden.

Dieser Stopp wird generiert, wenn eine Ausnahme beim Aufrufen von HeapSize für einen heap-Block abgerufen wird, der freigegeben wird. Dies bedeutet in der Regel, dass die angegebene Heap-Blockadresse falsch ist oder der Heap beschädigt ist. So debuggen Sie diesen Stopp:

• .exr <parameter3> – zum Anzeigen des Ausnahmedatensatzes.
• .cxr-Parameter4>< gefolgt von kb - zum Anzeigen der Ausnahmekontextinformationen und stapelüberwachung zum Zeitpunkt, zu dem die Ausnahme ausgelöst wurde.

• Parameter 1 - Adresse des Heapblocks, der freigegeben wird.
• Parameter 2 - Heap-Handle.
• Parameter 3 - Ausnahmedatensatz. Verwenden Sie ".exr", um sie anzuzeigen.
• Parameter 4 - Kontextdatensatz. Verwenden Sie .cxr, um sie anzuzeigen.

• Testschicht: Gedächtnis
• Stopp-ID: SIZE_HEAP_UNEXPECTED_EXCEPTION
• Stoppcode: 0x618
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Freigeben des Speicherblocks mit ungültiger Startadresse.

Dieser Stopp wird generiert, wenn das Programm VirtualFree (MEM_RELEASE) mit einem lpAddress-Parameter aufruft, der nicht die Basisadresse ist, die von der Funktion VirtualAlloc oder VirtualAllocEx zurückgegeben wird, wenn der Bereich der Seiten reserviert wurde; So debuggen Sie diesen Stopp:

• kb – um die aktuelle Stapelablaufverfolgung anzuzeigen, die VirtualFree aufruft. Die wahrscheinliche Ursache ist die DLL, die VirtualFree aufruft.

• Parameter 1 - Adresse des freizugebenden Speicherblocks.
• Parameter 2 -  Richtige Speicherblockadresse erwartet.
• Parameter 3 - Nicht verwendet.
• Parameter 4 – nicht verwendet.

• Testschicht: Gedächtnis
• Stopp-ID: INVALID_FREEMEM_START_ADDRESS
• Stoppcode: 0x619
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Aufheben der Zuordnung des Speicherblocks mit ungültiger Startadresse.

Dieser Stopp wird generiert, wenn das Programm UnmapViewOfFile mit einem lpBaseAddress-Parameter aufruft, der nicht mit dem Von einem vorherigen Aufruf der MapViewOfFile- oder MapViewOfFileEx-Funktion zurückgegebenen Wert identisch ist. So debuggen Sie diesen Stopp:

• kb - um die aktuelle Stapelablaufverfolgung anzuzeigen, die unmapViewOfFile aufruft. Die wahrscheinliche Ursache ist die DLL, die UnmapViewOfFile aufruft.

• Parameter 1 - Adresse des Speicherblocks, der nicht zugeordnet wird.
• Parameter 2 -  Richtige Speicherblockadresse erwartet.
• Parameter 3 - Nicht verwendet.
• Parameter 4 – nicht verwendet.

• Testschicht: Gedächtnis
• Stopp-ID: INVALID_UNMAPVIEW_START_ADDRESS
• Stoppcode: 0x619
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

unerwartete Ausnahme, die in der Threadpoolrückruffunktion ausgelöst wird.

Dieser Stopp wird generiert, wenn eine Rückruffunktion im Threadpoolthread eine Ausnahme auslöst. So debuggen Sie diesen Stopp:

• < Parameter1> kann für den Ausnahmetyp von Bedeutung sein. Ein Ausnahmecode C0000005 beispielsweise eine Zugriffsverletzung.
• .exr <parameter2> – zum Anzeigen der Ausnahmeinformationen.
• .cxr-Parameter3>< gefolgt von kb - zum Anzeigen der Ausnahmekontextinformationen.

• Parameter 1 - Ausnahmecode
• Parameter 2 - Ausnahmedatensatz. Verwenden von .exr zum Anzeigen
• Parameter 3 - Kontextdatensatz. Verwenden von .cxr zum Anzeigen
• Parameter 4 - Nicht verwendet

• Testschicht: Gedächtnis
• Stopp-ID: THREADPOOL_UNEXPECTED_EXCEPTION
• Stoppcode: 0x61B
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Code im nicht ausführbaren Speicher

Dieser Stopp wird generiert, wenn die Anwendung versucht, Code aus einer Adresse auszuführen, die nicht ausführbar oder kostenlos ist. So debuggen Sie diesen Stopp:

• u <parameter2> – zum Aufheben der Assemble the culprit code
• .exr-Parameter3>< – zum Anzeigen der Ausnahmeinformationen
• .cxr-Parameter4>< gefolgt von kb - zum Anzeigen der Ausnahmekontextinformationen und der Stapelablaufverfolgung für den Zeitpunkt, zu dem die Ausnahme ausgelöst wurde.

• Parameter 1 - Adresse, auf die zugegriffen wird
• Parameter 2 - Code, der ungültigen Zugriff ausführt
• Parameter 3 - Ausnahmedatensatz. Verwenden Sie ".exr", um sie anzuzeigen.
• Parameter 4 - Kontextdatensatz. Verwenden Sie .cxr, um sie anzuzeigen.

• Testschicht: Gedächtnis
• Stopp-ID: THREADPOOL_UNEXPECTED_EXCEPTION_CODE
• Stoppcode: 0x61C
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Erstellen eines ausführbaren Heaps.

Dieser Stopp wird generiert, wenn die Anwendung einen ausführbaren Heap erstellt. Dies kann ein Sicherheitsrisiko sein.

• Parameter 1 - nicht verwendet.
• Parameter 2 - Nicht verwendet.
• Parameter 3 - Nicht verwendet.
• Parameter 4 – nicht verwendet.

• Testschicht: Gedächtnis
• Stopp-ID: EXECUTABLE_HEAP
• Stoppcode: 0x1D
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Zuweisung des ausführbaren Speichers.

Dieser Stopp wird generiert, wenn die Anwendung ausführbaren Speicher ansetzt. Dies kann ein Sicherheitsrisiko sein.

• Parameter 1 - Seitenschutz durch Aufrufer angegeben.
• Parameter 2 - Nicht verwendet.
• Parameter 3 - Nicht verwendet.
• Parameter 4 – nicht verwendet.

• Testschicht: Gedächtnis
• Stopp-ID: EXECUTABLE_MEMORY
• Stoppcode: 0x1E
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

TLS Stop Details

Entladen der DLL, die TLS-Index zugewiesen hat, der nicht freigegeben wurde.

Dieser Stopp wird generiert, wenn eine DLL, die einen TLS-Index zugewiesen hat, entladen wird, bevor dieser TLS-Index freigegeben wird. So debuggen Sie diesen Stopp:

• du <parameter3> - den Namen der culprit DLL anzeigen
• .reload xxx.dll=<parameter4> - Reload-Symbole für die culprit DLL (falls erforderlich). xxx.dll ist der Name der DLL, die im obigen Schritt angezeigt wird.
• u <parameter2> : Zerlegen Sie den Code, der tls zugeordnet hat. Dies sollte auf die Funktion verweisen, die das TLS zugeordnet hat, aber vergessen hat, sie frei zu geben, bevor die DLL entladen wurde.

• Parameter 1 - TLS-Index
• Parameter 2 - Adresse des Codes, der diesen TLS-Index zugeordnet hat.
• Parameter 3 - DLL-Name-Adresse. Verwenden Sie "du", um es abzubilden.
• Parameter 4 - DLL-Basisadresse.

• Testschicht: TLS
• Stopp-ID: TLS_LEAK
• Stoppcode: 0x350
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Beschädigte TLS-Struktur.

Dieser Stopp wird generiert, wenn die internen Prüferstrukturen, die zum Speichern des Status von TLS-Slots für Thread verwendet werden, beschädigt sind. Sehr wahrscheinlich ist dies auf eine zufällige Korruption im Prozess zurückzuführen.

• Parameter 1 - TEB-Adresse.
• Parameter 2 -TeB-Adresse  erwartet.
• Parameter 3 - Thread-ID.
• Parameter 4 - Thread-ID erwartet.

• Testschicht: TLS
• Stopp-ID: CORRUPTED_TLS
• Stoppcode: 0x351
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Verwenden eines ungültigen TLS-Indexes.

Dieser Stopp wird generiert, wenn ein ungültiger TLS-Index verwendet wird. In den meisten Fällen liegt es daran, dass Code diesen Index weiterhin verwendet, wenn TlsFree aufgerufen wird. Hier ist ein Beispiel für den Threadpoolthread.

• T1: Dll lädt und TlsAlloc
• T1: Warteschlangenrückruf
• T1: Gewarteter/abgebrochener Rückruf übersprungen
• T1: TlsFree
• T2: Rückruf wird ausgeführt und ruft TlsSetValue auf
• T1: Dll entladen

• Parameter 1 - TLS-Index
• Parameter 2 - Nicht verwendet.
• Parameter 3 - Nicht verwendet.
• Parameter 4 - Nicht verwendet.

• Testschicht: TLS
• Stopp-ID: INVALID_TLS_INDEX
• Stoppcode: 0x352
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Threadpool-Stoppdetails

Die Priorität dieses Threadpoolthreads wurde geändert.

Dieser Stopp wird generiert, wenn die Threadpriorität geändert wird, wenn sie an threadpool zurückgegeben wird.

• Format: -  Threadpoolthread (%x), der Callback ausgeführt hat (%p) hat eine geänderte Threadpriorität (%i -> %i)
• Parameter 1 - Callback-Funktion.
• Parameter 2 - Context.
• Parameter 3 -Threadpool Object  allocation stack trace, use dps to dump it.
• Parameter 4 - Aktuelle Priorität.

• Testschicht: Threadpool
• Stopp-ID: INCONSISTENT_PRIORITY
• Stoppcode: 0x700
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Die Affinität dieses Threadpoolthreads wurde geändert.

Dieser Stopp wird generiert, wenn die Threadaffinität geändert wird, wenn sie an threadpool zurückgegeben wird.

• Format: - Threadpoolthread (%x) mit ausgeführter Rückruf (%p) hat eine geänderte Threadaffinitätsmaske (%p -> %p)
• Parameter 1 - Callback-Funktion.
• Parameter 2 - Context.
• Parameter 3 -Threadpool Object  allocation stack trace, use dps to dump it.
• Parameter 4 - Aktuelle Affinität.

• Testschicht: Threadpool
• Stopp-ID: INCONSISTENT_AFFINITY_MASK
• Stoppcode: 0x701
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Unprocessed msg im msg-Pool des aktuellen Threads.

Dieser Stopp wird generiert, wenn eine Nachricht, die als nicht verarbeitet verbleibt, wenn dieser Threadpoolthread an den Pool zurückgegeben wird. Es ist gefährlich, da es in einem völlig anderen Kontext verarbeitet wird. Verwenden Sie bitte !avrf -tp <Param4> , um die in diesem Thread geposteten Nachrichten anzuzeigen.

• Format: - Threadpoolthread (%x) mit ausgeführter Rückruf (%p) verfügt über ausstehende Fenstermeldung (%x: %x)
• Parameter 1 - Callback-Funktion.
• Parameter 2 - Context.
• Parameter 3 -Threadpool Object  allocation stack trace, use dps to dump it.
• Parameter 4 - Threadpool-Thread-ID. Verwenden Sie !avrf -tp <Threadid> , um die in diesem Thread geposteten Nachrichten anzuzeigen.

• Testschicht: Threadpool
• Stopp-ID: ORPHANED_THREAD_MESSAGE
• Stoppcode: 0x702
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Das nicht geöffnete Fenster gehörte zum aktuellen Thread.

Dieser Stopp wird generiert, wenn ein Fenster aktiv gehalten wird, wenn dieser Threadpoolthread an den Pool zurückgegeben wird.

• Format: -  Threadpoolthread (%x), der Callback ausgeführt hat (%p) hat gültige hwnd (%x: %s), die Nachrichten empfangen können
• Parameter 1 - Callback-Funktion.
• Parameter 2 - Context.
• Parameter 3 -Threadpool Object  allocation stack trace, use dps to dump it.
• Parameter 4 - Threadpool-Thread-ID.

• Testschicht: Threadpool
• Stopp-ID: ORPHANED_THREAD_WINDOW
• Stoppcode: 0x703
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

ExitThread() oder TerminateThread() in einem Threadpoolthread.

Dieser Stopp wird generiert, wenn ExitThread in einem Threadpoolthread aufgerufen wird. Es ist verboten, da es System instabil macht. Dies führt zu Ressourcenleck, Fixierung oder AV.

• Parameter 1 - Callback-Funktion.
• Parameter 2 - Context.
• Parameter 3 -Threadpool Object  allocation stack trace, use dps to dump it.
• Parameter 4 - Nicht verwendet.

• Testschicht: Threadpool
• Stopp-ID: ILLEGAL_THREAD_TERMINATION
• Stoppcode: 0x704
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Thread befindet sich im Identitätswechselstatus, wenn er an einen Threadpoolthread zurückgegeben wird.

Dieser Stopp wird generiert, wenn die Rückruffunktion das Threadtoken so ändert, dass ein anderer Benutzer identitätswechselt und vergessen hat, es zurückzusetzen, bevor er wieder in den Threadpool zurückgesetzt wird.

• Parameter 1 - Callback-Funktion.
• Parameter 2 - Context.
• Parameter 3 -Threadpool Object  allocation stack trace, use dps to dump it.
• Parameter 4 - Nicht verwendet.

• Testschicht: Threadpool
• Stopp-ID: THREAD_IN_IMPERSONATION
• Stoppcode: 0x705
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Eine Funktion, die beständigen Thread erfordert, wird aufgerufen.

Einige Microsoft Windows-APIs müssen innerhalb eines dedizierten oder persistenten Threads aufgerufen werden. Im Threadpool sollten Sie in der Regel die Verwendung des lokalen Threadspeichers und das Queuing asynchroner Aufrufe vermeiden, die einen persistenten Thread erfordern, z. B. die RegNotifyChangeKeyValue-Funktion. Solche Funktionen können jedoch mithilfe von QueueUserWorkItem mit der Option WT_EXECUTEINPERSISTENTTHREAD an einen beständigen Workerthread in die Warteschlange gestellt werden. Ein KB-Code im Debugger zeigt den Aufrufer an.

• Parameter 1 - Callback-Funktion.
• Parameter 2 - Context.
• Parameter 3 -Threadpool Object  allocation stack trace, use dps to dump it.
• Parameter 4 - Nicht verwendet.

• Testschicht: Threadpool
• Stopp-ID: PERSISTED_THREAD_NEEDED
• Stoppcode: 0x706
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Thread befindet sich im geänderten Transaktionszustand.

Dieser Stopp wird generiert, wenn die Rückruffunktion vergessen hat, das aktuelle Transaktionshandle zu schließen oder zurückzusetzen.

• Parameter 1 - Callback-Funktion.
• Parameter 2 - Context.
• Parameter 3 -Threadpool Object  allocation stack trace, use dps to dump it.
• Parameter 4 - Transaktionshandle.

• Testschicht: Threadpool
• Stopp-ID: DIRTY_TRANSACTION_CONTEXT
• Stoppcode: 0x707
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Dieser Threadpoolstatus weist unausgewogene CoInit- und CoUnInit-Aufrufe auf.

Dieser Stopp wird generiert, wenn die Rückruffunktion CoInit und CoUnInit nicht ausgeglichen aufruft.

• Parameter 1 - Callback-Funktion.
• Parameter 2 - Context.
• Parameter 3 -Threadpool Object  allocation stack trace, use dps to dump it.
• Parameter 4 - Ausgewogene Anrufanzahl.

• Testschicht: Threadpool
• Stopp-ID: DIRTY_COM_STATE
• Stoppcode: 0x708
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Die Parameter für das Timerobjekt sind inkonsistent. Zeitraum sollte 0 sein, wenn WT_EXECUTEONLYONCE beim Erstellen des Timers angegeben wird

Dieser Stopp wird generiert, wenn der Zeitraum, der den Timer signalisiert, nicht null ist, wenn der Timer nur einmal mit dem WT_EXECUTEONLYONCE Flag signalisiert wird.

• Parameter 1 - Punkt angegeben.
• Parameter 2 - Flags angegeben.
• Parameter 3 - Nicht verwendet.
• Parameter 4 - Nicht verwendet.

• Testschicht: Threadpool
• Stopp-ID: INCONSISTENT_TIMER_PARAMS
• Stoppcode: 0x709
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Die Ladesperre wurde vom Threadpoolthread innerhalb des Rückrufs gehalten.

Dieser Stopp wird generiert, wenn die Ladesperre innerhalb des Rückrufs gehalten wird und nicht freigegeben wird, wenn der Thread an den Threadpool zurückgegeben wird.

• Parameter 1 - Callback-Funktion.
• Parameter 2 - Context.
• Parameter 3 -Threadpool Object  allocation stack trace, use dps to dump it.
• Parameter 4 - Nicht verwendet.

• Testschicht: Threadpool
• Stopp-ID: LOADER_LOCK_HELD
• Stoppcode: 0x7A
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Die bevorzugte Sprache wird vom Threadpoolthread innerhalb des Rückrufs festgelegt.

Dieser Stopp wird generiert, wenn die bevorzugte Sprache innerhalb des Rückrufs festgelegt wird und nicht gelöscht wird, wenn der Thread an den Threadpool zurückgegeben wird.

• Parameter 1 - Callback-Funktion.
• Parameter 2 - Context.
• Parameter 3 -Threadpool Object  allocation stack trace, use dps to dump it.
• Parameter 4 - Nicht verwendet.

• Testschicht: Threadpool
• Stopp-ID: PREFERRED_LANGUAGES_SET
• Stoppcode: 0x7B
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Die Hintergrundpriorität wird vom Threadpoolthread innerhalb des Rückrufs festgelegt.

Dieser Stopp wird generiert, wenn die Hintergrundpriorität innerhalb des Rückrufs festgelegt wird und nicht deaktiviert ist, wenn der Thread an den Threadpool zurückgegeben wird.

• Parameter 1 - Callback-Funktion.
• Parameter 2 - Context.
• Parameter 3 -Threadpool Object  allocation stack trace, use dps to dump it.
• Parameter 4 - Nicht verwendet.

• Testschicht: Threadpool
• Stopp-ID: BACKGROUND_PRIORITY_SET
• Stoppcode: 0x7C
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

TerminateThread() in einem Threadpoolthread.

Dieser Stopp wird generiert, wenn TerminateThread in einem Threadpoolthread aufgerufen wird. Es ist verboten, da es System instabil macht. Dies führt zu Ressourcenleck, Fixierung oder AV.

• Parameter 1 - Nicht verwendet.
• Parameter 2 - Nicht verwendet.
• Parameter 3 - Nicht verwendet.
• Parameter 4 - Nicht verwendet.

• Testschicht: Threadpool
• Stopp-ID: ILLEGAL_THREAD_TERMINATION
• Stoppcode: 0x7D
• Schweregrad: Fehler
• Einmaliger Fehler: 
• Fehlerbericht: Break
• Protokolldatei: ja
• Backtrace erstellen: Ja

Siehe auch

Application Verifier - Stop Codes and Definitions

Application Verifier – Übersicht

Application Verifier – Features

Application Verifier – Testen von Anwendungen

Application Verifier – Tests innerhalb von Application Verifier

Application Verifier – Debuggen der Anwendungsüberprüfung beendet

Application Verifier – Häufig gestellte Fragen