Freigeben über

Anwendungsüberprüfung – Stoppcodes – Grundlagen

  • Artikel

Die folgenden Stoppcodes sind in der Basisreihe von Tests enthalten.

Details zum Beenden von Ausnahmen

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

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendung versucht, Code von einer Adresse auszuführen, die nicht ausführbar oder kostenlos ist. Zum Debuggen dieses Stopps: $ u parameter2 – zum Aufheben der Assemblierung des verantwortlichen Codes $ .exr parameter3 – zur Anzeige der Ausnahmeinformationen; $ .cxr parameter4 gefolgt von kb – zur Anzeige der Ausnahmekontextinformationen und der Stapelverfolgung, wenn die Ausnahme ausgelöst wurde.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Adresse, auf die zugegriffen wird.
  • Parameter 2 - Code für ungültigen Zugriff.
  • Parameter 3 - Ausnahmedatensatz. Verwenden Sie .exr, um ihn anzuzeigen.
  • Parameter 4 - Kontextdatensatz. Verwenden Sie .cxr, um ihn anzuzeigen.

Weitere Informationen
  • Testebene: Ausnahmen
  • Stopp-ID: FIRST_CHANCE_ACCESS_VIOLATION_CODE
  • Stoppcode: 650NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Details zum Beenden von Handles

Ungültige Handle-Ausnahme für die aktuelle Stapelüberwachung.

Wahrscheinliche Ursache

Dieser Stopp wird erzeugt, wenn die Funktion am oberen Ende des Stapels ein ungültiges Handle an Systemroutinen übergeben hat. Normalerweise zeigt ein einfacher KB-Befehl an, was der Wert des übergebenen Handles ist (dies muss einer der Parameter sein, in der Regel der erste). Wenn der Wert null ist, ist dies eindeutig falsch. Wenn der Wert in Ordnung zu sein scheint, müssen Sie die Debuggererweiterung !htrace verwenden, um einen Verlauf der Vorgänge zu erhalten, die sich auf diesen Handle-Wert beziehen. In den meisten Fällen muss der Handlewert nach dem Schließen verwendet werden.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Ausnahmecode.
  • Parameter 2 - Ausnahmedatensatz. Verwenden Sie .exr, um ihn anzuzeigen.
  • Parameter 3 - Kontextdatensatz. Verwenden Sie .cxr, um ihn anzuzeigen.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Handles
  • Stopp-ID: INVALID_HANDLE
  • Stoppcode: 300NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Für die aktuelle Stapelüberwachung wurde ein ungültiger TLS-Index verwendet.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Funktion oben auf dem Stapel einen ungültigen TLS-Index an die TLS-Systemroutinen übergeben hat. Normalerweise zeigt ein einfacher KB-Befehl an, was falsch ist. Der typische Fehler hier besteht darin, einen bestimmten Wert für einen TLS-Index anzunehmen, anstatt TlsAlloc aufzurufen. Dies kann entweder dadurch passieren, dass Sie denken, Sie erhalten immer den Wert N und deshalb TlsAlloc nicht aufrufen zu müssen, oder häufiger aufgrund einer nicht initialisierten Variable.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 – Ungültiger TLS-Index .
  • Parameter 2 – Erwarteter unterer Teil des Index.
  • Parameter 3 - Nicht verwendet.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Handles
  • Stopp-ID: INVALID_TLS_VALUE
  • Stoppcode: 300NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Ungültige Parameter für den WaitForMultipleObjects-Aufruf.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Funktion oben auf dem Stapel „WaitForMultipleObjects“ mit NULL als Adresse des Arrays der zu wartenden Handles oder mit Null als Anzahl der Handles aufruft. Ein einfacher KB-Befehl zeigt die Funktion an, die diese API falsch aufruft.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 – Adresse des Objekt-Handle-Vektors.
  • Parameter 2 – Anzahl der Handles.
  • Parameter 3 - Nicht verwendet.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Handles
  • Stopp-ID: INCORRECT_WAIT_CALL
  • Stoppcode: 300NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

NULL-Handle, der als Parameter übergeben wird. Es muss ein gültiger Handle verwendet werden.

Wahrscheinliche Ursache

Dieser Stopp wird erzeugt, wenn die Funktion am oberen Ende des Stapels ein NULL-Handle an Systemroutinen übergeben hat.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Nicht verwendet.
  • Parameter 2 - Nicht verwendet.
  • Parameter 3 - Nicht verwendet.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Handles
  • Stopp-ID: NULL_HANDLE
  • Stoppcode: 300NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Wartet auf einen Thread-Handle in DllMain.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn der aktuelle Thread derzeit Code innerhalb der DllMain-Funktion einer der im aktuellen Prozess geladenen DLLs ausführt und WaitForSingleObject oder WaitForMultipleObjects aufruft, um auf einen Thread-Handle im selben Prozess zu warten. Dies würde höchstwahrscheinlich zu einem Deadlock führen, da der Thread-Handle nicht signalisiert wird, es sei denn, der zweite Thread wird beendet. Wenn der zweite Thread ExitThread aufruft, versucht er, die DLL-Loadersperre zu erhalten und ruft dann DllMain (DLL_THREAD_DETACH) für alle DLLs im aktuellen Prozess auf. Da die Loader-Sperre jedoch dem ersten Thread gehört (demjenigen, der auf den Thread-Handle wartet), kommt es zu einem Deadlock zwischen den beiden Threads.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Thread-Handle.
  • Parameter 2 - Nicht verwendet.
  • Parameter 3 - Nicht verwendet.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Handles
  • Stopp-ID: WAIT_IN_DLLMAIN
  • Stoppcode: 300NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Falscher Objekttyp für Handle.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn der aktuelle Thread eine API mit einem Handle für ein Objekt mit einem falschen Objekttyp aufruft. Beispielsweise wird dieser Stopp durch den Aufruf von SetEvent mit einem Semaphor-Handle als Parameter generiert. Zum Debuggen dieses Stopps: $ kb – zum Anzeigen der aktuellen Stapelüberwachung. Das Problem ist wahrscheinlich die DLL, die verifier.dll aufruft; $ du parameter2 – um den tatsächlichen Typ des Handles anzuzeigen. Der Handlewert ist Parameter1. Im obigen Beispiel wird Folgendes angezeigt: Semaphor. $ du parameter3 – zum Anzeigen des Objekttyps, der von der API erwartet wird. Im obigen Beispiel lautet dieser Name: Ereignis. $ !htrace parameter1 kann hilfreich sein, da die Stapelüberwachung für die letzten Öffnen/Schließen-Vorgänge auf diesem Handle angezeigt wird.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Handle-Wert.
  • Parameter 2 - Objekttypname. Verwenden von du zum Anzeigen
  • Parameter 3 - Erwarteter Objekttypname. Verwenden von du zum Anzeigen
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Handles
  • Stopp-ID: INCORRECT_OBJECT_TYPE
  • Stoppcode: 300NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Heaps-Stopp-Details

Unbekannter Fehler.

Wahrscheinliche Ursache

Diese Meldung kann auftreten, wenn der aufgetretene Fehler nicht anders eingeordnet werden kann. Wird derzeit nicht verwendet.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Nicht verwendet
  • Parameter 2 - Nicht verwendet
  • Parameter 3 - Nicht verwendet
  • Parameter 4 - Nicht verwendet

Weitere Informationen
  • Testebene: Heaps
  • Stopp-ID: UNKNOWN_ERROR
  • Stoppcode: 0NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Ausnahme bei Zugriffsverletzung.

Wahrscheinliche Ursache

Dies ist der am häufigsten vorkommende Stopp bei der Anwendungsüberprüfung. Normalerweise wird er durch einen Pufferüberlauffehler verursacht. Der Heap-Prüfer platziert eine nicht zugängliche Seite am Ende einer Heap-Zuweisung und ein Pufferüberlauf verursacht eine Ausnahme, wenn 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 Debugger-Befehl: !heap -p -a ACCESS_ADDRESS. Dieser Befehl stellt Details zur Art des Fehlers bereit und dazu, welcher Heap-Block überlaufen ist. Außerdem wird der Stapelüberwachungsbericht für die Blockzuweisung angezeigt. Es gibt mehrere andere Gründe für diesen Stopp. Beispielsweise der Zugriff auf einen Heap-Block nach der Freigabe. Der gleiche Debuggerbefehl ist auch in diesem Fall nützlich.

Von der Anwendungsüberprüfung angezeigte Informationen
  • 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

Weitere Informationen
  • Testebene: Heaps
  • Stopp-ID: ACCESS_VIOLATION
  • Stoppcode: 0NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Multithread-Zugriff auf einen Heap, der mit dem Flag HEAP_NO_SERIALIZE erstellt wurde.

Wahrscheinliche Ursache

Auf einen mit dem Flag HEAP_NO_SERIALIZE erstellten Heap sollte nicht gleichzeitig von zwei Threads zugegriffen werden. Wenn eine solche Situation erkannt wird, erhalten Sie diese Nachricht. Diese Situation schleicht sich typischerweise in ein Programm ein, indem es eine Verknüpfung mit einer Single-Thread-Version der C-Runtime herstellt. Visual C++ kann eine solche Bibliothek beispielsweise statisch verknüpfen, wenn die entsprechenden Flags verwendet werden. Dann vergessen die Benutzer dieses Detail und verwenden mehrere Threads. Der Fehler ist in der Realität sehr schwer zu beheben, da er sich in Form mysteriöser Datenbeschädigungen zeigt.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Heap, in dem der Vorgang stattfindet.
  • Parameter 2 - Thread-ID für den aktuellen Besitzer des Heap-kritischen Abschnitts.
  • Parameter 3 - Thread-ID des aktuellen Threads, der versucht, auf den Heap zuzugreifen.
  • Parameter 4 - Nicht verwendet

Weitere Informationen
  • Testebene: Heaps
  • Stopp-ID: UNSYNCHRONIZED_ACCESS
  • Stoppcode: 0NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Extreme Größenanforderung.

Wahrscheinliche Ursache

Diese Meldung wird generiert, wenn bei einer HeapAlloc()- oder HeapReAlloc()-Operation die Blockgröße jeden angemessenen Wert überschreitet. Normalerweise beträgt dieser Wert auf 32-Bit-Plattformen 0x80000000 und ist auf 64-Bit-Plattformen deutlich höher.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Heap, in dem der Vorgang stattfindet.
  • Parameter 2 - Größe angefordert
  • Parameter 3 - Nicht verwendet
  • Parameter 4 - Nicht verwendet

Weitere Informationen
  • Testebene: Heaps
  • Stopp-ID: EXTREME_SIZE_REQUEST
  • Stoppcode: 0NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Heap-Handle mit falscher Signatur.

Wahrscheinliche Ursache

Die Heap-Strukturen werden mit einem magischen Wert markiert. Wenn der beim Aufruf einer Heap-Schnittstelle verwendete Heap-Handle dieses Muster nicht aufweist, wird dieser Stopp generiert. Dieser Fehler kann auftreten, wenn die interne Heap-Struktur irgendwie beschädigt wurde (zufällige Beschädigung) oder einfach ein falscher Wert als Heap-Handle verwendet wird. Um eine Liste gültiger Heap-Handle-Werte zu erhalten, verwenden Sie die folgenden Debugger-Befehle: !heap -p. Beachten Sie, dass Sie diesen Stopp nicht erhalten, wenn Sie in einer Heap-Operation einfach ein gültiges Heap-Handle durch ein anderes gültiges ersetzen (das Handle sieht schließlich gültig aus). Der Heap-Prüfer erkennt diese Situation jedoch und meldet sie mit SWITCHED_HEAP_HANDLE-Stop.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Heap-Handle, der beim Aufruf einer Heap-Schnittstelle verwendet wird
  • Parameter 2 - Nicht verwendet
  • Parameter 3 - Nicht verwendet
  • Parameter 4 - Nicht verwendet

Weitere Informationen
  • Testebene: Heaps
  • Stopp-ID: BAD_HEAP_HANDLE
  • Stoppcode: 0NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Beschädigter Heap-Zeiger oder falscher Heap wird verwendet.

Wahrscheinliche Ursache

Dies geschieht normalerweise, wenn ein Block auf einem Heap zugewiesen und auf einem anderen freigegeben wird. Verwenden Sie den Befehl !heap -p, um eine Liste aller gültigen Heap-Handle-Werte zu erhalten. Das häufigste Beispiel ist eine msvcrt-Zuweisung mithilfe von malloc() gepaart mit einer Kernel32-Freigabe mithilfe von HeapFree().

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Im Aufruf verwendeter Heap-Handle.
  • Parameter 2 - Am Vorgang beteiligter Heap-Block.
  • Parameter 3 - Größe des Heap-Blocks.
  • Parameter 4 - Heap, in dem der Block ursprünglich zugewiesen wurde.

Weitere Informationen
  • Testebene: Heaps
  • Stopp-ID: SWITCHED_HEAP_HANDLE
  • Stoppcode: 0NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Heap-Block bereits freigegeben.

Wahrscheinliche Ursache

Diese Situation tritt ein, wenn der Block zweimal freigegeben wird. Freigegebene Blöcke werden speziell markiert und für eine Weile in einer verzögerten Warteschlange aufbewahrt. Wenn ein fehlerhaftes Programm versucht, den Block erneut freizugeben, wird dies abgefangen, vorausgesetzt, der Block wurde nicht aus der Warteschlange für verzögerte Freigaben entfernt und sein Speicher wurde für andere Zuweisungen wiederverwendet. Die Tiefe der Warteschlange ohne Verzögerung beträgt mehrere Tausend Blöcke. Daher besteht eine gute Chance, dass die meisten Doppelfreigaben abgefangen werden.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Heap-Handle für den Heap, dem der Block gehört.
  • Parameter 2 - Heap-Block wird wieder freigegeben.
  • Parameter 3 - Größe des Heap-Blocks.
  • Parameter 4 - Nicht verwendet

Weitere Informationen
  • Testebene: Heaps
  • Stopp-ID: DOUBLE_FREE
  • Stoppcode: 0NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Beschädigter Heap-Block.

Wahrscheinliche Ursache

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

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Im Aufruf verwendeter Heap-Handle.
  • Parameter 2 - Am Vorgang beteiligter Heap-Block.
  • Parameter 3 - Größe des Heap-Blocks.
  • Parameter 4 - Reserviert

Weitere Informationen
  • Testebene: Heaps
  • Stopp-ID: CORRUPTED_HEAP_BLOCK
  • Stoppcode: 0NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Versuch, den Prozessheap zu zerstören.

Wahrscheinliche Ursache

Der Versuch, den Standardprozessheap (den von der Schnittstelle GetProcessHeap() zurückgegebenen) zu zerstören, ist ein Fehler.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Mit HeapDestroy verwendeter Heap-Handle.
  • Parameter 2 - Nicht verwendet
  • Parameter 3 - Nicht verwendet
  • Parameter 4 - Nicht verwendet

Weitere Informationen
  • Testebene: Heaps
  • Stopp-ID: DESTROY_PROCESS_HEAP
  • Stoppcode: 0NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Beim Ausführen des Heap-Verwaltungscodes ist eine unerwartete Ausnahme aufgetreten.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn während der Ausführung des Heap-Manager-Codes in unzulässigen Situationen eine Zugriffsverletzung auftritt. Es gibt sehr wenige Situationen, in denen dies in Ordnung ist, beispielsweise beim Aufruf von HeapValidate() oder HeapSize(). Anhand der Informationen im Ausnahmedatensatz (dritter Parameter) lässt sich der genaue Kontext der Ausnahme ermitteln. Verwenden Sie hierfür die folgenden Debuggerbefehle: $ .exr STOP-PARAMETER-2 $ .cxr STOP-PARAMETER-3 Normalerweise kann dieser Stopp erfolgen, wenn es zu zufälligen Beschädigungen in den internen Heap-Strukturen kommt.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Der am Vorgang beteiligte Heap.
  • Parameter 2 - Ausnahmedatensatz.
  • Parameter 3 - Kontextdatensatz.
  • Parameter 4 - Ausnahmecode (C0000005 – Zugriffsverletzung)

Weitere Informationen
  • Testebene: Heaps
  • Stopp-ID: UNEXPECTED_EXCEPTION
  • Stoppcode: 0NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Beim Überprüfen des Heap-Block-Headers ist eine Ausnahme aufgetreten.

Wahrscheinliche Ursache

Diese Situation tritt ein, wenn wir für den Block wirklich keine bestimmte Art von Beschädigung feststellen können. Dieser Stopp erfolgt höchstwahrscheinlich, wenn die an einen freien Heap übergebene Heap-Blockadresse auf einen nicht zugänglichen Speicherbereich verweist (beschädigter Zeiger, nicht initialisierter Zeiger usw.).

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Heap-Handle für den Heap, dem der Block gehört.
  • Parameter 2 - Beschädigter Heap-Block.
  • Parameter 3 - Größe des Blocks oder Null, wenn die Größe nicht bestimmt werden kann.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Heaps
  • Stopp-ID: CORRUPTED_HEAP_BLOCK_EXCEPTION_RAISED_FOR_HEADER
  • Stoppcode: 0NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Beim Überprüfen des Heap-Blocks ist eine Ausnahme aufgetreten.

Wahrscheinliche Ursache

Diese Situation tritt ein, wenn wir für den Block wirklich keine bestimmte Art von Beschädigung feststellen können. Dies tritt beispielsweise auf, wenn Sie bei einem Heap-Freigabevorgang eine Adresse übergeben, die auf einen nicht zugänglichen Speicherbereich verweist. Dies kann auch bei doppelter Freigabe passieren, wenn wir den Block nicht unter den vollständigen Seitenheapblöcken finden und ihn als leichten Seitenheapblock prüfen.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Im Aufruf verwendeter Heap-Handle.
  • Parameter 2 - Am Vorgang beteiligter Heap-Block.
  • Parameter 3 - Größe des Heap-Blocks.
  • Parameter 4 - Reserviert.

Weitere Informationen
  • Testebene: Heaps
  • Stopp-ID: CORRUPTED_HEAP_BLOCK_EXCEPTION_RAISED_FOR_PROBING
  • Stoppcode: 0NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Heap-Block nach Freigabe beschädigt.

Wahrscheinliche Ursache

Diese Situation tritt ein, wenn in einen Speicherblock geschrieben wird, nachdem er freigegeben wurde.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Heap-Handle für den Heap, dem der Block gehört.
  • Parameter 2 - Beschädigter Heap-Block.
  • Parameter 3 - Größe des Blocks oder Null, wenn die Größe nicht bestimmt werden kann.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Heaps
  • Stopp-ID: CORRUPTED_HEAP_BLOCK_HEADER
  • Stoppcode: 0NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Beschädigtes Infixmuster für freigegebenen Heapblock.

Wahrscheinliche Ursache

Freigegebene Blöcke werden manchmal als nicht zugänglich markiert und ein Programm, das sie berührt, verursacht eine Zugriffsverletzung (anderer Prüferstopp). In anderen Fällen (Light Page Heap) wird der Block mit einem magischen Muster markiert und für eine Weile beibehalten. Schließlich werden die Blöcke im FIFO-Verfahren wirklich freigegeben. 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 herausfinden und den Code überprüfen, der möglicherweise fehlerhaft ist.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Heap-Handle für den Heap, dem der Block gehört.
  • Parameter 2 - Heap-Block wird freigegeben.
  • Parameter 3 - Größe des Heap-Blocks.
  • Parameter 4 - Reserviert.

Weitere Informationen
  • Testebene: Heaps
  • Stopp-ID: CORRUPTED_FREED_HEAP_BLOCK
  • Stoppcode: 0NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Beschädigtes Suffixmuster für Heap-Block.

Wahrscheinliche Ursache

Dies geschieht am häufigsten bei Pufferüberlauffehlern. Manchmal platziert der Anwendungsprüfer nicht zugängliche Seiten am Ende der Zuweisung, und Pufferüberläufe führen zu einer Zugriffsverletzung, und manchmal folgt auf den Heap-Block ein magisches Muster. Wenn dieses Muster geändert wird, wenn der Block freigegeben wird, erhalten Sie diese Unterbrechung. Das Debuggen dieser Unterbrechungen kann ziemlich schwierig sein, da Sie nicht über den tatsächlichen Zeitpunkt der Beschädigung verfügen. Sie haben lediglich Zugriff auf den freien Moment (hier ist ein Stopp aufgetreten) und den Zuordnungsstapelüberwachungs-Trace (!heap -p -a HEAP_ADDRESS).

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Im Aufruf verwendeter Heap-Handle.
  • Parameter 2 - Am Vorgang beteiligter Heap-Block.
  • Parameter 3 - Größe des Heap-Blocks.
  • Parameter 4 - Reserviert.

Weitere Informationen
  • Testebene: Heaps
  • Stopp-ID: CORRUPTED_HEAP_BLOCK_SUFFIX
  • Stoppcode: 0NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Beschädigter Startstempel für Heap-Block.

Wahrscheinliche Ursache

Dies geschieht bei Pufferunterläufen.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Im Aufruf verwendeter Heap-Handle.
  • Parameter 2 - Am Vorgang beteiligter Heap-Block.
  • Parameter 3 - Größe des Heap-Blocks.
  • Parameter 4 - Beschädigter Stempelwert.

Weitere Informationen
  • Testebene: Heaps
  • Stopp-ID: CORRUPTED_HEAP_BLOCK_START_STAMP
  • Stoppcode: 0NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Beschädigter Endstempel für den Heap-Block.

Wahrscheinliche Ursache

Dies geschieht bei Pufferunterläufen.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Im Aufruf verwendeter Heap-Handle.
  • Parameter 2 - Am Vorgang beteiligter Heap-Block.
  • Parameter 3 - Größe des Heap-Blocks.
  • Parameter 4 - Beschädigter Stempelwert.

Weitere Informationen
  • Testebene: Heaps
  • Stopp-ID: CORRUPTED_HEAP_BLOCK_END_STAMP
  • Stoppcode: 0NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Beschädigtes Präfixmuster für Heap-Block.

Wahrscheinliche Ursache

Dies geschieht bei Pufferunterläufen.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Im Aufruf verwendeter Heap-Handle.
  • Parameter 2 - Am Vorgang beteiligter Heap-Block.
  • Parameter 3 - Größe des Heap-Blocks.
  • Parameter 4 - Reserviert.

Weitere Informationen
  • Testebene: Heaps
  • Stopp-ID: CORRUPTED_HEAP_BLOCK_PREFIX
  • Stoppcode: 0NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Erstmalige Zugriffsverletzung für aktuelle Stapelüberwachung.

Wahrscheinliche Ursache

Dies ist der am häufigsten vorkommende Stopp bei der Anwendungsüberprüfung. Normalerweise wird er durch einen Pufferüberlauffehler verursacht. Der Heap-Prüfer platziert eine nicht zugängliche Seite am Ende einer Heap-Zuweisung und ein Pufferüberlauf verursacht eine Ausnahme, wenn 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 Debugger-Befehl: !heap -p -a ACCESS_ADDRESS. Dieser Befehl stellt Details zur Art des Fehlers bereit und dazu, welcher Heap-Block überlaufen ist. Außerdem wird der Stapelüberwachungsbericht für die Blockzuweisung angezeigt. Es gibt mehrere andere Gründe für diesen Stopp. Beispielsweise der Zugriff auf einen Heap-Block nach der Freigabe. Der gleiche Debuggerbefehl ist auch in diesem Fall nützlich.

Von der Anwendungsüberprüfung angezeigte Informationen
  • 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.

Weitere Informationen
  • Testebene: Heaps
  • Stopp-ID: FIRST_CHANCE_ACCESS_VIOLATION
  • Stoppcode: 0NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Ungültige Anzahl der Prozess-Heap-Listen.

Wahrscheinliche Ursache

Diese Meldung kann auftreten, wenn der Seitenheap-Manager beim Aufruf von GetProcessHeaps interne Inkonsistenzen erkennt. Die Ursache hierfür kann eine zufällige Beschädigung im Prozessbereich sein.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Tatsächliche Heap-Anzahl.
  • Parameter 2 - Seiten-Heap-Anzahl.
  • Parameter 3 - Nicht verwendet
  • Parameter 4 - Nicht verwendet

Weitere Informationen
  • Testebene: Heaps
  • Stopp-ID: CORRUPTED_HEAP_LIST
  • Stoppcode: 0NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Details zum Leckstopp

Die Heap-Zuweisung wurde kompromittiert.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Besitzer-DLL der Zuweisung dynamisch entladen wurde, während sie über Ressourcen verfügte.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Adresse der kompromittierten Zuweisung. Führen Sie die <Adresse> !heap -p -a aus, um weitere Informationen zur Zuteilung zu erhalten.
  • Parameter 2 - Adresse zum Zuordnungsstapelüberwachung. Führen Sie die <Adresse> dps aus, um den Zuordnungsstapel anzuzeigen.
  • Parameter 3 - Adresse des Besitzer-DLL-Namens. Führen Sie die <Adresse> du aus, um den DLL-Namen zu lesen.
  • Parameter 4 - Basis 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.

Weitere Informationen
  • Testebene: Leck
  • Stopp-ID: ALLOCATION
  • Stoppcode: 900NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Ein HANDLE wurde kompromittiert.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Besitzer-DLL des Handles dynamisch entladen wurde, während sie über Ressourcen verfügte. So debuggen Sie diesen Stopp: Führen Sie !htrace parameter1 aus, um zusätzliche Informationen zum Handle zu erhalten.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Wert des kompromittierten Handles. Führen Sie den <Handle> !htrace aus, um zusätzliche Informationen über den Handle zu erhalten, wenn die Handle-Verfolgung aktiviert ist.
  • Parameter 2 - Adresse zum Zuordnungsstapelüberwachung. Führen Sie die <Adresse> dps aus, um den Zuordnungsstapel anzuzeigen.
  • Parameter 3 - Adresse des Besitzer-DLL-Namens. Führen Sie die <Adresse> du aus, um den DLL-Namen zu lesen.
  • Parameter 4 - Basis 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.

Weitere Informationen
  • Testebene: Leck
  • Stopp-ID: HANDLE
  • Stoppcode: 900NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Ein HKEY wurde kompromittiert.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Besitzer-DLL des Registrierungsschlüssels dynamisch entladen wurde, während sie über Ressourcen verfügte.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Wert des kompromittierten HKEY.
  • Parameter 2 - Adresse zum Zuordnungsstapelüberwachung. Führen Sie die <Adresse> dps aus, um den Zuordnungsstapel anzuzeigen.
  • Parameter 3 - Adresse des Besitzer-DLL-Namens. Führen Sie die <Adresse> du aus, um den DLL-Namen zu lesen.
  • Parameter 4 - Basis 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.

Weitere Informationen
  • Testebene: Leck
  • Stopp-ID: REGISTRY
  • Stoppcode: 900NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Eine virtuelle Reservierung wurde geleakt.

Wahrscheinliche Ursache

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

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Kompromittierte Reservierungsadresse.
  • Parameter 2 - Adresse zum Zuordnungsstapelüberwachung. Führen Sie die <Adresse> dps aus, um den Zuordnungsstapel anzuzeigen.
  • Parameter 3 - Adresse des Besitzer-DLL-Namens. Führen Sie die <Adresse> du aus, um den DLL-Namen zu lesen.
  • Parameter 4 - Basis 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.

Weitere Informationen
  • Testebene: Leck
  • Stopp-ID: VIRTUAL_RESERVATION
  • Stoppcode: 900NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Ein BSTR wurde kompromittiert.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Besitzer-DLL des SysStrings dynamisch entladen wurde, während sie über Ressourcen verfügte.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Adresse des kompromittierten BSTR. Führen Sie die <Adresse> !heap -p -a aus, um weitere Informationen zur Zuteilung zu erhalten.
  • Parameter 2 - Adresse zum Zuordnungsstapelüberwachung. Führen Sie die <Adresse> dps aus, um den Zuordnungsstapel anzuzeigen.
  • Parameter 3 - Adresse des Besitzer-DLL-Namens. Führen Sie die <Adresse> du aus, um den DLL-Namen zu lesen.
  • Parameter 4 - Basis 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.

Weitere Informationen
  • Testebene: Leck
  • Stopp-ID: SYSSTRING
  • Stoppcode: 900NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Die Registrierung einer Stromversorgungsmeldung wurde nicht abgemeldet.

Wahrscheinliche Ursache

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

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Adresse zur Registrierung der Stromversorgungsmeldung.
  • Parameter 2 - Adresse zur Registrierungs-Stapelüberwachung. Führen Sie die <Adresse> dps aus, um den Zuordnungsstapel anzuzeigen.
  • Parameter 3 - Adresse des Besitzer-DLL-Namens. Führen Sie die <Adresse> du aus, um den DLL-Namen zu lesen.
  • Parameter 4 - Basis 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.

Weitere Informationen
  • Testebene: Leck
  • Stopp-ID: POWER_NOTIFICATION
  • Stoppcode: 900NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Details zu Sperrstopps

Der Thread kann keinen kritischen Abschnitt besitzen.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn ein Thread (Thread-ID ist Parameter1) beendet oder angehalten wird oder sich in einem Zustand befindet (Arbeitsthread hat ein Arbeitselement beendet), in dem er einen kritischen Abschnitt nicht halten kann. Der aktuelle Thread ist das Problem. Verwenden Sie zum Debuggen dieses Stopps die folgenden Debuggerbefehle: $ kb – zum Abrufen der aktuellen Stapelüberwachung. Wenn der aktuelle Thread der Besitzer des kritischen Abschnitts ist, ruft er wahrscheinlich ExitThread auf. Der aktuelle Thread sollte den kritischen Abschnitt vor dem Beenden freigegeben haben. Wenn der aktuelle Thread TerminateThread oder SuspendThread aufruft, sollte er dies nicht für einen Thread tun, der einen kritischen Abschnitt enthält. $ !cs -s parameter2 – Informationen zu diesem kritischen Abschnitt ausgeben. $ ln Parameter2 – um Symbole in der Nähe der Adresse des kritischen Abschnitts anzuzeigen. Dies sollte dabei helfen, den kompromittierten kritischen Abschnitt zu identifizieren. $ dps Parameter4 – um die Stapelüberwachung für die Initialisierung dieses kritischen Abschnitts zu sichern.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Thread-ID.
  • Parameter 2 - Kritische Abschnittsadresse
  • Parameter 3 - Adresse der Debuginformationen im kritischen Abschnitt.
  • Parameter 4 - Stapelüberwachung für die Initialisierung kritischer Abschnitte.

Weitere Informationen
  • Testebene: Sperren
  • Stopp-ID: EXIT_THREAD_OWNS_LOCK
  • Stoppcode: 200NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

DLL mit einem aktiven kritischen Abschnitt wird entladen.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn eine DLL eine globale Variable mit einem kritischen Abschnitt hat und die DLL entladen wird, der kritische Abschnitt jedoch nicht gelöscht wurde. Um diesen Stopp zu debuggen, verwenden Sie die folgenden Debuggerbefehle: $ du parameter3 – um den Namen der fehlerhaften DLL zu sichern. $ .reload dllname oder .reload dllname = Parameter4 – um die Symbole für diese DLL neu zu laden. $ !cs -s parameter1 – Informationen zu diesem kritischen Abschnitt ausgeben. $ ln Parameter1 – um Symbole in der Nähe der Adresse des kritischen Abschnitts anzuzeigen. Dies sollte dabei helfen, den kompromittierten kritischen Abschnitt zu identifizieren. $ dps Parameter2 – um den Stacktrace für die Initialisierung dieses kritischen Abschnitts zu sichern.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Kritische Abschnittsadresse.
  • Parameter 2 - Stapelüberwachung für die Initialisierung kritischer Abschnitte.
  • Parameter 3 - DLL-Namensadresse.
  • Parameter 4 - DLL-Basisadresse.

Weitere Informationen
  • Testebene: Sperren
  • Stopp-ID: LOCK_IN_UNLOADED_DLL
  • Stoppcode: 200NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Heap-Block freigeben, der einen aktiven kritischen Abschnitt enthält.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn eine Heap-Zuweisung einen kritischen Abschnitt enthält, die Zuweisung freigegeben ist und der kritische Abschnitt nicht gelöscht wurde. Um diesen Stopp zu debuggen, verwenden Sie die folgenden Debuggerbefehle: $ !cs -s parameter1 – Informationen zu diesem kritischen Abschnitt ausgeben. $ ln Parameter1 – um Symbole in der Nähe der Adresse des kritischen Abschnitts anzuzeigen. Dies sollte dabei helfen, den kompromittierten kritischen Abschnitt zu identifizieren. $ dps Parameter2 – um den Stacktrace für die Initialisierung dieses kritischen Abschnitts zu sichern. $ Parameter3 und Parameter4 können dabei helfen zu verstehen, wo dieser Heap-Block zugewiesen wurde (die Größe der Zuweisung ist wahrscheinlich erheblich).

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Kritische Abschnittsadresse.
  • Parameter 2 - Stapelüberwachung für die Initialisierung kritischer Abschnitte.
  • Parameter 3 - Heap-Blockadresse.
  • Parameter 4 - Heap-Blockgröße.

Weitere Informationen
  • Testebene: Sperren
  • Stopp-ID: LOCK_IN_FREED_HEAP
  • Stoppcode: 200NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Doppelt initialisierter oder beschädigter kritischer Abschnitt.

Wahrscheinliche Ursache

Normalerweise wird dieser Stopp generiert, wenn ein kritischer Abschnitt mehr als einmal initialisiert wurde. In diesem Fall sind Parameter3 und Parameter4 die Stapelüberwachungs-Adressen für zwei dieser Initialisierungen. In anderen Fällen kann dieser Stopp auch erfolgen, wenn der kritische Abschnitt oder seine Debug-Informationsstruktur beschädigt wurde. In diesem zweiten Fall ist es möglich, dass Parameter3 und Parameter4 ungültig und unbrauchbar sind. So debuggen Sie diesen Stopp: $ !cs -s -d parameter2 – Informationen zu diesem kritischen Abschnitt ausgeben. $ ln Parameter1 – um Symbole in der Nähe der Adresse des kritischen Abschnitts anzuzeigen. Dies kann bei der Identifizierung des kritischen Abschnitts hilfreich sein, wenn es sich um eine globale Variable handelt. $ dps parameter3 und dps parameter4 – um die beiden Codepfade zum Initialisieren dieses kritischen Abschnitts zu identifizieren.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Kritische Abschnittsadresse.
  • Parameter 2 - Adresse der Debug-Informationsstruktur, die in der aktiven Liste gefunden wurde.
  • Parameter 3 - Erste Initialisierungsstapelüberwachung.
  • Parameter 4 - Zweite Initialisierungsstapelüberwachung.

Weitere Informationen
  • Testebene: Sperren
  • Stopp-ID: LOCK_DOUBLE_INITIALIZE
  • Stoppcode: 200NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Geben Sie Speicher frei, der einen aktiven kritischen Abschnitt enthält.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn der Speicher, der einen kritischen Abschnitt enthält, freigegeben wurde, der kritische Abschnitt jedoch nicht mit DeleteCriticalSection gelöscht wurde. Um diesen Stopp zu debuggen, verwenden Sie die folgenden Debuggerbefehle: $ !cs -s -d parameter2 – Informationen zu diesem kritischen Abschnitt ausgeben. $ dps parameter3 – um den Codepfad für die Initialisierung dieses kritischen Abschnitts zu identifizieren. In den meisten Fällen erkennt der Lock Verifier sofort kompromittierte kritische Abschnitte, die in einer Heap-Zuweisung, einem DLL-Bereich, einer virtuellen Speicherzuweisung oder einem per MapViewOfFile zugeordneten Speicherbereich enthalten sind, und gibt in diesen Fällen unterschiedliche Stopps aus. Es gibt also nur sehr wenige Fälle für diesen Prüferstopp. Die Sperre muss in einem Speicherbereich liegen, der durch Kernelmoduscode oder prozessübergreifend durch APIs wie VirtualFreeEx freigegeben wird. Am häufigsten wird dieser Stopp erreicht, wenn ein vorheriger Stopp (z. B. LOCK_IN_FREED_HEAP oder LOCK_IN_UNLOADED_DLL) durch Drücken von „g“ in der Debugger-Konsole fortgesetzt wurde.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Kritische Abschnittsadresse.
  • Parameter 2 - Adresse der Debuginformationen im kritischen Abschnitt.
  • Parameter 3 - Stapelüberwachung für die Initialisierung kritischer Abschnitte.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Sperren
  • Stopp-ID: LOCK_IN_FREED_MEMORY
  • Stoppcode: 200NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Beschädigter kritischer Abschnitt.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn das DebugInfo-Feld des kritischen Abschnitts auf freigegebenen Speicher verweist. Normalerweise wird in der Liste der aktiven kritischen Abschnitte eine andere gültige DebugInfo-Struktur gefunden. Ohne Beschädigung sollten die beiden Zeiger identisch sein. Um diesen Stopp zu debuggen, verwenden Sie die folgenden Debuggerbefehle: $ !cs -s -d parameter3 – gibt Informationen zu diesem kritischen Abschnitt basierend auf dem aktuellen Inhalt der Debuginfostruktur aus, die in der aktiven Liste gefunden wurde (diese Struktur wird selten beschädigt, also sind diese Informationen normalerweise vertrauenswürdig). $ !cs -s Parameter1 – Informationen zu diesem kritischen Abschnitt basierend auf dem aktuellen Inhalt der kritischen Abschnittsstruktur ausgeben (die Struktur ist bereits beschädigt, deshalb sind diese Informationen manchmal NICHT vertrauenswürdig). $ dps parameter4 – um den Codepfad für die Initialisierung dieses kritischen Abschnitts zu identifizieren. Erstellen Sie einen Dump des kritischen Abschnitts an der Adresse Parameter1 und suchen Sie nach dem Beschädigungsmuster. 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

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Kritische Abschnittsadresse.
  • Parameter 2 - Ungültige Debug-Informationsadresse für diesen kritischen Abschnitt.
  • Parameter 3 - Adresse der in der aktiven Liste gefundenen Debuginformationen.
  • Parameter 4 - Initialisierungsstapelüberlauf.

Weitere Informationen
  • Testebene: Sperren
  • Stopp-ID: LOCK_CORRUPTED
  • Stoppcode: 200NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Ungültiger Thread für den Besitzer kritischer Abschnitte.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Thread-ID des Besitzers im aktuellen Kontext ungültig ist. So debuggen Sie diesen Stopp: $ !cs -s parameter1 – Informationen zu diesem kritischen Abschnitt ausgeben. $ ln Parameter1 – um Symbole in der Nähe der Adresse des kritischen Abschnitts anzuzeigen. Dies sollte dazu beitragen, den kritischen Abschnitt zu identifizieren.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Kritische Abschnittsadresse.
  • Parameter 2 - Besitzender Thread.
  • Parameter 3 - Erwarteter besitzender Thread.
  • Parameter 4 - Kritischer Abschnitt der Adresse der Debuginformationen.

Weitere Informationen
  • Testebene: Sperren
  • Stopp-ID: LOCK_INVALID_OWNER
  • Stoppcode: 200NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Ungültige Anzahl kritischer Abschnittsrekursionen.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn das Feld zur Rekursionsanzahl der kritischen Abschnittsstruktur im aktuellen Kontext ungültig ist. So debuggen Sie diesen Stopp: $ !cs -s parameter1 – Informationen zu diesem kritischen Abschnitt ausgeben. $ ln Parameter1 – um Symbole in der Nähe der Adresse des kritischen Abschnitts anzuzeigen. Dies sollte dazu beitragen, den kritischen Abschnitt zu identifizieren.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Kritische Abschnittsadresse.
  • Parameter 2 - Rekursionsanzahl.
  • Parameter 3 - Erwartete Rekursionsanzahl.
  • Parameter 4 - Kritischer Abschnitt der Adresse der Debuginformationen.

Weitere Informationen
  • Testebene: Sperren
  • Stopp-ID: LOCK_INVALID_RECURSION_COUNT
  • Stoppcode: 200NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Kritischer Abschnitt mit ungültiger Sperranzahl wird gelöscht.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn ein kritischer Abschnitt einem Thread gehört, wenn er gelöscht wird oder wenn der kritische Abschnitt nicht initialisiert ist. So debuggen Sie diesen Stopp: $ !cs -s parameter1 – Informationen zu diesem kritischen Abschnitt ausgeben. Wenn der besitzende Thread 0 ist, wurde der kritische Abschnitt nicht initialisiert. $ ln Parameter1 – um Symbole in der Nähe der Adresse des kritischen Abschnitts anzuzeigen. Dies sollte dazu beitragen, den kritischen Abschnitt zu identifizieren.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Kritische Abschnittsadresse.
  • Parameter 2 - Sperranzahl.
  • Parameter 3 - Erwartete Sperranzahl.
  • Parameter 4 - Besitzender Thread.

Weitere Informationen
  • Testebene: Sperren
  • Stopp-ID: LOCK_INVALID_LOCK_COUNT
  • Stoppcode: 200NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Kritischer Abschnitt zu oft freigegeben oder beschädigt.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn ein kritischer Abschnitt öfter freigegeben wird, als der aktuelle Thread ihn abgerufen hat. So debuggen Sie diesen Stopp: $ !cs -s parameter1 – Informationen zu diesem kritischen Abschnitt ausgeben. $ !cs -s -d parameter4 – Dumpinformationen zu diesem kritischen Abschnitt. $ ln Parameter1 – um Symbole in der Nähe der Adresse des kritischen Abschnitts anzuzeigen. Dies sollte dazu beitragen, den kritischen Abschnitt zu identifizieren.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Kritische Abschnittsadresse.
  • Parameter 2 - Sperranzahl.
  • Parameter 3 - Erwartete Sperranzahl.
  • Parameter 4 - Kritischer Abschnitt der Adresse der Debuginformationen.

Weitere Informationen
  • Testebene: Sperren
  • Stopp-ID: LOCK_OVER_RELEASED
  • Stoppcode: 200NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Kritischer Abschnitt nicht initialisiert.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn ein kritischer Abschnitt verwendet wird, ohne dass er initialisiert wurde oder nachdem er gelöscht wurde. Zum Debuggen diese: $ ln parameter1 – um Symbole in der Nähe der Adresse des kritischen Abschnitts anzuzeigen. Dies sollte dazu beitragen, den kritischen Abschnitt zu identifizieren.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Kritische Abschnittsadresse.
  • Parameter 2 - Kritischer Abschnitt der Adresse der Debuginformationen.
  • Parameter 3 - Nicht verwendet.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Sperren
  • Stopp-ID: LOCK_NOT_INITIALIZED
  • Stoppcode: 200NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Kritischer Abschnitt ist bereits initialisiert.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn ein kritischer Abschnitt vom aktuellen Thread erneut initialisiert wird. Zum Debuggen dieses Stopps: $ !cs -s parameter1 or !cs -s -d parameter2 - Dumpinformationen zu diesem kritischen Abschnitt. $ ln Parameter1 – um Symbole in der Nähe der Adresse des kritischen Abschnitts anzuzeigen. Dies kann bei der Identifizierung des kritischen Abschnitts hilfreich sein, 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 Stapelüberwachung anzuzeigen, die diesen kritischen Abschnitt neu initialisiert.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Kritische Abschnittsadresse.
  • Parameter 2 - Kritischer Abschnitt der Adresse der Debuginformationen.
  • Parameter 3 - Erste Initialisierungsstapelüberwachung. Verwenden von dps, um es zu auszugeben, wenn es nicht NULL ist
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Sperren
  • Stopp-ID: LOCK_ALREADY_INITIALIZED
  • Stoppcode: 200NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

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

Wahrscheinliche Ursache

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 für diesen kritischen Abschnitt aufrufen, bevor sie diesen Speicher freigibt. $ kb – um die aktuelle Stapelüberwachung anzuzeigen, die VirtualFree aufruft. Die wahrscheinliche Ursache ist die DLL, die VirtualFree aufruft. $ !cs -s parameter1 – Informationen zu diesem kritischen Abschnitt ausgeben. $dps parameter2 – um den Codepfad für die Initialisierung dieses kritischen Abschnitts zu identifizieren.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Kritische Abschnittsadresse.
  • Parameter 2 - Stapelüberwachung für die Initialisierung kritischer Abschnitte.
  • Parameter 3 - Speicherblockadresse.
  • Parameter 4 - Speicherblockgröße.

Weitere Informationen
  • Testebene: Sperren
  • Stopp-ID: LOCK_IN_FREED_VMEM
  • Stoppcode: 200NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

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

Wahrscheinliche Ursache

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 für diesen kritischen Abschnitt aufrufen, bevor sie die Zuordnung dieses Speichers aufhebt. $ kb – um die aktuelle Stapelüberwachung anzuzeigen, die unmapViewOfFile aufruft. Die wahrscheinliche Ursache ist die DLL, die UnmapViewOfFile aufruft. $ !cs -s parameter1 – Informationen zu diesem kritischen Abschnitt ausgeben. $dps parameter2 – um den Codepfad für die Initialisierung dieses kritischen Abschnitts zu identifizieren.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Kritische Abschnittsadresse.
  • Parameter 2 - Stapelüberwachung für die Initialisierung kritischer Abschnitte.
  • Parameter 3 - Speicherblockadresse.
  • Parameter 4 - Speicherblockgröße.

Weitere Informationen
  • Testebene: Sperren
  • Stopp-ID: LOCK_IN_UNMAPPED_MEM
  • Stoppcode: 200NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Der aktuelle Thread besitzt keine kritischen Abschnitte.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn der aktuelle Thread LeaveCriticalSection aufruft, aber laut den internen Prüfer-Aufzeichnungen keinen kritischen Abschnitt besitzt. Wenn parameter2 Null ist, handelt es sich wahrscheinlich um einen Fehler im aktuellen Thread. Entweder versucht er, einen kritischen Abschnitt zu verlassen, den er nicht betreten hat, oder er ruft „LeaveCriticalSection“ für denselben kritischen Abschnitt häufiger auf als „EnterCriticalSection“. Wenn Parameter2 nicht null ist (es handelt sich um eine negative ganze Zahl), sind die internen Prüfdatenstrukturen wahrscheinlich beschädigt.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Kritische Abschnittsadresse.
  • Parameter 2 - Anzahl der kritischen Abschnitte, die dem aktuellen Thread gehören.
  • Parameter 3 - Nicht verwendet
  • Parameter 4 - Nicht verwendet

Weitere Informationen
  • Testebene: Sperren
  • Stopp-ID: THREAD_NOT_LOCK_OWNER
  • Stoppcode: 200NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Es wird ein kritischer Abschnitt verwendet, der für eine andere DLL privat ist.

Wahrscheinliche Ursache

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 in einen kritischen Abschnitt zu wechseln, der in ntdll.dll definiert ist. Private Sperren können nicht über DLLs hinweg verwendet werden.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Kritische Abschnittsadresse.
  • Parameter 2 - Nicht verwendet.
  • Parameter 3 - Nicht verwendet
  • Parameter 4 - Nicht verwendet

Weitere Informationen
  • Testebene: Sperren
  • Stopp-ID: LOCK_PRIVATE
  • Stoppcode: 200NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

SRWLock-Stoppdetails

Die SRW-Sperre ist nicht initialisiert.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn ein Thread versucht, die SRW-Sperre (Param1) zu verwenden, die nicht initialisiert ist. $ kb – zum Abrufen der aktuellen Stapelüberwachung. Hier wird die SRW-Sperre verwendet. Die SRW-Sperre sollte mit InitializeSRWLock initialisiert werden, bevor sie verwendet werden kann.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - SRW-Sperre
  • Parameter 2 - Nicht verwendet
  • Parameter 3 - Nicht verwendet
  • Parameter 4 - Nicht verwendet

Weitere Informationen
  • Testebene: SRWLock
  • Stopp-ID: NOT_INITIALIZED
  • Stoppcode: 250NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Die SWR-Sperre ist bereits initialisiert.

Wahrscheinliche Ursache

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 Neuinitialisierung der Sperre zu unvorhersehbarem Verhalten der Anwendung, einschließlich Hängenbleiben und Abstürzen. Die Initialisierungsstapelüberwachung zeigt möglicherweise einen Aufruf an, wenn die SRW-Sperre statisch initialisiert wurde. $ kb – zum Abrufen der aktuellen Stapelüberwachung. Hier wird die SRW-Sperre neu initialisiert. $ dps Param3 – um die SRW-Sperrinitialisierungs-Stapelüberwachung abzurufen. Diese Stapelüberwachung zeigt möglicherweise einen Aufruf an, wenn die Sperre statisch initialisiert wurde.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - SRW-Sperre
  • Parameter 2 - ThreadId des Threads, der die SRW-Sperre initialisiert hat.
  • Parameter 3 - Adresse der Initialisierungs-Stapelüberwachung. Verwenden Sie dps <address>, um zu sehen, wo die SRW-Sperre initialisiert wurde.
  • Parameter 4 - Nicht verwendet

Weitere Informationen
  • Testebene: SRWLock
  • Stopp-ID: ALREADY_INITIALIZED
  • Stoppcode: 250NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Nicht übereinstimmende Aufruf-/Freigabevorgänge bei der SRW-Sperre.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die SRW-Sperre (Param1) mit einer falschen Freigabe-API freigegeben wird. Wenn die SRW-Sperre für den gemeinsamen Zugriff aufgerufen wurde und mithilfe der API für die exklusive Freigabe freigegeben wird oder wenn die SRW-Sperre für den exklusiven Zugriff aufgerufen wurde und mithilfe der API für die gemeinsame Freigabe freigegeben wird. Dies kann zu unvorhersehbaren Verhaltensweisen durch die Anwendung führen, einschließlich Blockaden und Abstürze. $ kb – zum Abrufen der aktuellen Stapelüberwachung. Hier wird die SRW-Sperre mit der falschen API freigegeben. $ dps Param3 – zum Abrufen der Stapelüberwachung der SRW-Sperre

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - SRW-Sperre
  • Parameter 2 - ThreadId des Threads, der die SRW-Sperre aufgerufen hat.
  • Parameter 3 - Adresse der Stapelüberwachung für den Aufruf Verwenden Sie dps <address>, um zu sehen, wo die SRW-Sperre aufgerufen wurde.
  • Parameter 4 - Nicht verwendet

Weitere Informationen
  • Testebene: SRWLock
  • Stopp-ID: MISMATCHED_ACQUIRE_RELEASE
  • Stoppcode: 250NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Die SRW-Sperre wird rekursiv vom selben Thread aufgerufen.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die SRW-Sperre (Param1) rekursiv vom selben Thread abgerufen wird. Dies führt zu einem Deadlock und der Thread wird auf unbestimmte Zeit blockiert. Der rekursive Erwerb einer SRW-Sperre im exklusiven Modus führt zu einem Deadlock. Der rekursive Abruf einer SRW-Sperre im gemeinsam genutzten Modus führt zu einem Deadlock, wenn ein Thread auf exklusiven Zugriff wartet. Betrachten Sie das folgende Beispiel: – Thread A ruft die SRW-Sperre im gemeinsam genutzten Modus auf. – Thread B versucht, die SRW-Sperre im exklusiven Modus aufzurufen und wartet. – Thread A versucht, die SRW-Sperre im gemeinsam genutzten Modus rekursiv aufzurufen. Dies ist erfolgreich, solange kein exklusiver Waiter vorhanden ist (in diesem Fall B). Da SRW-Sperren keinen Writer-Mangel aufweisen, wartet Thread A hinter Thread B. Nun wartet Thread B auf Thread A, der wiederum auf Thread B wartet, was zu einer zirkulären Wartezeit und damit zu einem Deadlock führt. $ kb – zum Abrufen der aktuellen Stapelüberwachung. Hier wird die SRW-Sperre rekursiv aufgerufen. $ dps Param2 – um die Stapelüberwachung für den ersten Aufruf zu erhalten.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - SRW-Sperre
  • Parameter 2 - Adresse der ersten Stapelüberwachung für den Aufruf. Verwenden Sie dps <address>, um zu sehen, wo die SRW-Sperre aufgerufen wurde.
  • Parameter 3 - Nicht verwendet
  • Parameter 4 - Nicht verwendet

Weitere Informationen
  • Testebene: SRWLock
  • Stopp-ID: RECURSIVE_ACQUIRE
  • Stoppcode: 250NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

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

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn der Thread (Param2), der die SRW-Sperre (Param1) besitzt, endet oder beendet wird. Dies führt zu einer verwaisten SRW-Sperre und die Threads, die versuchen, diese Sperre aufzurufen, werden auf unbestimmte Zeit blockiert. $ kb – zum Abrufen der aktuellen Stapelüberwachung. Hier endet der Thread oder er wird beendet. $ dps Param3 – zum Abrufen der Stapelüberwachung der SRW-Sperre

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - SRW-Sperre
  • Parameter 2 - ThreadId des Threads, der endet oder beendet wird.
  • Parameter 3 - Adresse der Stapelüberwachung für den Aufruf Verwenden Sie dps <address>, um zu sehen, wo die SRW-Sperre aufgerufen wurde.
  • Parameter 4 - Nicht verwendet

Weitere Informationen
  • Testebene: SRWLock
  • Stopp-ID: EXIT_THREAD_OWNS_LOCK
  • Stoppcode: 250NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Die freigegebene SRW-Sperre wurde nicht von diesem Thread abgerufen.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die SRW-Sperre (Param1) vom Thread (Param2) freigegeben wird, der die Sperre nicht erhalten hat. Dies stellt eine schlechte Programmierpraxis dar, die schwer richtig umzusetzen ist und zu unvorhersehbarem Verhalten der Anwendung führen kann. $ kb – zum Abrufen der aktuellen Stapelüberwachung. Hier gibt der Thread die SRW-Sperre frei, die er nicht aufgerufen hat. $ dps Param4 – zum Abrufen der Stapelüberwachung zum Aufrufen der SRW-Sperre.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - SRW-Sperre
  • Parameter 2 - Aktuelle ThreadId.
  • Parameter 3 - ThreadId des Threads, der die SRW-Sperre aufgerufen hat.
  • Parameter 4 - Adresse der Aufruf-Stapelüberwachung. Verwenden Sie dps <address>, um zu sehen, wo die SRW-Sperre aufgerufen wurde.

Weitere Informationen
  • Testebene: SRWLock
  • Stopp-ID: INVALID_OWNER
  • Stoppcode: 250NAN
  • Schweregrad:  Warnung
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Keine
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

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

Wahrscheinliche Ursache

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. $ kb – zum Abrufen der aktuellen Stapelüberwachung. Hier wird der Speicher freigegeben, der eine aktive SRW-Sperre enthält. $ dps Param4 – zum Abrufen der Stapelüberwachung zum Aufrufen der SRW-Sperre.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - SRW-Sperre
  • Parameter 2 - Adresse des freizugebenden Speichers.
  • Parameter 3 - ThreadId des Threads, der die SRW-Sperre aufgerufen hat.
  • Parameter 4 - Adresse der Aufruf-Stapelüberwachung. Verwenden Sie dps <address>, um zu sehen, wo die SRW-Sperre aufgerufen wurde.

Weitere Informationen
  • Testebene: SRWLock
  • Stopp-ID: IN_FREED_MEMORY
  • Stoppcode: 250NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

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

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die zu entladende DLL (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. $ kb – zum Abrufen der aktuellen Stapelüberwachung. Hier wird die DLL entladen, die eine aktive SRW-Sperre enthält. $ du Param2 – um den Namen der DLL zu finden, die entladen wird. $ dps Param4 – zum Abrufen der Stapelüberwachung zum Aufrufen der SRW-Sperre.

Von der Anwendungsüberprüfung angezeigte Informationen
  • 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 aufgerufen hat.
  • Parameter 4 - Adresse der Aufruf-Stapelüberwachung. Verwenden Sie dps <address>, um zu sehen, wo die SRW-Sperre aufgerufen wurde.

Weitere Informationen
  • Testebene: SRWLock
  • Stopp-ID: IN_UNLOADED_DLL
  • Stoppcode: 250NAN
  • Schweregrad:  Warnung
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Keine
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Details zum Speicherstopp

Virtueller Speicherblock mit ungültiger Größe oder Startadresse wird freigegeben.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendungsüberprüfung ein VirtualFree oder einen DLL-Unload 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 Stapelüberwachung und die Speicheradresse sowie die Größe an, die gerade freigegeben werden soll, und versuchen Sie zu ermitteln, warum sie ungültig sind.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Basisadresse der Zuordnung.
  • Parameter 2 - Speicherbereichsgröße
  • Parameter 3 - Nicht verwendet.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: INVALID_FREEMEM
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Falscher virtueller Zuweisungsaufruf.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendungsüberprüfung 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.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Zeiger auf die Basisadresse der Zuweisung.
  • Parameter 2 - Zeiger auf die Speicherbereichsgröße.
  • Parameter 3 - Nicht verwendet
  • Parameter 4 - Nicht verwendet

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: INVALID_ALLOCMEM
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Falscher Aufruf der Zuordnungsansicht.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendungsüberprüfung 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.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Zeiger zur Basisadresse der Zuordnung.
  • Parameter 2 - Zeiger auf die Ansichtsgröße.
  • Parameter 3 - Nicht verwendet.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: INVALID_MAPVIEW
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Ungültige Adresse für die Überprüfung.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendungsüberprüfung einen IsBadXXXPtr-Aufruf mit einer ungültigen Adresse (z. B. eine Kernelmodusadresse statt einer normalen Benutzermodusadresse) für den zu prüfenden Speicherpuffer erkennt. Um diesen Stopp zu debuggen, sehen Sie sich die aktuellen Stapelüberwachung (kb) an und versuchen Sie herauszufinden, warum der Aufrufer der Funktion IsBadXXXPtr eine ungültige Adresse erhalten hat. In vielen Fällen handelt es sich bei der Adresse schlicht und einfach um einen nicht initialisierten Zeiger. Die MSDN-Bibliothek listet einige Gründe auf, warum Anwendungen die IsBadXXXPtr-APIs nicht verwenden sollten: In einer präemptiven Multitasking-Umgebung ist es möglich, dass ein anderer Thread den Zugriff des Prozesses auf den getesteten Speicher ändert. Das Dereferenzieren potenziell ungültiger Zeiger kann die Stapelerweiterung in anderen Threads deaktivieren. Wenn die Stapelerweiterung deaktiviert wurde und ein Thread seinen Stapel erschöpft, führt dies zur sofortigen Beendigung des übergeordneten Prozesses, ohne dass ein Fehlerfenster oder Diagnoseinformationen angezeigt werden. Von den Threads in einem Prozess wird erwartet, dass sie so zusammenarbeiten, dass keiner von ihnen Speicher freigibt, den der 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.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Startadresse.
  • Parameter 2 - Speicherblockgröße.
  • Parameter 3 - Ungültige Adresse.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: PROBE_INVALID_ADDRESS
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Prüfen von freiem Speicher.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendungsüberprüfung einen IsBadXXXPtr-Aufruf für eine freie Speicherzuweisung erkennt. Dies ist sehr schlecht, da es möglich ist, dass dieser Speicher in anderen Fällen bereits für eine andere Zuweisung 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 Stapelüberwachung (kb) an und versuchen, zu ermitteln, warum der Aufrufer der IsBadXXXPtr-Funktion zu einem freien Arbeitsspeicher gelangt ist. Die Adresse könnte schlichtweg falsch sein (z. B. ein nicht initialisierter Zeiger) oder möglicherweise bereits Speicher freigegeben haben. Wenn der Speicher bereits von einer der VirtualFree- oder UnmapViewOfFile-APIs freigegeben wurde, sucht „!avrf -vs -a parameter3“ nach einem Protokoll der Stapelüberprüfungen der Codepfade, die diese Adresse zugewiesen/freigegeben haben, und zeigt diese Stapelüberprüfung an, wenn sie verfügbar sind. Dies zeigt möglicherweise die Stapelüberwachung, 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 der Stapelüberprüfungen der Codepfade, die diese Adresse vom/zum Heap zugewiesen/freigegeben haben, und zeigt diese Stapelverfolgungen an, wenn sie verfügbar sind. Die MSDN-Bibliothek listet einige Gründe auf, warum Anwendungen die IsBadXXXPtr-APIs nicht verwenden sollten: In einer präemptiven Multitasking-Umgebung ist es möglich, dass ein anderer Thread den Zugriff des Prozesses auf den getesteten Speicher ändert. Das Dereferenzieren potenziell ungültiger Zeiger kann die Stapelerweiterung in anderen Threads deaktivieren. Wenn die Stapelerweiterung deaktiviert wurde und ein Thread seinen Stapel erschöpft, führt dies zur sofortigen Beendigung des übergeordneten Prozesses, ohne dass ein Fehlerfenster oder Diagnoseinformationen angezeigt werden. Von den Threads in einem Prozess wird erwartet, dass sie so zusammenarbeiten, dass keiner von ihnen Speicher freigibt, den der 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.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Startadresse.
  • Parameter 2 - Speicherblockgröße.
  • Parameter 3 - Adresse der freien Speicherseite.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: PROBE_FREE_MEM
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Prüfen einer Sicherheitsseite.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendungsüberprüfung einen IsBadXXXPtr-Aufruf für eine Speicherzuweisung erkennt, die mindestens eine GUARD_PAGE enthält. Dies ist sehr schlecht, da es sehr gut möglich ist, dass diese GUARD_PAGE das Ende des aktuellen Stapels eines Threads ist. Wie in der MSDN-Bibliothek dokumentiert: Das Dereferenzieren potenziell ungültiger Zeiger kann die Stapelerweiterung in anderen Threads deaktivieren. Wenn die Stapelerweiterung deaktiviert wurde und ein Thread seinen Stapel erschöpft, führt dies zur sofortigen Beendigung des übergeordneten Prozesses, ohne dass ein Fehlerfenster oder Diagnoseinformationen angezeigt werden. Um diesen Stopp zu debuggen, sehen Sie sich die aktuelle Stapelüberwachung (kb) an und versuchen Sie herauszufinden, warum der Aufrufer der Funktion IsBadXXXPtr letztendlich eine GUARD_PAGE abgefragt hat. Die MSDN-Bibliothek listet einige Gründe auf, warum Anwendungen die IsBadXXXPtr-APIs nicht verwenden sollten: In einer präemptiven Multitasking-Umgebung ist es möglich, dass ein anderer Thread den Zugriff des Prozesses auf den getesteten Speicher ändert. Das Dereferenzieren potenziell ungültiger Zeiger kann die Stapelerweiterung in anderen Threads deaktivieren. Wenn die Stapelerweiterung deaktiviert wurde und ein Thread seinen Stapel erschöpft, führt dies zur sofortigen Beendigung des übergeordneten Prozesses, ohne dass ein Fehlerfenster oder Diagnoseinformationen angezeigt werden. Von den Threads in einem Prozess wird erwartet, dass sie so zusammenarbeiten, dass keiner von ihnen Speicher freigibt, den der 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.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Startadresse.
  • Parameter 2 - Speicherblockgröße.
  • Parameter 3 - Adresse der Sicherheitsseite.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: PROBE_GUARD_PAGE
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Prüfen der NULL-Adresse.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendungsüberprüfung einen IsBadXXXPtr-Aufruf mit einer NULL-Adresse erkennt. Um diesen Stopp zu debuggen, sehen Sie sich die aktuelle Stapelüberwachung (kb) an und versuchen Sie herauszufinden, warum der Aufrufer der Funktion IsBadXXXPtr am Ende die NULL-Adresse erhalten hat. Dies ist normalerweise ein Zeichen dafür, dass jemand den Rückgabewert einer der Speicherzuweisungsfunktionen nicht überprüft hat. Wenn beispielsweise der folgende Code falsch ist: 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. // } Die MSDN-Bibliothek listet einige Gründe auf, warum Anwendungen die IsBadXXXPtr-APIs nicht verwenden sollten: In einer präemptiven Multitasking-Umgebung ist es möglich, dass ein anderer Thread den Zugriff des Prozesses auf den getesteten Speicher ändert. Das Dereferenzieren potenziell ungültiger Zeiger kann die Stapelerweiterung in anderen Threads deaktivieren. Wenn die Stapelerweiterung deaktiviert wurde und ein Thread seinen Stapel erschöpft, führt dies zur sofortigen Beendigung des übergeordneten Prozesses, ohne dass ein Fehlerfenster oder Diagnoseinformationen angezeigt werden. Von den Threads in einem Prozess wird erwartet, dass sie so zusammenarbeiten, dass keiner von ihnen Speicher freigibt, den der 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.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Nicht verwendet.
  • Parameter 2 - Nicht verwendet.
  • Parameter 3 - Nicht verwendet.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: PROBE_NULL
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Prüfen des Speicherblocks mit ungültiger Startadresse oder Größe.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendungsüberprüfung einen IsBadXXXPtr-Aufruf mit einer ungültigen Startadresse (z. B. eine Kernelmodusadresse anstelle einer normalen Benutzermodusadresse) oder einer ungültigen Größe für den zu prüfenden Speicherpuffer erkennt. Um diesen Stopp zu debuggen, sehen Sie sich die aktuelle Stapelüberwachung (kb) an und versuchen Sie herauszufinden, warum der Aufrufer der Funktion IsBadXXXPtr eine ungültige Adresse oder Größe erhalten hat. In vielen Fällen sind die Adresse oder Größe schlicht falsch, z. B. eine nicht initialisierte Variable. Die MSDN-Bibliothek listet einige Gründe auf, warum Anwendungen die IsBadXXXPtr-APIs nicht verwenden sollten: In einer präemptiven Multitasking-Umgebung ist es möglich, dass ein anderer Thread den Zugriff des Prozesses auf den getesteten Speicher ändert. Das Dereferenzieren potenziell ungültiger Zeiger kann die Stapelerweiterung in anderen Threads deaktivieren. Wenn die Stapelerweiterung deaktiviert wurde und ein Thread seinen Stapel erschöpft, führt dies zur sofortigen Beendigung des übergeordneten Prozesses, ohne dass ein Fehlerfenster oder Diagnoseinformationen angezeigt werden. Von den Threads in einem Prozess wird erwartet, dass sie so zusammenarbeiten, dass keiner von ihnen Speicher freigibt, den der 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.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Startadresse.
  • Parameter 2 - Speicherblockgröße.
  • Parameter 3 - Nicht verwendet.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: PROBE_INVALID_START_OR_SIZE
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

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

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendungsüberprüfung einen DLL-Entladevorgang 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.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - DLL-Speicherbasisadresse.
  • Parameter 2 - DLL-Speicherbereichsgröße.
  • Parameter 3 - DLL-Namensadresse. Verwenden von du zur Abfrage.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: INVALID_DLL_RANGE
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Speicherblock innerhalb des Stapeladressbereichs des aktuellen Threads wird freigegeben.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendungsüberprüfung 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 Stapelüberwachung (kb) an und versuchen Sie zu verstehen, warum die Funktion, die VirtualFree aufgerufen hat, dachte, der Speicherblock sei dynamisch zugewiesen oder zugeordnet, obwohl es sich tatsächlich um vom Stapel zugewiesenen Speicher handelte.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Basisadresse der Zuordnung.
  • Parameter 2 - Speicherbereichsgröße
  • Parameter 3 - Adresse der unteren Stapelbegrenzung.
  • Parameter 4 - Adresse mit hoher Stapelgrenze.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: FREE_THREAD_STACK_MEMORY
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Falscher FreeType-Parameter für VirtualFree-Vorgang.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendungsüberprüfung 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 als diesen beiden aufgerufen wird, kann VirtualFree den Speicher nicht freigeben. Um diesen Stopp zu debuggen, sehen Sie sich die aktuellen Stapelüberwachung (kb) an: Der Aufrufer von VirtualFree ist wahrscheinlich das Problem.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 : Falscher Wert, der von der Anwendung verwendet wird.
  • Parameter 2 - Richtiger erwarteter Wert 1.
  • Parameter 3 - Richtiger erwarteter Wert 2.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: INVALID_FREE_TYPE
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Es wird versucht, einen virtuellen Speicherblock freizugeben, der bereits frei ist.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendungsüberprüfung ein VirtualFree für eine Adresse erkennt, die bereits frei ist. Um diesen Stopp zu debuggen, sehen Sie sich die aktuelle Stapelüberwachung (kb) an und versuchen Sie herauszufinden, warum der Speicher bereits frei ist, die Anwendung aber versucht, ihn erneut freizugeben. „!avrf -vs -a parameter1“ sucht nach einem Protokoll der Stapelüberwachung der Codepfade, die diese Adresse zugewiesen/freigegeben haben, und zeigt diese Stapelüberwachungen an, wenn sie verfügbar sind. Dies zeigt möglicherweise die Stapelüberwachung, die diesen Speicher freigegeben hat.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Speicherblockadresse.
  • Parameter 2 - Nicht verwendet.
  • Parameter 3 - Nicht verwendet.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: MEM_ALREADY_FREE
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Falscher Größenparameter für den VirtualFree-Vorgang (MEM_RELEASE).

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendungsü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 aktuellen Stapelüberwachung (kb) an: Der Aufrufer von VirtualFree ist wahrscheinlich das Problem.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 : Falsche Größe, die von der Anwendung verwendet wird.
  • Parameter 2 - Richtige erwartete Größe (0).
  • Parameter 3 - Nicht verwendet.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: INVALID_FREE_SIZE
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Unerwartete Ausnahme in der DLL-Eintrittspunktroutine.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Einstiegspunktfunktion (DllMain) einer DLL eine Ausnahme auslöst. Ein Beispiel dafür, weshalb dies schlecht ist: if DllMain(DLL_PROCESS_ATTACH) is raising an exception, the Windows DLL loader will: - Catch and hide the exception; - Unload the DLL without calling its DllMain(DLL_PROCESS_DETACH). In vielen Fällen hat die DLL einige Ressourcen bereits zugewiesen, dann die Ausnahme ausgelöst und hat keine Chance, diese Ressourcen auf DllMain freizugeben (DLL_PROCESS_DETACH). Zum Debuggen dieses Stopps: $ du Parameter1 – zum Anzeigen des DLL-Namens; $ .exr Parameter2 – zum Anzeigen der Ausnahmeinformationen; $ .cxr Parameter3 gefolgt von kb – zum Anzeigen der Ausnahmekontextinformationen und des Stapelüberwachungsprotokolls für den Zeitpunkt, als die Ausnahme aufgetreten ist; $ Parameter4 ist die Adresse einer internen Prüfer-Struktur und hat für die meisten Prüfer-Benutzer keine Bedeutung.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - DLL-Name (du zum Aufrufen verwenden).
  • Parameter 2 - Ausnahmedatensatz. Verwenden Sie .exr, um ihn anzuzeigen.
  • Parameter 3 - Kontextdatensatz. Verwenden Sie .cxr, um ihn anzuzeigen.
  • Parameter 4 - DLL-Deskriptor des Prüfers

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: DLL_UNEXPECTED_EXCEPTION
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Unerwartete Ausnahme in der Thread-Funktion aufgetreten.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn eine Thread-Funktion eine Ausnahme auslöst. Dies ist schlecht, da dadurch der gesamte Prozess beendet wird. Um diesen Stopp zu debuggen: $parameter1 kann für den Ausnahmetyp von Bedeutung sein. Beispielsweise bedeutet ein Ausnahmecode C0000005 eine Zugriffsverletzung; $ .exr Parameter2 – zum Anzeigen der Ausnahmeinformationen; $ .cxr Parameter3 gefolgt von kb – zum Anzeigen der Ausnahmekontextinformationen;

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Ausnahmecode.
  • Parameter 2 - Ausnahmedatensatz. Verwenden Sie .exr, um ihn anzuzeigen.
  • Parameter 3 - Kontextdatensatz. Verwenden Sie .cxr, um ihn anzuzeigen.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: THREAD_UNEXPECTED_EXCEPTION
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Beim Prüfen des Speichers ist eine unerwartete Ausnahme aufgetreten.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn während eines IsBadXXXPtr-Aufrufs eine Ausnahme erhalten. Dies bedeutet, dass der Speicherpuffer, den wir prüfen, nicht über den vom Aufrufer angenommenen Schutz verfügt oder dass der Speicher bereits freigegeben wurde usw. Weitere Beispiele, warum die Verwendung der IsBadXXXPtr-APIs nicht empfohlen wird, finden Sie in der obigen Erläuterung zu anderem Stoppcode (PROBE_INVALID_ADDRESS, PROBE_FREE_MEM, PROBE_GUARD_PAGE, PROBE_NULL, PROBE_INVALID_START_OR_SIZE). Zum Debuggen dieses Stopps: $ Parameter1 ist normalerweise C0000005 und bedeutet Zugriffsverletzung; $ .exr Parameter2 – um die Ausnahmeinformationen anzuzeigen; $ .cxr Parameter3 gefolgt von kb – um die Ausnahmekontextinformationen und den Stapelüberwachungsbericht zum Zeitpunkt der Ausnahmeauslösung anzuzeigen;

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Ausnahmecode.
  • Parameter 2 - Ausnahmedatensatz. Verwenden Sie .exr, um ihn anzuzeigen.
  • Parameter 3 - Kontextdatensatz. Verwenden Sie .cxr, um ihn anzuzeigen.
  • Parameter 4 - Nicht verwendet

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: PROBE_UNEXPECTED_EXCEPTION
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Es wird versucht, die NULL-Adresse zurückzusetzen.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendungsüberprüfung einen VirtualFree-Aufruf (MEM_RESET) mit einem ersten NULL-Parameter erkennt. MEM_RESET sollte nur für bereits zugewiesenen Speicher verwendet werden, daher ist NULL in diesem Fall kein gültiger erster Parameter.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Nicht verwendet.
  • Parameter 2 - Nicht verwendet.
  • Parameter 3 - Nicht verwendet.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: INVALID_MEM_RESET
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Freigabe eines Heap-Speicherblocks innerhalb des Stapeladressbereichs des aktuellen Threads.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendungsüberprüfung einen HeapFree 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 Stapelüberwachung (kb) an und versuchen Sie zu verstehen, warum die Funktion, die HeapFree aufgerufen hat, dachte, der Speicherblock sei dynamisch zugewiesen oder zugeordnet, obwohl es sich tatsächlich um vom Stapel zugewiesenen Speicher handelte.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Basisadresse der Zuordnung.
  • Parameter 2 - Speicherbereichsgröße
  • Parameter 3 - Adresse der unteren Stapelbegrenzung.
  • Parameter 4 - Adresse mit hoher Stapelgrenze.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: FREE_THREAD_STACK_MEMORY_AS_HEAP
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

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

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendungsüberprüfung ein UnmapViewOfFile 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 Stapelüberwachung (kb) an und versuchen Sie zu verstehen, warum die Funktion, die UnmapViewOfFile aufgerufen hat, dachte, der Speicherblock sei dynamisch zugewiesen oder zugeordnet, obwohl es sich tatsächlich um vom Stapel zugewiesenen Speicher handelte.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Basisadresse der Zuordnung.
  • Parameter 2 - Speicherbereichsgröße
  • Parameter 3 - Adresse der unteren Stapelbegrenzung.
  • Parameter 4 - Adresse mit hoher Stapelgrenze.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: FREE_THREAD_STACK_MEMORY_AS_MAP
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Falsche RTL_RESOURCE-Adresse.

Wahrscheinliche Ursache

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 von Prüfstopp auslöst. param1 ist die verwendete falsche Adresse und das Problem befindet sich in der Stapelüberwachung (mit kb anzeigen).

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Adresse.
  • Parameter 2 - Nicht verwendet.
  • Parameter 3 - Nicht verwendet.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: INVALID_RESOURCE_ADDRESS
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Ungültige kritische Abschnittsadresse.

Wahrscheinliche Ursache

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 Prüfstopp auslöst. param1 ist die verwendete falsche Adresse und das Problem befindet sich in der Stapelüberwachung (mit kb anzeigen).

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Adresse.
  • Parameter 2 - Nicht verwendet.
  • Parameter 3 - Nicht verwendet.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: INVALID_CRITSECT_ADDRESS
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Versuch, Code im nicht ausführbaren Speicher auszuführen.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendung versucht, Code von einer Adresse auszuführen, die nicht ausführbar oder kostenlos ist. Zum Debuggen dieses Stopps: $ u parameter2 – zum Aufheben der Assemblierung des verantwortlichen Codes $ .exr parameter3 – zur Anzeige der Ausnahmeinformationen; $ .cxr parameter4 gefolgt von kb – zur Anzeige der Ausnahmekontextinformationen und der Stapelverfolgung, wenn die Ausnahme ausgelöst wurde.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Adresse, auf die zugegriffen wird.
  • Parameter 2 - Code für ungültigen Zugriff.
  • Parameter 3 - Ausnahmedatensatz. Verwenden Sie .exr, um ihn anzuzeigen.
  • Parameter 4 - Kontextdatensatz. Verwenden Sie .cxr, um ihn anzuzeigen.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: THREAD_UNEXPECTED_EXCEPTION_CODE
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Beim Initialisieren des Ausgabepuffers ist eine unerwartete Ausnahme aufgetreten.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn beim Initialisieren eines Puffers, der als Ausgabeparameter für eine Win32- oder CRT-API angegeben ist, eine Ausnahme auftritt. Dies bedeutet normalerweise, dass die angegebene Ausgabepuffergröße falsch ist. Zum Debuggen dieses Stopps: $ .exr Parameter3 – um die Ausnahmeinformationen anzuzeigen; $ .cxr Parameter4 gefolgt von kb – um die Ausnahmekontextinformationen und den Stapelüberwachungsbericht zum Zeitpunkt des Auftretens der Ausnahme anzuzeigen.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Startadresse des Puffers.
  • Parameter 2 - Puffergröße.
  • Parameter 3 - Ausnahmedatensatz. Verwenden Sie .exr, um ihn anzuzeigen.
  • Parameter 4 - Kontextdatensatz. Verwenden Sie .cxr, um ihn anzuzeigen.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: OUTBUFF_UNEXPECTED_EXCEPTION
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Unerwartete Ausnahme beim Versuch, die Heap-Blockgröße zu ermitteln.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn beim Aufrufen von HeapSize für einen Heap-Block, der freigegeben wird, eine Ausnahme auftritt. Dies bedeutet normalerweise, dass die angegebene Heap-Blockadresse falsch oder der Heap beschädigt ist. Zum Debuggen dieses Stopps: $ .exr Parameter3 – um den Ausnahmedatensatz anzuzeigen; $ .cxr Parameter4 gefolgt von kb – um die Kontextinformationen und die Stapelüberwachung für den Zeitpunkt anzuzeigen, als die Ausnahme aufgetreten ist.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Adresse des freigegebenen Heapblocks.
  • Parameter 2 - Heap-Handle.
  • Parameter 3 - Ausnahmedatensatz. Verwenden Sie .exr, um ihn anzuzeigen.
  • Parameter 4 - Kontextdatensatz. Verwenden Sie .cxr, um ihn anzuzeigen.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: SIZE_HEAP_UNEXPECTED_EXCEPTION
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Speicherblock mit ungültiger Startadresse wird freigegeben.

Wahrscheinliche Ursache

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 wurde, als der Seitenbereich reserviert wurde. Zum Debuggen dieses Stopps: $ kb – um die aktuellen Stapelüberwachung anzuzeigen, die VirtualFree aufruft. Die wahrscheinliche Ursache ist die DLL, die VirtualFree aufruft.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Adresse des Speicherblocks, der freigegeben wird.
  • Parameter 2 - Richtige erwartete Speicherblockadresse.
  • Parameter 3 - Nicht verwendet.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: INVALID_FREEMEM_START_ADDRESS
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Aufheben der Zuordnung eines Speicherblocks mit ungültiger Startadresse.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn das Programm UnmapViewOfFile mit einem lpBaseAddress-Parameter aufruft, der nicht mit dem Wert identisch ist, der von einem vorherigen Aufruf der Funktion MapViewOfFile oder MapViewOfFileEx zurückgegeben wurde. Zum Debuggen dieses Stopps: $ kb - zum Anzeigen der aktuellen Stapelüberwachung, die unmapViewOfFile aufruft. Die wahrscheinliche Ursache ist die DLL, die UnmapViewOfFile aufruft.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Adresse des Speicherblocks, der nicht zugeordnet wird.
  • Parameter 2 - Richtige erwartete Speicherblockadresse.
  • Parameter 3 - Nicht verwendet.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: INVALID_UNMAPVIEW_START_ADDRESS
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Unerwartete Ausnahme in der Threadpool-Rückruffunktion.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn eine Rückruffunktion im Threadpool-Thread eine Ausnahme auslöst. Um diesen Stopp zu debuggen: $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 – um die Ausnahmekontextinformationen anzuzeigen.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Ausnahmecode
  • Parameter 2 - Ausnahmedatensatz. Verwenden von .exr zum Anzeigen
  • Parameter 3 - Kontextdatensatz. Verwenden von .cxr zum Anzeigen
  • Parameter 4 - Nicht verwendet

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: THREADPOOL_UNEXPECTED_EXCEPTION
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Code im nicht ausführbaren Speicher

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendung versucht, Code von einer Adresse auszuführen, die nicht ausführbar oder kostenlos ist. Zum Debuggen dieses Stopps: $ u parameter2 – zum Aufheben der Assemblierung des verantwortlichen Codes $ .exr parameter3 – zur Anzeige der Ausnahmeinformationen; $ .cxr parameter4 gefolgt von kb – zur Anzeige der Ausnahmekontextinformationen und der Stapelverfolgung, wenn die Ausnahme ausgelöst wurde.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Adresse, auf die zugegriffen wird.
  • Parameter 2 - Code für ungültigen Zugriff.
  • Parameter 3 - Ausnahmedatensatz. Verwenden Sie .exr, um ihn anzuzeigen.
  • Parameter 4 - Kontextdatensatz. Verwenden Sie .cxr, um ihn anzuzeigen.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: THREADPOOL_UNEXPECTED_EXCEPTION_CODE
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Erstellen von ausführbarem Heap.

Wahrscheinliche Ursache

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

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Nicht verwendet.
  • Parameter 2 - Nicht verwendet.
  • Parameter 3 - Nicht verwendet.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: EXECUTABLE_HEAP
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Zuweisen von ausführbarem Speicher.

Wahrscheinliche Ursache

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

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Vom Anrufer angegebener Seitenschutz.
  • Parameter 2 - Nicht verwendet.
  • Parameter 3 - Nicht verwendet.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Speicher
  • Stopp-ID: EXECUTABLE_MEMORY
  • Stoppcode: 600NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

TLS-Stopp-Details

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

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn eine DLL, die einen TLS-Index zugewiesen hat, entladen wird, bevor dieser TLS-Index freigegeben wird. Zum Debuggen dieses Stopps: $ du Parameter3 – zeigt den Namen der fehlerhaften DLL an; $ .reload xxx.dll=Parameter4 – lädt Symbole für die fehlerhafte DLL neu (falls erforderlich). xxx.dll ist der Name der im obigen Schritt angezeigten DLL; $ u Parameter2 – disassemblieren Sie den Code, der das TLS zugewiesen hat. Dies sollte auf die Funktion verweisen, die das TLS zugeordnet hat, aber vergessen hat, sie frei zu geben, bevor die DLL entladen wurde.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - TLS-Index
  • Parameter 2 - Adresse des Codes, der diesen TLS-Index zugewiesen hat.
  • Parameter 3 - DLL-Namensadresse. Verwenden von du zur Abfrage.
  • Parameter 4 - DLL-Basisadresse.

Weitere Informationen
  • Testebene: TLS
  • Stopp-ID: TLS_LEAK
  • Stoppcode: 350NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Beschädigte TLS-Struktur des Prüfers.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die internen Prüfstrukturen, die zum Speichern des Status der TLS-Slots für Threads verwendet werden, beschädigt sind. Sehr wahrscheinlich liegt dies an einer zufälligen Beschädigung während des Prozesses.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - TEB-Adresse.
  • Parameter 2 - Erwartete TEB-Adresse.
  • Parameter 3 - Thread-ID.
  • Parameter 4 - Erwartete Thread-ID.

Weitere Informationen
  • Testebene: TLS
  • Stopp-ID: CORRUPTED_TLS
  • Stoppcode: 350NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Verwenden eines ungültigen TLS-Index.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn ein ungültiger TLS-Index verwendet wird. In den meisten Fällen liegt dies daran, dass der Code diesen Index immer noch verwendet, wenn TlsFree aufgerufen wird. Hier ist ein Beispiel für den Threadpoolthread. T1: DLL wird geladen und TlsAlloc T1: Rückruf in Warteschlange T1: Übersprungener wartender/abgebrochener Rückruf T1: TlsFree T2: Rückruf wird ausgeführt und ruft TlsSetValue auf T1: DLL wird entladen

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - TLS-Index
  • Parameter 2 - Nicht verwendet.
  • Parameter 3 - Nicht verwendet.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: TLS
  • Stopp-ID: INVALID_TLS_INDEX
  • Stoppcode: 350NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Threadpool-Stoppdetails

Die Priorität dieses Threadpool-Threads wurde geändert.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Thread-Priorität bei der Rückgabe an den Threadpool geändert wird.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Format: -  Threadpoolthread (%x) mit ausgeführtem Rückruf (%p) hat eine geänderte Threadpriorität (%i -> %i)
  • Parameter 1 - Rückruffunktion.
  • Parameter 2 - Kontext.
  • Parameter 3 - Stapelüberwachung der Threadpool-Objektzuweisung. dps zum Aufrufen verwenden.
  • Parameter 4 - Aktuelle Priorität.

Weitere Informationen
  • Testebene: Threadpool
  • Stopp-ID: INCONSISTENT_PRIORITY
  • Stoppcode: 700NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Die Affinität dieses Threadpool-Threads wurde geändert.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Thread-Affinität bei der Rückgabe an den Threadpool geändert wird.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Format: - Threadpool-Thread (%x), der Callback (%p) ausgeführt hat, hat eine geänderte Thread-Affinitätsmaske (%p -> %p)
  • Parameter 1 - Rückruffunktion.
  • Parameter 2 - Kontext.
  • Parameter 3 - Stapelüberwachung der Threadpool-Objektzuweisung. dps zum Aufrufen verwenden.
  • Parameter 4 - Aktuelle Affinität.

Weitere Informationen
  • Testebene: Threadpool
  • Stopp-ID: INCONSISTENT_AFFINITY_MASK
  • Stoppcode: 700NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Unbearbeitete Nachricht im Nachrichtenpool des aktuellen Threads.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn bei der Rückgabe dieses Threadpool-Threads an den Pool eine Nachricht als unverarbeitet übrig bleibt. Dies ist gefährlich, da es in einem völlig anderen Kontext verarbeitet wird. Verwenden Sie !avrf -tp <Param4>, um die in diesem Thread geposteten Nachrichten anzuzeigen.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Format: - Threadpool-Thread (%x), der Callback (%p) ausgeführt hat, hat eine ausstehende Fensternachricht (%x: %x)
  • Parameter 1 - Rückruffunktion.
  • Parameter 2 - Kontext.
  • Parameter 3 - Stapelüberwachung der Threadpool-Objektzuweisung. dps zum Aufrufen verwenden.
  • Parameter 4 - Threadpool-Thread-ID. Verwenden Sie !avrf -tp <threadid>, um die in diesem Thread geposteten Nachrichten anzuzeigen.

Weitere Informationen
  • Testebene: Threadpool
  • Stopp-ID: ORPHANED_THREAD_MESSAGE
  • Stoppcode: 700NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Das nicht geschlossene Fenster gehörte zum aktuellen Thread.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn ein beliebiges Fenster aktiv gehalten wird, wenn dieser Threadpool-Thread an den Pool zurückgegeben wird.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Format: -  Threadpool-Thread (%x), der Callback (%p) ausgeführt hat, hat einen gültigen hwnd (%x: %s), der Nachrichten empfangen könnte
  • Parameter 1 - Rückruffunktion.
  • Parameter 2 - Kontext.
  • Parameter 3 - Stapelüberwachung der Threadpool-Objektzuweisung. dps zum Aufrufen verwenden.
  • Parameter 4 - Threadpool-Thread-ID.

Weitere Informationen
  • Testebene: Threadpool
  • Stopp-ID: ORPHANED_THREAD_WINDOW
  • Stoppcode: 700NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

ExitThread() in einem Threadpool-Thread.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn ExitThread für einen Threadpool-Thread aufgerufen wird. Dies ist verboten, da das System dadurch instabil wird. Dies kann zu einem Ressourcenverlust, Einfrieren oder AV führen.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Rückruffunktion.
  • Parameter 2 - Kontext.
  • Parameter 3 - Stapelüberwachung der Threadpool-Objektzuweisung. dps zum Aufrufen verwenden.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Threadpool
  • Stopp-ID: ILLEGAL_THREAD_EXIT
  • Stoppcode: 700NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Der Thread befindet sich im Identitätswechselzustand, wenn er an einen Threadpool-Thread zurückgegeben wird.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Rückruffunktion das Thread-Token ändert, um sich als ein anderer Benutzer auszugeben, und vergessen hat, es zurückzusetzen, bevor es an den Threadpool zurückgegeben wird.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Rückruffunktion.
  • Parameter 2 - Kontext.
  • Parameter 3 - Stapelüberwachung der Threadpool-Objektzuweisung. dps zum Aufrufen verwenden.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Threadpool
  • Stopp-ID: THREAD_IN_IMPERSONATION
  • Stoppcode: 700NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Es wird eine Funktion aufgerufen, die einen persistenten Thread erfordert.

Wahrscheinliche Ursache

Einige Microsoft Windows-APIs müssen in einem dedizierten oder persistenten Thread aufgerufen werden. Im Threadpool sollten Sie grundsätzlich die Verwendung von threadlokalem Speicher und das Einreihen asynchroner Aufrufe, die einen persistenten Thread erfordern, wie etwa die Funktion „RegNotifyChangeKeyValue“, vermeiden. Solche Funktionen können jedoch mit QueueUserWorkItem und der Option WT_EXECUTEINPERSISTENTTHREAD in die Warteschlange eines persistenten Arbeitsthreads gestellt werden. Eine KB im Debugger zeigt den Anrufer an.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Rückruffunktion.
  • Parameter 2 - Kontext.
  • Parameter 3 - Stapelüberwachung der Threadpool-Objektzuweisung. dps zum Aufrufen verwenden.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Threadpool
  • Stopp-ID: PERSISTED_THREAD_NEEDED
  • Stoppcode: 700NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Der Thread befindet sich im modifizierten Transaktionsstatus.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Rückruffunktion vergessen hat, den aktuellen Transaktions-Handle zu schließen oder zurückzusetzen.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Rückruffunktion.
  • Parameter 2 - Kontext.
  • Parameter 3 - Stapelüberwachung der Threadpool-Objektzuweisung. dps zum Aufrufen verwenden.
  • Parameter 4 - Transaktions-Handle.

Weitere Informationen
  • Testebene: Threadpool
  • Stopp-ID: DIRTY_TRANSACTION_CONTEXT
  • Stoppcode: 700NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Dieser Threadpool-Status weist unausgeglichene CoInit- und CoUnInit-Aufrufe auf.

Wahrscheinliche Ursache

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

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Rückruffunktion.
  • Parameter 2 - Kontext.
  • Parameter 3 - Stapelüberwachung der Threadpool-Objektzuweisung. dps zum Aufrufen verwenden.
  • Parameter 4 - Ausgeglichene Aufrufanzahl.

Weitere Informationen
  • Testebene: Threadpool
  • Stopp-ID: DIRTY_COM_STATE
  • Stoppcode: 700NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

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

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Zeitspanne zum Signalisieren des Timers nicht Null ist, wenn der Timer mit dem Flag WT_EXECUTEONLYONCE so eingestellt ist, dass er nur einmal signalisiert

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Zeitraum angegeben.
  • Parameter 2 - Flags angegeben.
  • Parameter 3 - Nicht verwendet.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Threadpool
  • Stopp-ID: INCONSISTENT_TIMER_PARAMS
  • Stoppcode: 700NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Die Loader-Sperre wurde vom Threadpool-Thread innerhalb des Rückrufs aufrechterhalten.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Loader-Sperre innerhalb des Rückrufs aufrechterhalten und nicht freigegeben wird, wenn der Thread an den Threadpool zurückgegeben wird.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Rückruffunktion.
  • Parameter 2 - Kontext.
  • Parameter 3 - Stapelüberwachung der Threadpool-Objektzuweisung. dps zum Aufrufen verwenden.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Threadpool
  • Stopp-ID: LOADER_LOCK_HELD
  • Stoppcode: 700NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Die bevorzugte Sprache wird vom Threadpool-Thread innerhalb des Rückrufs festgelegt.

Wahrscheinliche Ursache

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

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Rückruffunktion.
  • Parameter 2 - Kontext.
  • Parameter 3 - Stapelüberwachung der Threadpool-Objektzuweisung. dps zum Aufrufen verwenden.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Threadpool
  • Stopp-ID: PREFERRED_LANGUAGES_SET
  • Stoppcode: 700NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Die Hintergrundpriorität wird vom Threadpool-Thread innerhalb des Rückrufs festgelegt.

Wahrscheinliche Ursache

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

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Rückruffunktion.
  • Parameter 2 - Kontext.
  • Parameter 3 - Stapelüberwachung der Threadpool-Objektzuweisung. dps zum Aufrufen verwenden.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Threadpool
  • Stopp-ID: BACKGROUND_PRIORITY_SET
  • Stoppcode: 700NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

TerminateThread() in einem Threadpool-Thread.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn TerminateThread für einen Threadpool-Thread aufgerufen wird. Es ist verboten, da es System instabil macht. Dies kann zu einem Ressourcenverlust, Einfrieren oder AV führen.

Von der Anwendungsüberprüfung angezeigte Informationen
  • Parameter 1 - Nicht verwendet.
  • Parameter 2 - Nicht verwendet.
  • Parameter 3 - Nicht verwendet.
  • Parameter 4 - Nicht verwendet.

Weitere Informationen
  • Testebene: Threadpool
  • Stopp-ID: ILLEGAL_THREAD_TERMINATION
  • Stoppcode: 700NAN
  • Schweregrad: Fehler
  • Ein einmaliger Fehler: 
  • Fehlerbericht: Pause
  • Protokollierung in Datei: ja
  • Rückverfolgung erstellen: ja

Weitere Informationen

Anwendungsüberprüfung – Stoppcodes und Definitionen

Anwendungsüberprüfung – Überblick

Anwendungsüberprüfung – Funktionen

Anwendungsüberprüfung – Testen von Anwendungen

Anwendungsüberprüfung – Tests innerhalb der Anwendungsüberprüfung

Anwendungsüberprüfung – Debuggen von Stopps der Anwendungsüberprüfung

Anwendungsüberprüfung – Häufig gestellte Fragen