Anwendungsüberprüfung – Stoppcodes – Sonstiges

Die folgenden Stoppcodes sind in diesem Testsatz enthalten.

Gefährlicher Aufruf von TerminateThread.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn ein Thread (Thread-ID ist Parameter1) explizit mit TerminateThread beendet wird. Diese Funktion ist sehr gefährlich, da sie Datenbeschädigungen und Deadlocks (gemäß MSDN) verursacht.

Von Application Verifier angezeigte Informationen

• Parameter 1  - Thread-ID für den Aufrufer von Terminatethread.
• Parameter 2  - Nicht verwendet.
• Parameter 3  - Nicht verwendet.
• Parameter 4  - Nicht verwendet.

Weitere Informationen

• Testebene:  Gefährlich
• Stopp-ID:  TERMINATE_THREAD_CALL
• Code beenden:  100NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Potenzieller Stapelüberlauf bei geringem Arbeitsspeicher.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die anfängliche Stapelcommitgröße eines Threads so groß ist, dass ein Stapelüberlauf bei geringem Arbeitsspeicher ausgelöst werden kann, wenn der Stapel nicht erweitert werden kann.

Von Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  Gefährlich
• Stopp-ID:  STACK_OVERFLOW
• Code beenden:  100NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

ExitProcess wird aufgerufen, während noch mehrere Threads ausgeführt werden.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn ein Thread ExitProcess aufruft, während mehrere Threads ausgeführt werden. In einem solchen Fall wird intern TerminateThread für jeden Thread aufgerufen, was zu Deadlocks oder Datenbeschädigungen führen kann.

Von Application Verifier angezeigte Informationen

• Parameter 1  -  Anzahl der ausgeführten Threads.
• Parameter 2  - Nicht verwendet.
• Parameter 3  - Nicht verwendet.
• Parameter 4  - Nicht verwendet.

Weitere Informationen

• Testebene:  Gefährlich
• Stopp-ID:  INVALID_EXIT_PROCESS_CALL
• Code beenden:  100NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

LoadLibrary wird während dllMain aufgerufen.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn der Code in DllMain LoadLibrary oder FreeLibary aufruft. Dies ist das Verhalten, das von MSDN verboten ist.

Von Application Verifier angezeigte Informationen

• Parameter 1  - DLL-Name (du zum Sichern verwenden).
• Parameter 2  - Dll-Basisadresse.
• Parameter 3  - Nicht verwendet.
• Parameter 4  - Nicht verwendet.

Weitere Informationen

• Testebene:  Gefährlich
• Stopp-ID:  INVALID_LOAD_LIBRARY_CALL
• Code beenden:  100NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

FreeLibrary wird während dllMain aufgerufen.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn der Code in DllMain LoadLibrary oder FreeLibary aufruft. Dies ist das Verhalten, das von MSDN verboten ist.

Von Application Verifier angezeigte Informationen

• Parameter 1  - DLL-Name (du zum Sichern verwenden).
• Parameter 2  - Dll-Basisadresse.
• Parameter 3  - Nicht verwendet.
• Parameter 4  - Nicht verwendet.

Weitere Informationen

• Testebene:  Gefährlich
• Stopp-ID:  INVALID_FREE_LIBRARY_CALL
• Code beenden:  100NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

SetProcessWorkingSetSize wird mit MinimumWorkingSetSize = 0xFFFFFFFF aufgerufen.

Wahrscheinliche Ursache

Verwenden Sie MinimumWorkingSetSize = (SIZE_T) -1.

Von Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  Gefährlich
• Stopp-ID:  INVALID_MINIMUM_PROCESS_WORKING_SIZE
• Code beenden:  100NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

SetProcessWorkingSetSize wird mit MaximumWorkingSetSize = 0xFFFFFFFF aufgerufen.

Wahrscheinliche Ursache

Verwenden Sie MaximumWorkingSetSize = (SIZE_T) -1.

Von Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  Gefährlich
• Stopp-ID:  INVALID_MAXIMUM_PROCESS_WORKING_SIZE
• Code beenden:  100NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

SetProcessWorkingSetSizeEx wird mit MinimumWorkingSetSize = 0xFFFFFFFF aufgerufen.

Wahrscheinliche Ursache

Verwenden Sie MinimumWorkingSetSize = (SIZE_T) -1.

Von Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  Gefährlich
• Stopp-ID:  INVALID_MINIMUM_PROCESS_WORKING_SIZE_EX
• Code beenden:  100NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

SetProcessWorkingSetSizeEx wird mit MaximumWorkingSetSize = 0xFFFFFFFF aufgerufen.

Wahrscheinliche Ursache

Verwenden Sie MaximumWorkingSetSize = (SIZE_T) -1.

Von Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  Gefährlich
• Stopp-ID:  INVALID_MAXIMUM_PROCESS_WORKING_SIZE_EX
• Code beenden:  100NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Der Thread kann keinen kritischen Abschnitt besitzen.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn ein Thread (Thread-ID ist Parameter1) beendet, angehalten oder sich in einem Zustand (Arbeitsthread hat ein Arbeitselement abgeschlossen) befindet, in dem er keinen kritischen Abschnitt enthalten kann. Der aktuelle Thread ist der Schuldige. Verwenden Sie zum Debuggen dieses Stopps die folgenden Debuggerbefehle: $kb , um die aktuelle Stapelüberwachung abzurufen. 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: Speicherabbildinformationen zu diesem kritischen Abschnitt. $ln-Parameter2, um Symbole in der Nähe der Adresse des kritischen Abschnitts anzuzeigen. Dies sollte helfen, den durchgesickerten kritischen Abschnitt zu identifizieren. $dps-Parameter4, um die Stapelüberwachung für diese kritische Abschnittsinitialisierung abzuspeichern.

Von Application Verifier angezeigte Informationen

• Parameter 1  - Thread-ID.
• Parameter 2  Adresse  des kritischen Abschnitts.
• Parameter 3  Adresse  für Debuginformationen im Kritischen Abschnitt.
• Parameter 4  - Kritische Abschnittsinitialisierungsstapelablaufverfolgung.

Weitere Informationen

• Testebene:  Sperren
• Stopp-ID:  EXIT_THREAD_OWNS_LOCK
• Code beenden:  200NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Entladen der DLL mit einem aktiven kritischen Abschnitt.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn eine DLL eine globale Variable mit einem kritischen Abschnitt enthält und die DLL entladen wird, aber der kritische Abschnitt nicht gelöscht wurde. Verwenden Sie zum Debuggen dieses Stopps die folgenden Debuggerbefehle: $du parameter3 , um den Namen der Täter-DLL abzuspeichern. $ .reload dllname oder .reload dllname = parameter4 – um die Symbole für diese DLL neu zu laden. $ !cs -s Parameter1: Speicherabbildinformationen zu diesem kritischen Abschnitt. $ln-Parameter1, um Symbole in der Nähe der Adresse des kritischen Abschnitts anzuzeigen. Dies sollte helfen, den durchgesickerten kritischen Abschnitt zu identifizieren. $dps-Parameter2, um die Stapelüberwachung für diese kritische Abschnittsinitialisierung abzuspeichern.

Von Application Verifier angezeigte Informationen

• Parameter 1  Adresse  des kritischen Abschnitts.
• Parameter 2  - Kritische Abschnittsinitialisierungsstapelablaufverfolgung.
• Parameter 3  - DLL-Namensadresse.
• Parameter 4  - DLL-Basisadresse.

Weitere Informationen

• Testebene:  Sperren
• Stopp-ID:  LOCK_IN_UNLOADED_DLL
• Code beenden:  200NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

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

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn eine Heapzuordnung einen kritischen Abschnitt enthält, die Zuordnung freigegeben und der kritische Abschnitt nicht gelöscht wurde. Verwenden Sie zum Debuggen dieses Stopps die folgenden Debuggerbefehle: $ !cs -s Parameter1 – Dumpinformationen zu diesem kritischen Abschnitt. $ln-Parameter1, um Symbole in der Nähe der Adresse des kritischen Abschnitts anzuzeigen. Dies sollte helfen, den durchgesickerten kritischen Abschnitt zu identifizieren. $dps-Parameter2, um die Stapelüberwachung für diese kritische Abschnittsinitialisierung abzuspeichern. $parameter3 und parameter4 können helfen zu verstehen, wo dieser Heapblock zugeordnet wurde (die Größe der Zuordnung ist wahrscheinlich signifikant).

Von Application Verifier angezeigte Informationen

• Parameter 1  Adresse  des kritischen Abschnitts.
• Parameter 2  - Kritische Abschnittsinitialisierungsstapelablaufverfolgung.
• Parameter 3  - Heap-Blockadresse.
• Parameter 4  - Heap-Blockgröße.

Weitere Informationen

• Testebene:  Sperren
• Stopp-ID:  LOCK_IN_FREED_HEAP
• Code beenden:  200NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Doppelt initialisierter oder beschädigter kritischer Abschnitt.

Wahrscheinliche Ursache

In der Regel wird dieser Stopp generiert, wenn ein kritischer Abschnitt mehrmals initialisiert wurde. In diesem Fall sind parameter3 und parameter4 die Stapelüberwachungsadressen für zwei dieser Initialisierungen. In einigen anderen Fällen ist es möglich, diesen Stopp zu erhalten, wenn der kritische Abschnitt oder seine Debuginformationsstruktur beschädigt wurde. In diesem zweiten Fall ist es möglich, dass parameter3 und parameter4 ungültig und nutzlos sind. Zum Debuggen dieses Stopps: $ !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 helfen, den kritischen Abschnitt zu identifizieren, 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 Application Verifier angezeigte Informationen

• Parameter 1  Adresse  des kritischen Abschnitts.
• Parameter 2  - Adresse der Debuginformationsstruktur in der aktiven Liste.
• Parameter 3  -  Erste Initialisierungsstapelablaufverfolgung.
• Parameter 4  -  Zweite Initialisierungsstapelablaufverfolgung.

Weitere Informationen

• Testebene:  Sperren
• Stopp-ID:  LOCK_DOUBLE_INITIALIZE
• Code beenden:  200NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Freier Arbeitsspeicher, 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 mithilfe von DeleteCriticalSection gelöscht wurde. Verwenden Sie zum Debuggen dieses Stopps die folgenden Debuggerbefehle: $ !cs -s -d Parameter2 – Dumpinformationen zu diesem kritischen Abschnitt. $dps-Parameter3, um den Codepfad für die Initialisierung dieses kritischen Abschnitts zu identifizieren. In den meisten Fällen erkennt die Sperrüberprüfung sofort kompromittierte kritische Abschnitte, die in einer Heapzuordnung, einem DLL-Bereich, einer virtuellen Speicherbelegung oder einem zugeordneten MapViewOfFile-Speicherbereich enthalten sind, und gibt in diesen Fällen verschiedene Stopps aus. Es gibt also nur noch sehr wenige Fälle für diesen Prüferstopp. Die Sperre muss sich in einem Speicherbereich befinden, der durch Kernelmoduscode oder prozessübergreifend durch APIs wie VirtualFreeEx freigegeben wurde. In der Regel tritt dieser Stopp auf, wenn ein vorheriger Stopp (z. B. LOCK_IN_FREED_HEAP oder LOCK_IN_UNLOADED_DLL) fortgesetzt wurde, indem "g" in der Debuggerkonsole gedrückt wurde.

Von Application Verifier angezeigte Informationen

• Parameter 1  Adresse  des kritischen Abschnitts.
• Parameter 2  Adresse  für Debuginformationen im Kritischen Abschnitt.
• Parameter 3  - Kritische Abschnittsinitialisierungsstapelablaufverfolgung.
• Parameter 4  - Nicht verwendet.

Weitere Informationen

• Testebene:  Sperren
• Stopp-ID:  LOCK_IN_FREED_MEMORY
• Code beenden:  200NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Beschädigter kritischer Abschnitt.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn das Feld DebugInfo des kritischen Abschnitts auf freigegebenen Arbeitsspeicher verweist. In der Regel befindet sich eine andere gültige DebugInfo-Struktur in der Liste der aktiven kritischen Abschnitte. Ohne Beschädigung sollten die beiden Zeiger identisch sein. Verwenden Sie zum Debuggen dieses Stopps die folgenden Debuggerbefehle: $ !cs -s -d Parameter3 - Dumpinformationen zu diesem kritischen Abschnitt basierend auf dem aktuellen Inhalt der Debuginformationsstruktur in der aktiven Liste (diese Struktur ist selten beschädigt, sodass diese Informationen normalerweise vertrauenswürdig sind). $ !cs -s Parameter1 : Speicherabbildinformationen zu diesem kritischen Abschnitt basierend auf dem aktuellen Inhalt der kritischen Abschnittsstruktur (die Struktur ist bereits beschädigt, sodass diese Informationen manchmal NICHT vertrauenswürdig sind). $ dps parameter4 , um den Codepfad für die Initialisierung dieses kritischen Abschnitts zu identifizieren. Sichern Sie den kritischen Abschnitt unter adressparameter1, 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 Application Verifier angezeigte Informationen

• Parameter 1  Adresse  des kritischen Abschnitts.
• Parameter 2  -  Ungültige Debuginformationsadresse dieses kritischen Abschnitts.
• Parameter 3  -  Adresse der Debuginformationen in der aktiven Liste.
• Parameter 4  -  Ablaufverfolgung des Initialisierungsstapels.

Weitere Informationen

• Testebene:  Sperren
• Stopp-ID:  LOCK_CORRUPTED
• Code beenden:  200NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Ungültiger Thread des Besitzers des kritischen Abschnitts.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Besitzerthread-ID im aktuellen Kontext ungültig ist. Zum Debuggen dieses Stopps: $ !cs -s Parameter1 - Dumpinformationen zu diesem kritischen Abschnitt. $ln-Parameter1, um Symbole in der Nähe der Adresse des kritischen Abschnitts anzuzeigen. Dies sollte helfen, den kritischen Abschnitt zu identifizieren.

Von Application Verifier angezeigte Informationen

• Parameter 1  Adresse  des kritischen Abschnitts.
• Parameter 2  -  Besitzender Thread.
• Parameter 3  –  Es wurde erwartet, dass ein Thread besitzt.
• Parameter 4  Adresse  für Debuginformationen im Kritischen Abschnitt.

Weitere Informationen

• Testebene:  Sperren
• Stopp-ID:  LOCK_INVALID_OWNER
• Code beenden:  200NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Ungültige Anzahl kritischer Abschnittsrekursionen.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn das Feld rekursionsanzahl der kritischen Abschnittsstruktur im aktuellen Kontext ungültig ist. Zum Debuggen dieses Stopps: $ !cs -s Parameter1 - Dumpinformationen zu diesem kritischen Abschnitt. $ln-Parameter1, um Symbole in der Nähe der Adresse des kritischen Abschnitts anzuzeigen. Dies sollte helfen, den kritischen Abschnitt zu identifizieren.

Von Application Verifier angezeigte Informationen

• Parameter 1  Adresse  des kritischen Abschnitts.
• Parameter 2  - Rekursionsanzahl.
• Parameter 3  -  Erwartete Rekursionsanzahl.
• Parameter 4  Adresse  für Debuginformationen im Kritischen Abschnitt.

Weitere Informationen

• Testebene:  Sperren
• Stopp-ID:  LOCK_INVALID_RECURSION_COUNT
• Code beenden:  200NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

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

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn ein kritischer Abschnitt im Besitz eines Threads ist, wenn er gelöscht wird oder wenn der kritische Abschnitt nicht initialisiert wird. Zum Debuggen dieses Stopps: $ !cs -s Parameter1 - Dumpinformationen zu diesem kritischen Abschnitt. 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 helfen, den kritischen Abschnitt zu identifizieren.

Von Application Verifier angezeigte Informationen

• Parameter 1  Adresse  des kritischen Abschnitts.
• Parameter 2  - Anzahl der Sperren.
• Parameter 3  –  Anzahl der erwarteten Sperren.
• Parameter 4  -  Besitzender Thread.

Weitere Informationen

• Testebene:  Sperren
• Stopp-ID:  LOCK_INVALID_LOCK_COUNT
• Code beenden:  200NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Kritischer Abschnitt überlastet oder beschädigt.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn ein kritischer Abschnitt häufiger freigegeben wird, als der aktuelle Thread ihn abgerufen hat. Zum Debuggen dieses Stopps: $ !cs -s Parameter1 - Dumpinformationen zu diesem kritischen Abschnitt. $ !cs -s -d Parameter4: Speicherabbildinformationen zu diesem kritischen Abschnitt. $ln-Parameter1, um Symbole in der Nähe der Adresse des kritischen Abschnitts anzuzeigen. Dies sollte helfen, den kritischen Abschnitt zu identifizieren.

Von Application Verifier angezeigte Informationen

• Parameter 1  Adresse  des kritischen Abschnitts.
• Parameter 2  - Anzahl der Sperren.
• Parameter 3  –  Anzahl der erwarteten Sperren.
• Parameter 4  Adresse  für Debuginformationen im Kritischen Abschnitt.

Weitere Informationen

• Testebene:  Sperren
• Stopp-ID:  LOCK_OVER_RELEASED
• Code beenden:  200NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Kritischer Abschnitt nicht initialisiert.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn ein kritischer Abschnitt verwendet wird, ohne initialisiert zu werden oder nachdem er gelöscht wurde. So debuggen Sie diesen Stop: $ ln Parameter1 , um Symbole in der Nähe der Adresse des kritischen Abschnitts anzuzeigen. Dies sollte helfen, den kritischen Abschnitt zu identifizieren.

Von Application Verifier angezeigte Informationen

• Parameter 1  Adresse  des kritischen Abschnitts.
• Parameter 2  Adresse  für Debuginformationen im Kritischen Abschnitt.
• Parameter 3  - Nicht verwendet.
• Parameter 4  - Nicht verwendet.

Weitere Informationen

• Testebene:  Sperren
• Stopp-ID:  LOCK_NOT_INITIALIZED
• Code beenden:  200NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Der kritische Abschnitt wurde bereits initialisiert.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn ein kritischer Abschnitt vom aktuellen Thread neu initialisiert wird. Zum Debuggen dieses Stopps: $ !cs -s Parameter1 oder !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 helfen, den kritischen Abschnitt zu identifizieren, wenn es sich um eine globale Variable handelt. $dps-Parameter3, um den Codepfad für die erste Initialisierung dieses kritischen Abschnitts zu identifizieren. $ kb: Zeigt die aktuelle Stapelablaufverfolgung an, d. h. dieser wichtige Abschnitt wird neu initialisiert.

Von Application Verifier angezeigte Informationen

• Parameter 1  Adresse  des kritischen Abschnitts.
• Parameter 2  Adresse  für Debuginformationen im Kritischen Abschnitt.
• Parameter 3  -  Erste Initialisierungsstapelablaufverfolgung. Verwenden von dps, um sie abzuspeichern, wenn kein NULL-Wert ist
• Parameter 4  - Nicht verwendet.

Weitere Informationen

• Testebene:  Sperren
• Stopp-ID:  LOCK_ALREADY_INITIALIZED
• Code beenden:  200NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

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

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn der aktuelle Thread VirtualFree für einen Arbeitsspeicherblock aufruft, der einen aktiven kritischen Abschnitt enthält. Die Anwendung sollte DeleteCriticalSection in diesem wichtigen Abschnitt aufrufen, bevor dieser Arbeitsspeicher freigegeben wird. $ kb– zum Anzeigen der aktuellen Stapelüberwachung, d. h. beim Aufrufen von VirtualFree. Der wahrscheinliche Schuldige ist die DLL, die VirtualFree aufruft. $ !cs -s Parameter1: Speicherabbildinformationen zu diesem kritischen Abschnitt. $dps-Parameter2, um den Codepfad für die Initialisierung dieses kritischen Abschnitts zu identifizieren.

Von Application Verifier angezeigte Informationen

• Parameter 1  Adresse  des kritischen Abschnitts.
• Parameter 2  - Kritische Abschnittsinitialisierungsstapelablaufverfolgung.
• Parameter 3  - Speicherblockadresse.
• Parameter 4  - Speicherblockgröße.

Weitere Informationen

• Testebene:  Sperren
• Stopp-ID:  LOCK_IN_FREED_VMEM
• Code beenden:  200NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Aufheben der Belegung des 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 in diesem wichtigen Abschnitt aufrufen, bevor die Zuordnung dieses Arbeitsspeichers aufheben. $ kb : zeigt die aktuelle Stapelüberwachung an, d. h. unmapViewOfFile. Der wahrscheinliche Schuldige ist die DLL, die UnmapViewOfFile aufruft. $ !cs -s Parameter1: Speicherabbildinformationen zu diesem kritischen Abschnitt. $dps-Parameter2, um den Codepfad für die Initialisierung dieses kritischen Abschnitts zu identifizieren.

Von Application Verifier angezeigte Informationen

• Parameter 1  Adresse  des kritischen Abschnitts.
• Parameter 2  - Kritische Abschnittsinitialisierungsstapelablaufverfolgung.
• Parameter 3  - Speicherblockadresse.
• Parameter 4  - Speicherblockgröße.

Weitere Informationen

• Testebene:  Sperren
• Stopp-ID:  LOCK_IN_UNMAPPED_MEM
• Code beenden:  200NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Der aktuelle Thread besitzt keine kritischen Abschnitte.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn der aktuelle Thread LeaveCriticalSection aufruft, aber gemäß der internen Prüferbuchhaltung keinen kritischen Abschnitt besitzt. Wenn parameter2 null ist, ist dies wahrscheinlich ein Fehler im aktuellen Thread. Es versucht entweder, einen kritischen Abschnitt zu belassen, den es nicht eingegeben hat, oder vielleicht wird LeaveCriticalSection häufiger aufgerufen, als er für denselben kritischen Abschnitt EnterCriticalSection genannt hat. Wenn Parameter2 nicht null ist (eine negative ganzzahlige Zahl), sind die internen Verifierdatenstrukturen wahrscheinlich beschädigt.

Von Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  Sperren
• Stopp-ID:  THREAD_NOT_LOCK_OWNER
• Code beenden:  200NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Verwenden eines kritischen Abschnitts, 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, einen kritischen Abschnitt einzugeben, der in ntdll.dll definiert ist. Private Sperren können nicht für DLLs verwendet werden.

Von Application Verifier angezeigte Informationen

• Parameter 1  Adresse  des kritischen Abschnitts.
• Parameter 2  - Nicht verwendet.
• Parameter 3  - Nicht verwendet
• Parameter 4  - Nicht verwendet

Weitere Informationen

• Testebene:  Sperren
• Stopp-ID:  LOCK_PRIVATE
• Code beenden:  200NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Die SRW-Sperre wird nicht initialisiert.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn ein Thread versucht, die nicht initialisierte SRW-Sperre (Param1) zu verwenden. $ 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 Application Verifier 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
• Code beenden:  250NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Die SRW-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 erneute Initialisierung der Sperre zu unvorhersehbarem Verhalten der Anwendung, einschließlich Hängen und Abstürze. Die Initialisierungsstapelablaufverfolgung kann einen Abruf anzeigen, wenn die SRW-Sperre statisch initialisiert wurde. $ kb : zum Abrufen der aktuellen Stapelüberwachung. Hier wird die SRW-Sperre neu initialisiert. $ dps Param3– zum Abrufen der Ablaufverfolgung des SRW-Sperrinitialisierungsstapels. Diese Stapelablaufverfolgung kann einen Abruf anzeigen, wenn die Sperre statisch initialisiert wurde.

Von Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  SRWLock
• Stopp-ID:  ALREADY_INITIALIZED
• Code beenden:  250NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Nicht übereinstimmende Acquire-Release für die SRW-Sperre.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die SRW-Sperre (Param1) mit einer falschen Release-API freigegeben wird. Wenn die SRW-Sperre für den gemeinsamen Zugriff erworben wurde und mit der exklusiven Release-API freigegeben wird, oder die SRW-Sperre wurde für exklusiven Zugriff erworben und wird mithilfe der SHARED Release-API freigegeben. Dies kann zu unvorhersehbarem Verhalten der Anwendung führen, einschließlich Hängen 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 Ablaufverfolgung des SRW-Sperrenstapels.

Von Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  SRWLock
• Stopp-ID:  MISMATCHED_ACQUIRE_RELEASE
• Code beenden:  250NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Die SRW-Sperre wird rekursiv vom gleichen Thread abgerufen.

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 würde auf unbestimmte Zeit blockiert. Der rekursive Erwerb einer SRW-Sperre im exklusiven Modus führt zu einem Deadlock. Das rekursive Abrufen einer SRW-Sperre im freigegebenen Modus führt zu einem Deadlock, wenn ein Thread auf exklusiven Zugriff wartet. Betrachten Sie das folgende Beispiel: - Thread A ruft die SRW-Sperre im freigegebenen Modus ab – Thread B versucht, die SRW-Sperre im exklusiven Modus zu übernehmen und wartet . Thread A versucht, die SRW-Sperre rekursiv im freigegebenen Modus abzurufen. Dies ist erfolgreich, solange kein exklusiver Kellner vorhanden ist (in diesem Fall B). Da SRW-Sperren keinen Writermangel aufweisen, wartet Thread A hinter Thread B. Jetzt wartet Thread B auf Thread A, der auf Thread B wartet, was zu einem Zirkelwartevorgang und somit zu einem Deadlock führt. $ kb : zum Abrufen der aktuellen Stapelüberwachung. Hier wird die SRW-Sperre rekursiv abgerufen. $ dps Param2, um die Stapelablaufverfolgung für den ersten Abruf abzurufen.

Von Application Verifier angezeigte Informationen

• Parameter 1  - SRW-Sperre
• Parameter 2  - Adresse der ersten Abrufstapelablaufverfolgung. Verwenden Sie die dps-Adresse<>, um zu ermitteln, wo die SRW-Sperre abgerufen wurde.
• Parameter 3  - Nicht verwendet
• Parameter 4  - Nicht verwendet

Weitere Informationen

• Testebene:  SRWLock
• Stopp-ID:  RECURSIVE_ACQUIRE
• Code beenden:  250NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

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

Wahrscheinliche Ursache

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

Von Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  SRWLock
• Stopp-ID:  EXIT_THREAD_OWNS_LOCK
• Code beenden:  250NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Die SRW-Sperre, die freigegeben wird, wurde von diesem Thread nicht abgerufen.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die SRW-Sperre (Param1) vom Thread (Param2) freigegeben wird, der die Sperre nicht abgerufen hat. Dies stellt eine schlechte Programmierpraxis dar, die schwer richtig zu bekommen 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 abgerufen hat. $ dps Param4– zum Abrufen der Ablaufverfolgung des SRW-Sperrenstapels.

Von Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  SRWLock
• Stopp-ID:  INVALID_OWNER
• Code beenden:  250NAN
• Schweregrad:  Warnung
• Einmaliger Fehler: 
• Fehlerbericht:  Nichts
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

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

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die freigegebene Speicheradresse (Param1) eine aktive SRW-Sperre enthält, die noch verwendet wird. Dies kann zu unvorhersehbarem Verhalten der Anwendung führen, einschließlich Abstürze und Hängen. $ kb : zum Abrufen der aktuellen Stapelüberwachung. Hier wird der Speicher freigegeben, der eine aktive SRW-Sperre enthält. $ dps Param4– zum Abrufen der Ablaufverfolgung des SRW-Sperrenstapels.

Von Application Verifier angezeigte Informationen

• Parameter 1  - SRW-Sperre
• Parameter 2  - Adresse des freigegebenen Arbeitsspeichers.
• Parameter 3  - ThreadId des Threads, der die SRW-Sperre abgerufen hat.
• Parameter 4  - Adresse der Abrufstapelablaufverfolgung. Verwenden Sie die dps-Adresse<>, um zu ermitteln, wo die SRW-Sperre abgerufen wurde.

Weitere Informationen

• Testebene:  SRWLock
• Stopp-ID:  IN_FREED_MEMORY
• Code beenden:  250NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Die dll, die entladen wird, 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 unvorhersehbarem Verhalten der Anwendung führen, einschließlich Abstürze und Hängen. $ 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 Ablaufverfolgung des SRW-Sperrenstapels.

Von Application Verifier 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 abgerufen hat.
• Parameter 4  - Adresse der Abrufstapelablaufverfolgung. Verwenden Sie die dps-Adresse<>, um zu ermitteln, wo die SRW-Sperre abgerufen wurde.

Weitere Informationen

• Testebene:  SRWLock
• Stopp-ID:  IN_UNLOADED_DLL
• Code beenden:  250NAN
• Schweregrad:  Warnung
• Einmaliger Fehler: 
• Fehlerbericht:  Nichts
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

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

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Funktion oben im Stapel ein ungültiges Handle an Systemroutinen übergeben hat. In der Regel zeigt ein einfacher kb-Befehl den Wert des übergebenen Handles an (muss einer der Parameter sein , normalerweise der erste). Wenn der Wert NULL ist, ist dies eindeutig falsch. Wenn der Wert in Ordnung aussieht, müssen Sie die !htrace-Debuggererweiterung verwenden, um einen Verlauf der Vorgänge für diesen Handle-Wert abzurufen. In den meisten Fällen muss der Handle-Wert nach dem Schließen verwendet werden.

Von Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  Griffe
• Stopp-ID:  INVALID_HANDLE
• Code beenden:  300NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

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

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Funktion oben im Stapel einen ungültigen TLS-Index an TLS-Systemroutinen übergeben hat. Normalerweise zeigt ein einfacher kb-Befehl, was falsch ist. Der typische Fehler besteht darin, einen bestimmten Wert für einen TLS-Index anzunehmen, anstatt TlsAlloc aufzurufen. Dies kann entweder passieren, indem Sie denken, dass Sie immer den Wert N erhalten, daher ist es nicht erforderlich, TlsAlloc aufzurufen, oder häufiger aufgrund einer nicht initialisierten Variablen.

Von Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  Griffe
• Stopp-ID:  INVALID_TLS_VALUE
• Code beenden:  300NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Ungültige Parameter für waitForMultipleObjects-Aufruf.

Wahrscheinliche Ursache

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

Von Application Verifier angezeigte Informationen

• Parameter 1  - Adresse des Objekthandlesvektors.
• Parameter 2  -  Anzahl der Handles.
• Parameter 3  - Nicht verwendet.
• Parameter 4  - Nicht verwendet.

Weitere Informationen

• Testebene:  Griffe
• Stopp-ID:  INCORRECT_WAIT_CALL
• Code beenden:  300NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

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

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Funktion oben im Stapel ein NULL-Handle an Systemroutinen übergeben hat.

Von Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  Griffe
• Stopp-ID:  NULL_HANDLE
• Code beenden:  300NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Warten auf ein Threadhandle in DllMain.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn der aktuelle Thread derzeit Code in der DllMain-Funktion einer der dlLs ausführt, die im aktuellen Prozess geladen sind, und waitForSingleObject oder WaitForMultipleObjects aufgerufen wird, um auf ein Threadhandle im selben Prozess zu warten. Dies würde höchstwahrscheinlich zu einem Deadlock führen, da das Threadhandle erst dann signalisiert wird, wenn dieser zweite Thread beendet wird. Wenn der zweite Thread ExitThread aufruft, versucht er, die DLL-Ladesperre abzurufen und dann DllMain (DLL_THREAD_DETACH) für alle DLLs im aktuellen Prozess aufzurufen. Die Ladeprogrammsperre ist jedoch im Besitz des ersten Threads (der, der auf das Threadhandle wartet), sodass die beiden Threads ein Deadlock werden.

Von Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  Griffe
• Stopp-ID:  WAIT_IN_DLLMAIN
• Code beenden:  300NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace 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. Wenn Sie z. B. SetEvent mit einem Semaphorhandle als Parameter aufrufen, wird dieser Stopp generiert. So debuggen Sie diesen Stopp: $ kb , um die aktuelle Stapelablaufverfolgung anzuzeigen. Der Täter ist wahrscheinlich die DLL, die in verifier.dll aufruft. $du parameter2 : zum Anzeigen des tatsächlichen Typs des Handles. Der Handle-Wert ist parameter1. Im obigen Beispiel wird Folgendes angezeigt: Semaphor. $ du parameter3 : zum Anzeigen des von der API erwarteten Objekttyps. Im obigen Beispiel lautet dieser Name: Ereignis. $ !htrace parameter1 kann hilfreich sein, da die Stapelablaufverfolgung für die letzten Öffnen/Schließen-Vorgänge für dieses Handle angezeigt wird.

Von Application Verifier angezeigte Informationen

• Parameter 1  - Handle-Wert.
• Parameter 2  - Objekttypname. Verwenden Sie du, um sie anzuzeigen.
• Parameter 3  -  Name des erwarteten Objekttyps. Verwenden Sie du, um sie anzuzeigen.
• Parameter 4  - Nicht verwendet.

Weitere Informationen

• Testebene:  Griffe
• Stopp-ID:  INCORRECT_OBJECT_TYPE
• Code beenden:  300NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

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

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn eine DLL, die einen TLS-Index zugeordnet hat, vor dem Freigeben dieses TLS-Indexes entladen wird. So debuggen Sie diesen Stopp: $ du Parameter3 : Zeigen Sie den Namen der Täter-DLL an. $ .reload xxx.dll=parameter4 : Symbole für die Täter-DLL erneut laden (falls erforderlich). xxx.dll ist der Name der DLL, die im obigen Schritt angezeigt wird. $ u parameter2 : Zerlegen Sie den Code, der das TLS zugeordnet hat. Dies sollte auf die Funktion verweisen, die das TLS zugeordnet hat, aber vergessen hat, es frei zu geben, bevor die DLL entladen wurde.

Von Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  TLS
• Stopp-ID:  TLS_LEAK
• Code beenden:  350NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Beschädigte TLS-Struktur des Prüfers.

Wahrscheinliche Ursache

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

Von Application Verifier 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
• Code beenden:  350NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Verwenden eines ungültigen TLS-Indexes.

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 weiterhin verwendet, wenn TlsFree aufgerufen wird. Hier sehen Sie ein Beispiel für den Threadpoolthread. T1: Dll lädt und TlsAlloc T1: Warteschlangenrückruf T1: Übersprungener gewarteter/abgebrochener Rückruf T1: TlsFree T2: Rückruf wird ausgeführt und aufruft TlsSetValue T1: Dll-Entladen

Von Application Verifier 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
• Code beenden:  350NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

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

Wahrscheinliche Ursache

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

Von Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  Speicher
• Stopp-ID:  INVALID_FREEMEM
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Falscher aufruf der virtuellen Zuweisung.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die App-Überprüfung einen VirtualAlloc-Aufruf mit einer ungültigen Startadresse oder einer ungültigen Größe der Speicherbelegung erkennt. Zum Debuggen dieses Stopps 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 Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  Speicher
• Stopp-ID:  INVALID_ALLOCMEM
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Falscher Kartenansichtsaufruf.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die App-Überprüfung einen MapViewOfFile-Aufruf mit einer ungültigen Basisadresse oder größe der Zuordnung erkennt. Zum Debuggen dieses Stopps sehen Sie sich die aktuelle Stapelüberwachung (kb) sowie die Speicheradresse und größe an, die zugeordnet werden soll, und versuchen Sie zu ermitteln, warum sie ungültig sind.

Von Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  Speicher
• Stopp-ID:  INVALID_MAPVIEW
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Überprüfung ungültiger Adresse.

Wahrscheinliche Ursache

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

Von Application Verifier 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
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Testen des freien Arbeitsspeichers.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn der App-Prüfer einen IsBadXXXPtr-Aufruf für eine freie Speicherbelegung erkennt. Dies ist sehr schlecht, da es möglich ist, dass dieser Speicher in einigen anderen Fällen bereits für eine andere Zuordnung wiederverwendet wurde. Da der aktuelle Codepfad (kb) diesen Arbeitsspeicher nicht besitzt, könnte er den Speicher einer anderen Person beschädigen, was katastrophale Auswirkungen hat. Sehen Sie sich zum Debuggen dieses Stopps die aktuelle Stapelüberwachung (kb) an, und versuchen Sie zu ermitteln, warum der Aufrufer der IsBadXXXPtr-Funktion schließlich freien Arbeitsspeicher untersucht hat. Die Adresse kann einfach falsch sein (z. B. nicht initialisierter Zeiger) oder möglicherweise bereits freigegebener Arbeitsspeicher. Wenn der Speicher bereits von einer der VirtualFree- oder UnmapViewOfFile-APIs freigegeben wurde, sucht "!avrf -vs -a parameter3" nach einem Protokoll der Stapelüberwachungen der Codepfade, die diese Adresse zugeordnet/freigegeben haben, und zeigt diese Stapelablaufverfolgungen an, falls sie verfügbar sind. Dies kann die Stapelablaufverfolgung anzeigen, die diesen Arbeitsspeicher freigegeben hat. Häufiger ist der Speicher eine bereits freigegebene Heapzuordnung. Um diese Möglichkeit zu überprüfen, sucht "!avrf -hp -a parameter3" nach einem Protokoll der Stapelüberwachungen der Codepfade, die diese Adresse vom/zum Heap zugeordnet/freigegeben haben, und zeigt diese Stapelablaufverfolgungen an, falls sie verfügbar sind. Die MSDN Library listet einige Gründe auf, warum Anwendungen die IsBadXXXPtr-APIs nicht verwenden sollten: In einer präemptiven Multitaskingumgebung ist es möglich, dass ein anderer Thread den Zugriff des Prozesses auf den getesteten Arbeitsspeicher ändert. Die Dereferenzierung potenziell ungültiger Zeiger kann die Stapelerweiterung in anderen Threads deaktivieren. Ein Thread, der seinen Stapel erschöpft, wenn die Stapelerweiterung deaktiviert wurde, führt zum sofortigen Beenden des übergeordneten Prozesses ohne Popupfehlerfenster oder Diagnoseinformationen. Es wird erwartet, dass Threads in einem Prozess so zusammenarbeiten, dass einer keinen Arbeitsspeicher freigibt, den der andere benötigt. Die Verwendung dieser Funktion negiert nicht die Notwendigkeit, dies zu tun. Wenn dies nicht der Fall ist, schlägt die Anwendung möglicherweise auf unvorhersehbare Weise fehl. Aus all diesen Gründen wird empfohlen, diese APIs niemals zu verwenden.

Von Application Verifier angezeigte Informationen

• Parameter 1  - Startadresse.
• Parameter 2  - Speicherblockgröße.
• Parameter 3  - Adresse der Seite "Freier Arbeitsspeicher".
• Parameter 4  - Nicht verwendet.

Weitere Informationen

• Testebene:  Speicher
• Stopp-ID:  PROBE_FREE_MEM
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Testen einer Schutzseite.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die App-Überprüfung einen IsBadXXXPtr-Aufruf für eine Speicherbelegung erkennt, die mindestens eine GUARD_PAGE enthält. Dies ist sehr schlecht, da es sehr möglich ist, dass diese GUARD_PAGE das Ende des aktuellen Stapels eines Threads ist. Wie in der MSDN-Bibliothek dokumentiert: Dereferencing potenziell ungültige Zeiger kann die Stapelerweiterung in anderen Threads deaktivieren. Ein Thread, der seinen Stapel erschöpft, wenn die Stapelerweiterung deaktiviert wurde, führt zur sofortigen Beendigung des übergeordneten Prozesses ohne Popupfehlerfenster oder Diagnoseinformationen. Um diesen Stopp zu debuggen, sehen Sie sich die aktuelle Stapelverfolgung (kb) an, und versuchen Sie zu ermitteln, warum der Aufrufer der IsBadXXXPtr-Funktion letztendlich eine GUARD_PAGE untersucht hat. Die MSDN Library listet einige Gründe auf, warum Anwendungen die IsBadXXXPtr-APIs nicht verwenden sollten: In einer präemptiven Multitasking-Umgebung kann ein anderer Thread den Zugriff des Prozesses auf den zu testenden Arbeitsspeicher ändern. Durch deeferencing potenziell ungültige Zeiger kann die Stapelerweiterung in anderen Threads deaktiviert werden. Ein Thread, der seinen Stapel erschöpft, wenn die Stapelerweiterung deaktiviert wurde, führt zur sofortigen Beendigung des übergeordneten Prozesses ohne Popupfehlerfenster oder Diagnoseinformationen. Es wird erwartet, dass Threads in einem Prozess so zusammenarbeiten, dass einer keinen Speicher freigibt, den der andere benötigt. Die Verwendung dieser Funktion macht dies nicht erforderlich. Wenn dies nicht geschieht, schlägt die Anwendung möglicherweise unvorhersehbar fehl. Aus all diesen Gründen wird empfohlen, diese APIs niemals zu verwenden.

Von Application Verifier angezeigte Informationen

• Parameter 1  - Startadresse.
• Parameter 2  - Speicherblockgröße.
• Parameter 3  - Adresse der Wächterseite.
• Parameter 4  - Nicht verwendet.

Weitere Informationen

• Testebene:  Speicher
• Stopp-ID:  PROBE_GUARD_PAGE
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Überprüfung der NULL-Adresse.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die App-Überprüfung einen IsBadXXXPtr-Aufruf mit einer NULL-Adresse erkennt. Um diesen Stopp zu debuggen, sehen Sie sich die aktuelle Stapelablaufverfolgung (kb) an, und versuchen Sie zu ermitteln, warum der Aufrufer der IsBadXXXPtr-Funktion die NULL-Adresse erhalten hat. Dies ist in der Regel das Zeichen, dass jemand den Rückgabewert einer der Speicherzuordnungsfunktionen nicht überprüft. Der folgende Code ist beispielsweise falsch: int Standard (void) { PVOID p; p = malloc (1024); Verwenden Sie (p); 0 zurückgeben; } void Use (PVOID p) { if (IsBadReadPtr (p)) { return; } // // p kann hier sicher verwendet werden. } Dieser Code sollte wie folgt neu geschrieben werden: int Standard (void) { PVOID p; p = malloc (1024); if (NULL == p)) { return -1; } Verwenden Sie (p); 0 zurückgeben; } void Use (PVOID p) { // // p kann hier sicher verwendet werden. } MSDN Library listet einige Gründe auf, warum Anwendungen die IsBadXXXPtr-APIs nicht verwenden sollten: In einer präemptiven Multitasking-Umgebung kann ein anderer Thread den Zugriff des Prozesses auf den zu testenden Arbeitsspeicher ändern. Durch deeferencing potenziell ungültige Zeiger kann die Stapelerweiterung in anderen Threads deaktiviert werden. Ein Thread, der seinen Stapel erschöpft, wenn die Stapelerweiterung deaktiviert wurde, führt zur sofortigen Beendigung des übergeordneten Prozesses ohne Popupfehlerfenster oder Diagnoseinformationen. Es wird erwartet, dass Threads in einem Prozess so zusammenarbeiten, dass einer keinen Speicher freigibt, den der andere benötigt. Die Verwendung dieser Funktion macht dies nicht erforderlich. Wenn dies nicht geschieht, schlägt die Anwendung möglicherweise unvorhersehbar fehl. Aus all diesen Gründen wird empfohlen, diese APIs niemals zu verwenden.

Von Application Verifier 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
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Testspeicherblock mit ungültiger Startadresse oder -größe.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die App-Überprüfung einen IsBadXXXPtr-Aufruf mit einer ungültigen Startadresse (z. B. einer 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 Stapelverfolgung (kb) an, und versuchen Sie zu ermitteln, warum der Aufrufer der IsBadXXXPtr-Funktion eine ungültige Adresse oder Größe aufweist. Oft sind die Adresse oder die Größe einfach falsch, z. B. nicht initialisierte Variablen. Die MSDN Library listet einige Gründe auf, warum Anwendungen die IsBadXXXPtr-APIs nicht verwenden sollten: In einer präemptiven Multitasking-Umgebung kann ein anderer Thread den Zugriff des Prozesses auf den zu testenden Arbeitsspeicher ändern. Durch deeferencing potenziell ungültige Zeiger kann die Stapelerweiterung in anderen Threads deaktiviert werden. Ein Thread, der seinen Stapel erschöpft, wenn die Stapelerweiterung deaktiviert wurde, führt zur sofortigen Beendigung des übergeordneten Prozesses ohne Popupfehlerfenster oder Diagnoseinformationen. Es wird erwartet, dass Threads in einem Prozess so zusammenarbeiten, dass einer keinen Speicher freigibt, den der andere benötigt. Die Verwendung dieser Funktion macht dies nicht erforderlich. Wenn dies nicht geschieht, schlägt die Anwendung möglicherweise unvorhersehbar fehl. Aus all diesen Gründen wird empfohlen, diese APIs niemals zu verwenden.

Von Application Verifier 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
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

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

Wahrscheinliche Ursache

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

Von Application Verifier angezeigte Informationen

• Parameter 1  - DLL-Speicherbasisadresse.
• Parameter 2  - DLL-Speicherbereichsgröße.
• Parameter 3  - DLL-Name-Adresse. Verwenden Sie du, um sie abzuspeichern.
• Parameter 4  - Nicht verwendet.

Weitere Informationen

• Testebene:  Speicher
• Stopp-ID:  INVALID_DLL_RANGE
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Freigeben des Speicherblocks innerhalb des Stackadressbereichs des aktuellen Threads.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die App-Überprüfung einen VirtualFree-Wert für einen Speicherblock erkennt, der tatsächlich Teil des Stapels des aktuellen Threads (!) ist. Sehen Sie sich zum Debuggen dieses Stopps die aktuelle Stapelablaufverfolgung (kb) an, und versuchen Sie zu verstehen, warum die Funktion, die VirtualFree aufgerufen hat, dachte, dass der Speicherblock dynamisch zugeordnet oder zugeordnet wurde, aber tatsächlich Arbeitsspeicher aus dem Stapel zugeordnet war.

Von Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  Speicher
• Stopp-ID:  FREE_THREAD_STACK_MEMORY
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Falscher FreeType-Parameter für VirtualFree-Vorgang.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn der App-Prüfer einen VirtualFree-Wert mit einem falschen Wert für den FreeType-Parameter erkennt. Die einzigen zwei zulässigen Werte für diesen Parameter sind MEM_DECOMMIT und MEM_RELEASE. Wenn VirtualFree mit einem anderen Wert außer diesen beiden aufgerufen wird, kann VirtualFree den Arbeitsspeicher nicht freigeben. Zum Debuggen dieses Stopps sehen Sie sich die aktuelle Stapelüberwachung (kb) an: Der Aufrufer von VirtualFree ist wahrscheinlich der Schuldige.

Von Application Verifier angezeigte Informationen

• Parameter 1  - Falscher Wert, der von der Anwendung verwendet wird.
• Parameter 2  -  Der richtige Wert 1 wurde erwartet.
• Parameter 3  - Der richtige Wert 2 wurde erwartet.
• Parameter 4  - Nicht verwendet.

Weitere Informationen

• Testebene:  Speicher
• Stopp-ID:  INVALID_FREE_TYPE
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Versuchen Sie, den virtuellen Speicherblock freizugeben, der bereits frei ist.

Wahrscheinliche Ursache

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

Von Application Verifier 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
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

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

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die App-Überprüfung einen VirtualFree (MEM_RELEASE) mit einem Wert ungleich 0 für den dwSize-Parameter erkennt. Wenn Sie MEM_RELEASE verwenden, 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. Zum Debuggen dieses Stopps sehen Sie sich die aktuelle Stapelüberwachung (kb) an: Der Aufrufer von VirtualFree ist wahrscheinlich der Schuldige.

Von Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  Speicher
• Stopp-ID:  INVALID_FREE_SIZE
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

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

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Einstiegspunktfunktion einer DLL (DllMain) eine Ausnahme auslöst. Ein Beispiel, warum dies schlecht ist: Wenn DllMain(DLL_PROCESS_ATTACH) eine Ausnahme auslöst, führt das Windows-DLL-Ladeprogramm folgendes aus: - Fängt die Ausnahme ab und blendet sie aus; – Entladen Sie die DLL, ohne dllMain(DLL_PROCESS_DETACH) aufzurufen. In vielen Fällen hat die DLL also bereits einige Ressourcen zugewiesen, dann hat sie die Ausnahme ausgelöst, und sie hat keine Chance, diese Ressourcen auf DllMain (DLL_PROCESS_DETACH) freizugeben. Zum Debuggen dieses Stopps: $ du Parameter1 , um den DLL-Namen anzuzeigen; $ .exr parameter2 – zum Anzeigen der Ausnahmeinformationen; $ .cxr-Parameter3 gefolgt von kb , um die Ausnahmekontextinformationen und die Stapelüberwachung für den Zeitpunkt anzuzeigen, zu dem die Ausnahme ausgelöst wurde; $parameter4 ist die Adresse einer internen Verifiziererstruktur und hat für die meisten Benutzer des Prüfers keine Bedeutung.

Von Application Verifier angezeigte Informationen

• Parameter 1  - DLL-Name (verwenden Sie du, um es abzuspeichern).
• Parameter 2  - Ausnahmedatensatz. Verwenden Sie .exr, um sie anzuzeigen.
• Parameter 3  - Kontextdatensatz. Verwenden Sie .cxr, um sie anzuzeigen.
• Parameter 4  - Verifier-DLL-Deskriptor

Weitere Informationen

• Testebene:  Speicher
• Stopp-ID:  DLL_UNEXPECTED_EXCEPTION
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Unerwartete Ausnahme, die in der Threadfunktion ausgelöst wird.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn eine Threadfunktion eine Ausnahme auslöst. Dies ist schlecht, da der gesamte Prozess beendet wird. Um diesen Stopp zu debuggen: $parameter1 kann für den Ausnahmetyp von Bedeutung sein. Ein Ausnahmecode C0000005 bedeutet z. B. Zugriffsverletzung; $ .exr parameter2 , um die Ausnahmeinformationen anzuzeigen; $ .cxr parameter3 gefolgt von kb : zum Anzeigen der Ausnahmekontextinformationen;

Von Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  Speicher
• Stopp-ID:  THREAD_UNEXPECTED_EXCEPTION
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Unerwartete Ausnahme beim Ermitteln des Arbeitsspeichers.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn während eines IsBadXXXPtr-Aufrufs eine Ausnahme angezeigt wird. Dies bedeutet, dass der Speicherpuffer, den wir testen, nicht über den vom Aufrufer übernommenen Schutz verfügt, oder dass der Speicher bereits freigegeben wurde usw. Weitere Beispiele dafür, warum die Verwendung der IsBadXXXPtr-APIs nicht empfohlen wird, finden Sie in der obigen Diskussion über anderen Stoppcode (PROBE_INVALID_ADDRESS, PROBE_FREE_MEM, PROBE_GUARD_PAGE, PROBE_NULL, PROBE_INVALID_START_OR_SIZE). Um diesen Stopp zu debuggen: $parameter1 ist in der Regel C0000005 und das bedeutet Zugriffsverletzung; $ .exr parameter2 , um die Ausnahmeinformationen anzuzeigen; $ .cxr-Parameter3 gefolgt von kb: Zum Anzeigen der Ausnahmekontextinformationen und der Stapelablaufverfolgung zum Zeitpunkt, zu dem die Ausnahme ausgelöst wurde;

Von Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  Speicher
• Stopp-ID:  PROBE_UNEXPECTED_EXCEPTION
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Versuchen, die NULL-Adresse zurückzusetzen.

Wahrscheinliche Ursache

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

Von Application Verifier 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
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Freigeben des Heapspeicherblocks innerhalb des Stackadressbereichs des aktuellen Threads.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die App-Ü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 Stapelablaufverfolgung (kb) an, und versuchen Sie zu verstehen, warum die Funktion, die HeapFree aufgerufen hat, dachte, dass der Speicherblock dynamisch zugeordnet oder zugeordnet wurde, es sich aber tatsächlich um Arbeitsspeicher handelt, der aus dem Stapel zugewiesen wurde.

Von Application Verifier angezeigte Informationen

• Parameter 1  - Zuordnungsbasisadresse.
• Parameter 2  -  Größe des Speicherbereichs.
• Parameter 3  -  Stapeln sie die Adresse des niedrigen Grenzwerts.
• Parameter 4  -  Stapeladresse mit hohem Grenzwert.

Weitere Informationen

• Testebene:  Speicher
• Stopp-ID:  FREE_THREAD_STACK_MEMORY_AS_HEAP
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Aufheben des Speicherbereichs innerhalb des Stackadressbereichs des aktuellen Threads.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die App-Ü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 Stapelablaufverfolgung (kb) an, und versuchen Sie zu verstehen, warum die Funktion, die UnmapViewOfFile aufgerufen hat, dachte, dass der Speicherblock dynamisch zugeordnet oder zugeordnet wurde, dies aber tatsächlich Arbeitsspeicher war, der aus dem Stapel zugewiesen wurde.

Von Application Verifier angezeigte Informationen

• Parameter 1  - Zuordnungsbasisadresse.
• Parameter 2  -  Größe des Speicherbereichs.
• Parameter 3  -  Stapeln sie die Adresse des niedrigen Grenzwerts.
• Parameter 4  -  Stapeladresse mit hohem Grenzwert.

Weitere Informationen

• Testebene:  Speicher
• Stopp-ID:  FREE_THREAD_STACK_MEMORY_AS_MAP
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace 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 Überprüfungsstopp auslöst. param1 ist die falsche Adresse, die verwendet wird, und der Täter befindet sich in der Stapelablaufverfolgung (mit kb anzeigen).

Von Application Verifier 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
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Ungültige Adresse des kritischen Abschnitts.

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 Überprüfungsstopp auslöst. param1 ist die falsche Adresse, die verwendet wird, und der Täter befindet sich in der Stapelablaufverfolgung (mit kb anzeigen).

Von Application Verifier 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
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

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

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendung versucht, Code von einer Adresse auszuführen, die nicht ausführbar oder frei ist. So debuggen Sie diesen Stopp: $ u parameter2 , um den Tätercode $ .exr parameter3 aufzuheben, um die Ausnahmeinformationen anzuzeigen; $ .cxr-Parameter4 gefolgt von kb, um die Ausnahmekontextinformationen und die Stapelablaufverfolgung für den Zeitpunkt anzuzeigen, zu dem die Ausnahme ausgelöst wurde.

Von Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  Speicher
• Stopp-ID:  THREAD_UNEXPECTED_EXCEPTION_CODE
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Unerwartete Ausnahme beim Initialisieren des Ausgabepuffers.

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 angezeigt wird. Dies bedeutet in der Regel, dass die angegebene Ausgabepuffergröße falsch ist. So debuggen Sie diesen Stopp: $ .exr parameter3 , um die Ausnahmeinformationen anzuzeigen; $ .cxr-Parameter4 gefolgt von kb, um die Ausnahmekontextinformationen und die Stapelablaufverfolgung zum Zeitpunkt anzuzeigen, zu dem die Ausnahme ausgelöst wurde.

Von Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  Speicher
• Stopp-ID:  OUTBUFF_UNEXPECTED_EXCEPTION
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Unerwartete Ausnahme beim Ermitteln der Heapblockgröße.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn beim Aufrufen von HeapSize für einen freigegebenen Heapblock eine Ausnahme angezeigt wird. Dies bedeutet in der Regel, dass die angegebene Heapblockadresse falsch ist oder der Heap beschädigt ist. So debuggen Sie diesen Stopp: $ .exr parameter3 , um den Ausnahmedatensatz anzuzeigen; $ .cxr-Parameter4 gefolgt von kb, um die Ausnahmekontextinformationen und die Stapelablaufverfolgung zum Zeitpunkt anzuzeigen, zu dem die Ausnahme ausgelöst wurde.

Von Application Verifier angezeigte Informationen

• Parameter 1  - Adresse des freigegebenen Heapblocks.
• Parameter 2  Heaphandle .
• Parameter 3  Ausnahmedatensatz . Verwenden Sie .exr, um sie anzuzeigen.
• Parameter 4  - Kontextdatensatz. Verwenden Sie .cxr, um sie anzuzeigen.

Weitere Informationen

• Testebene:  Speicher
• Stopp-ID:  SIZE_HEAP_UNEXPECTED_EXCEPTION
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Freigeben des Speicherblocks mit ungültiger Startadresse.

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 VirtualAlloc- oder VirtualAllocEx-Funktion zurückgegeben wird, wenn die Region der Seiten reserviert wurde; Um dieses Debuggen zu debuggen, beenden Sie folgendes: $ kb , um die aktuelle Stapelablaufverfolgung anzuzeigen, die VirtualFree aufruft. Der wahrscheinliche Schuldige ist die DLL, die VirtualFree aufruft.

Von Application Verifier angezeigte Informationen

• Parameter 1  -  Adresse des freigegebenen Speicherblocks.
• Parameter 2  -  Die richtige Speicherblockadresse wurde erwartet.
• Parameter 3  - Nicht verwendet.
• Parameter 4  - Nicht verwendet.

Weitere Informationen

• Testebene:  Speicher
• Stopp-ID:  INVALID_FREEMEM_START_ADDRESS
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Aufheben des 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 MapViewOfFile- oder MapViewOfFileEx-Funktion zurückgegeben wurde. Zum Debuggen dieses Stop: $ kb – zum Anzeigen der aktuellen Stapelablaufverfolgung, die UnmapViewOfFile aufruft. Der wahrscheinliche Schuldige ist die DLL, die UnmapViewOfFile aufruft.

Von Application Verifier angezeigte Informationen

• Parameter 1  - Adresse des nicht zugeordneten Speicherblocks.
• Parameter 2  -  Die richtige Speicherblockadresse wurde erwartet.
• Parameter 3  - Nicht verwendet.
• Parameter 4  - Nicht verwendet.

Weitere Informationen

• Testebene:  Speicher
• Stopp-ID:  INVALID_UNMAPVIEW_START_ADDRESS
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

unerwartete Ausnahme, die in der Threadpool-Rückruffunktion ausgelöst wird.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn eine Rückruffunktion im Threadpoolthread 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 , um die Ausnahmeinformationen anzuzeigen. $ .cxr parameter3 gefolgt von kb , um die Ausnahmekontextinformationen anzuzeigen.

Von Application Verifier 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
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Code im nicht ausführbaren Arbeitsspeicher

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendung versucht, Code von einer Adresse auszuführen, die nicht ausführbar oder frei ist. So debuggen Sie diesen Stop: $ u parameter2 - zum Aufheben des Übeltätercodes $ .exr parameter3 , um die Ausnahmeinformationen $ .cxr parameter4 gefolgt von kb anzuzeigen, um die Ausnahmekontextinformationen und die Stapelablaufverfolgung für den Zeitpunkt anzuzeigen, zu dem die Ausnahme ausgelöst wurde.

Von Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  Speicher
• Stopp-ID:  THREADPOOL_UNEXPECTED_EXCEPTION_CODE
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Erstellen eines ausführbaren Heaps.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendung einen ausführbaren Heap erstellt. Dies stellt möglicherweise ein Sicherheitsrisiko dar.

Von Application Verifier 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
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Zuweisung von ausführbarem Arbeitsspeicher.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendung ausführbaren Arbeitsspeicher zuzuweisen hat. Dies stellt möglicherweise ein Sicherheitsrisiko dar.

Von Application Verifier angezeigte Informationen

• Parameter 1  -  Seitenschutz, der vom Aufrufer angegeben wird.
• Parameter 2  - Nicht verwendet.
• Parameter 3  - Nicht verwendet.
• Parameter 4  - Nicht verwendet.

Weitere Informationen

• Testebene:  Speicher
• Stopp-ID:  EXECUTABLE_MEMORY
• Code beenden:  600NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

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

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendung versucht, Code von einer Adresse auszuführen, die nicht ausführbar oder frei ist. So debuggen Sie diesen Stopp: $ u parameter2 , um den Tätercode $ .exr parameter3 aufzuheben, um die Ausnahmeinformationen anzuzeigen; $ .cxr-Parameter4 gefolgt von kb, um die Ausnahmekontextinformationen und die Stapelablaufverfolgung für den Zeitpunkt anzuzeigen, zu dem die Ausnahme ausgelöst wurde.

Von Application Verifier angezeigte Informationen

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

Weitere Informationen

• Testebene:  Ausnahmen
• Stopp-ID:  FIRST_CHANCE_ACCESS_VIOLATION_CODE
• Code beenden:  650NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Die Priorität dieses Threadpoolthreads wurde geändert.

Wahrscheinliche Ursache

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

Von Application Verifier 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  - Threadpool-Objektzuordnungsstapelablaufverfolgung, verwenden Sie dps, um sie abzubilden.
• Parameter 4  - Aktuelle Priorität.

Weitere Informationen

• Testebene:  Threadpool
• Stopp-ID:  INCONSISTENT_PRIORITY
• Code beenden:  700NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Die Affinität dieses Threadpoolthreads wurde geändert.

Wahrscheinliche Ursache

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

Von Application Verifier angezeigte Informationen

• Format:  Threadpoolthread  (%x) mit Ausgeführtem Rückruf (%p) weist eine geänderte Threadaffinitätsmaske (%p -> %p) auf.
• Parameter 1  - Rückruffunktion.
• Parameter 2  - Kontext.
• Parameter 3  - Threadpool-Objektzuordnungsstapelablaufverfolgung, verwenden Sie dps, um sie abzubilden.
• Parameter 4  - Aktuelle Affinität.

Weitere Informationen

• Testebene:  Threadpool
• Stopp-ID:  INCONSISTENT_AFFINITY_MASK
• Code beenden:  700NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Nicht verarbeitete msg im msg-Pool des aktuellen Threads.

Wahrscheinliche Ursache

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

Von Application Verifier angezeigte Informationen

• Format:  - threadpoolthread (%x) mit ausgeführtem Rückruf (%p) weist eine ausstehende Fenstermeldung auf (%x: %x)
• Parameter 1  - Rückruffunktion.
• Parameter 2  - Kontext.
• Parameter 3  - Threadpool-Objektzuordnungsstapelablaufverfolgung, verwenden Sie dps, um sie abzubilden.
• Parameter 4  Threadpool-Thread-ID . Verwenden Sie !avrf -tp <threadid> , um die an diesen Thread gesendeten Nachrichten anzuzeigen.

Weitere Informationen

• Testebene:  Threadpool
• Stopp-ID:  ORPHANED_THREAD_MESSAGE
• Code beenden:  700NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Das nicht geschlossene Fenster gehörte zum aktuellen Thread.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn ein Beliebiges Fenster am Leben erhalten bleibt, wenn dieser Threadpoolthread an den Pool zurückgegeben wird.

Von Application Verifier angezeigte Informationen

• Format:  -  Threadpoolthread (%x) mit ausgeführtem Rückruf (%p) hat einen gültigen hwnd (%x: %s), der Nachrichten empfangen kann
• Parameter 1  - Rückruffunktion.
• Parameter 2  - Kontext.
• Parameter 3  - Threadpool-Objektzuordnungsstapelablaufverfolgung, verwenden Sie dps, um sie abzubilden.
• Parameter 4  Threadpool-Thread-ID .

Weitere Informationen

• Testebene:  Threadpool
• Stopp-ID:  ORPHANED_THREAD_WINDOW
• Code beenden:  700NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

ExitThread() für einen Threadpoolthread.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn ExitThread für einen Threadpoolthread aufgerufen wird. Es ist verboten, da es das System instabil machen wird. Dies führt zu Ressourcenlecks, Einfrieren oder AV.

Von Application Verifier angezeigte Informationen

• Parameter 1  - Rückruffunktion.
• Parameter 2  - Kontext.
• Parameter 3  - Threadpool: Ablaufverfolgung des Objektzuordnungsstapels, verwenden Sie dps, um sie abzuspeichern.
• Parameter 4  - Nicht verwendet.

Weitere Informationen

• Testebene:  Threadpool
• Stopp-ID:  ILLEGAL_THREAD_EXIT
• Code beenden:  700NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

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

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Rückruffunktion das Threadtoken so ändert, dass es die Identität eines anderen Benutzers angibt und vergessen hat, es zurückzusetzen, bevor es an den Threadpool zurückgegeben wird.

Von Application Verifier angezeigte Informationen

• Parameter 1  - Rückruffunktion.
• Parameter 2  - Kontext.
• Parameter 3  - Threadpool: Ablaufverfolgung des Objektzuordnungsstapels, verwenden Sie dps, um sie abzuspeichern.
• Parameter 4  - Nicht verwendet.

Weitere Informationen

• Testebene:  Threadpool
• Stopp-ID:  THREAD_IN_IMPERSONATION
• Code beenden:  700NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Eine Funktion, die einen persistenten Thread erfordert, wird aufgerufen.

Wahrscheinliche Ursache

Einige Microsoft Windows-APIs müssen in einem dedizierten oder persistenten Thread aufgerufen werden. Im Threadpool sollten Sie im Allgemeinen die Verwendung des lokalen Threadspeichers und die Warteschlangen von asynchronen Aufrufen vermeiden, die einen persistenten Thread erfordern, z. B. die RegNotifyChangeKeyValue-Funktion. Solche Funktionen können jedoch mithilfe von QueueUserWorkItem mit der Option WT_EXECUTEINPERSISTENTTHREAD in die Warteschlange eines persistenten Workerthreads eingereiht werden. Ein Kb im Debugger zeigt den Aufrufer an.

Von Application Verifier angezeigte Informationen

• Parameter 1  - Rückruffunktion.
• Parameter 2  - Kontext.
• Parameter 3  - Threadpool: Ablaufverfolgung des Objektzuordnungsstapels, verwenden Sie dps, um sie abzuspeichern.
• Parameter 4  - Nicht verwendet.

Weitere Informationen

• Testebene:  Threadpool
• Stopp-ID:  PERSISTED_THREAD_NEEDED
• Code beenden:  700NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Der Thread befindet sich in modifiziert Transaktionszustand.

Wahrscheinliche Ursache

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

Von Application Verifier angezeigte Informationen

• Parameter 1  - Rückruffunktion.
• Parameter 2  - Kontext.
• Parameter 3  - Threadpool: Ablaufverfolgung des Objektzuordnungsstapels, verwenden Sie dps, um sie abzuspeichern.
• Parameter 4  Transaktionshandle .

Weitere Informationen

• Testebene:  Threadpool
• Stopp-ID:  DIRTY_TRANSACTION_CONTEXT
• Code beenden:  700NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Dieser Threadpoolzustand verfügt über unausgeglichene CoInit- und CoUnInit-Aufrufe.

Wahrscheinliche Ursache

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

Von Application Verifier angezeigte Informationen

• Parameter 1  - Rückruffunktion.
• Parameter 2  - Kontext.
• Parameter 3  - Threadpool: Ablaufverfolgung des Objektzuordnungsstapels, verwenden Sie dps, um sie abzuspeichern.
• Parameter 4  - Ausgeglichene Anzahl von Anrufen.

Weitere Informationen

• Testebene:  Threadpool
• Stopp-ID:  DIRTY_COM_STATE
• Code beenden:  700NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace 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 der Zeitraum zum Signalisieren des Timers nicht null ist, wenn der Timer nur einmal mit dem WT_EXECUTEONLYONCE-Flag signalisiert wird.

Von Application Verifier 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
• Code beenden:  700NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

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

Wahrscheinliche Ursache

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

Von Application Verifier angezeigte Informationen

• Parameter 1  - Rückruffunktion.
• Parameter 2  - Kontext.
• Parameter 3  - Threadpool-Objektzuordnungsstapelablaufverfolgung, verwenden Sie dps, um sie abzubilden.
• Parameter 4  - Nicht verwendet.

Weitere Informationen

• Testebene:  Threadpool
• Stopp-ID:  LOADER_LOCK_HELD
• Code beenden:  700NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

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

Wahrscheinliche Ursache

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

Von Application Verifier angezeigte Informationen

• Parameter 1  - Rückruffunktion.
• Parameter 2  - Kontext.
• Parameter 3  - Threadpool-Objektzuordnungsstapelablaufverfolgung, verwenden Sie dps, um sie abzubilden.
• Parameter 4  - Nicht verwendet.

Weitere Informationen

• Testebene:  Threadpool
• Stopp-ID:  PREFERRED_LANGUAGES_SET
• Code beenden:  700NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

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

Wahrscheinliche Ursache

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

Von Application Verifier angezeigte Informationen

• Parameter 1  - Rückruffunktion.
• Parameter 2  - Kontext.
• Parameter 3  - Threadpool-Objektzuordnungsstapelablaufverfolgung, verwenden Sie dps, um sie abzubilden.
• Parameter 4  - Nicht verwendet.

Weitere Informationen

• Testebene:  Threadpool
• Stopp-ID:  BACKGROUND_PRIORITY_SET
• Code beenden:  700NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

TerminateThread() für einen Threadpoolthread.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn TerminateThread in einem Threadpoolthread aufgerufen wird. Es ist verboten, da das System dadurch instabil wird. Dies führt zu Ressourcenverlust, Einfrieren oder AV.

Von Application Verifier 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
• Code beenden:  700NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Der Stapel wurde entladen, wenn ein asynchroner E/A-Vorgang aussteht.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendung einen E/A-Vorgang ausgegeben hat, der eine Stapelvariable verwendet und nicht auf den Abschluss der E/A gewartet hat, was zu stapelbeschädigungen führt. So debuggen Sie diesen Stopp: $ dps parameter4, um die Stapelablaufverfolgung anzuzeigen, als die E/A ausgegeben wurde. Parameter1 gibt die stapelbasierte Adresse und parameter3 den Thread an, der die E/A ausgegeben hat.

Von Application Verifier angezeigte Informationen

• Parameter 1  - Adresse der Stapelvariablen, die in der E/A verwendet wird.
• Parameter 2  -  Aktueller Stapelzeiger.
• Parameter 3  -  Ursprünglicher Thread, der die E/A ausgegeben hat.
• Parameter 4  -  Stapelablaufverfolgung, wenn die E/A ausgegeben wurde.

Weitere Informationen

• Testebene:  IO
• Stopp-ID:  ASYNCIO_STACK_UNWIND
• Code beenden:  800NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Der Stapel wurde beschädigt, wenn ein asynchroner E/A-Vorgang aussteht.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendung einen E/A-Vorgang ausgegeben hat, der eine Stapelvariable verwendet und nicht auf den Abschluss der E/A gewartet hat, was zu stapelbeschädigungen führt. So debuggen Sie diesen Stopp: $ dps parameter4, um die Stapelablaufverfolgung anzuzeigen, als die E/A ausgegeben wurde. Parameter1 gibt die stapelbasierte Adresse und parameter3 den Thread an, der die E/A ausgegeben hat.

Von Application Verifier angezeigte Informationen

• Parameter 1  -  Adresse der Stapelvariablen, die in der E/A verwendet wird.
• Parameter 2  -  Aktueller Stapelzeiger.
• Parameter 3  -  Ursprünglicher Thread, der die E/A ausgegeben hat.
• Parameter 4  -  Stapelablaufverfolgung, wenn die E/A ausgegeben wurde.

Weitere Informationen

• Testebene:  IO
• Stopp-ID:  ASYNCIO_CORRUPTED_STACK
• Code beenden:  800NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Verwenden einer freigegebenen Adresse in einem ausstehenden E/A-Vorgang.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendung einen E/A-Vorgang ausgegeben und den in der E/A verwendeten Arbeitsspeicher vor Abschluss der E/A freigegeben hat, was zu Speicherbeschädigungen usw. führt. So debuggen Sie diesen Stopp: $ dps parameter4, um die Stapelablaufverfolgung anzuzeigen, als die E/A ausgegeben wurde. Parameter1 gibt die Adresse an, die in der E/A verwendet wird. Parameter2 gibt die freigegebene Adresse und parameter3 den Thread an, der die E/A ausgegeben hat.

Von Application Verifier angezeigte Informationen

• Parameter 1  - Adresse, die in der E/A verwendet wird.
• Parameter 2  - Adresse wird freigegeben.
• Parameter 3  -  Ursprünglicher Thread, der die E/A ausgegeben hat.
• Parameter 4  -  Stapelablaufverfolgung, wenn die E/A ausgegeben wurde.

Weitere Informationen

• Testebene:  IO
• Stopp-ID:  FREED_ADDRESS_IN_PENDINGIO
• Code beenden:  800NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Ein E/A-status-Block (OVERLAPPED) wird wiederverwendet, während die zugeordnete E/A-Anforderung noch aussteht.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Anwendung einen E/A-status-Block (OVERLAPPED) wiederverwendet hat, während eine E/A-Anforderung mit diesem E/A-status-Block (OVERLAPPED) noch aussteht. So debuggen Sie diesen Stopp: $ dps parameter3, um die Stapelablaufverfolgung anzuzeigen, als die ursprüngliche E/A ausgegeben wurde. Parameter1 gibt die Adresse an, die in der E/A und parameter2 des Threads verwendet wird, der die E/A ausgegeben hat.

Von Application Verifier angezeigte Informationen

• Parameter 1  - Adresse des E/A-status-Blocks (OVERLAPPED).
• Parameter 2  -  Ursprünglicher Thread, der die E/A ausgegeben hat.
• Parameter 3  -  Stapelablaufverfolgung, wenn die E/A ausgegeben wurde.
• Parameter 4  - Nicht verwendet.

Weitere Informationen

• Testebene:  IO
• Stopp-ID:  REUSED_IOSTATUS_BLOCK
• Code beenden:  800NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Verwenden eines nicht unterstützten Flags FILE_ATTRIBUTE_NOT_CONTENT_INDEXED in CreateFile

Wahrscheinliche Ursache

In der alten Version des MSDN wurde CreateFile fälschlicherweise als unterstützende FILE_ATTRIBUTE_NOT_CONTENT_INDEXED dokumentiert. Wenn dieses Flag vorgesehen ist, sollte es mithilfe anderer API-Funktionen wie SetFileAttributes festgelegt werden. $ln Parameter1, um den Aufrufer von CreateFile zu finden.

Von Application Verifier angezeigte Informationen

• Format:  -  CreateFile beim Schreiben von %hs%ws mit flags %08x %08x %08x
• Parameter 1  -  Adresse zurückgeben.
• Parameter 2  - Nicht verwendet.
• Parameter 3  - Nicht verwendet.
• Parameter 4  - Nicht verwendet.

Weitere Informationen

• Testebene:  IO
• Stopp-ID:  USING_BAD_CREATEFILE_FLAG
• Code beenden:  800NAN
• Schweregrad:  Warnung
• Einmalfehler: 
• Fehlerbericht:  Nichts
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Eine Heapzuordnung wurde geleakt.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Besitzer-DLL der Zuordnung beim Besitz von Ressourcen dynamisch entladen wurde.

Von Application Verifier angezeigte Informationen

• Parameter 1  - Adresse der geleakten Zuordnung. Führen Sie !heap -p -a address> aus<, um zusätzliche Informationen zur Zuordnung abzurufen.
• Parameter 2  - Adresse für die Zuordnungsstapelablaufverfolgung. Führen Sie dps address> aus<, um den Zuordnungsstapel anzuzeigen.
• Parameter 3  - Adresse des Besitzer-DLL-Namens. Führen Sie du <address> aus, um den DLL-Namen zu lesen.
• Parameter 4  - Basis der Besitzer-DLL. Führen Sie .reload <dll_name> = <address> 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:  ZUTEILUNG
• Code beenden:  900NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Ein Handle wurde geleakt.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Besitzer-DLL des Handles beim Besitz von Ressourcen dynamisch entladen wurde. Um diesen Stopp zu debuggen: Führen Sie !htrace parameter1 aus, um zusätzliche Informationen zum Handle abzurufen.

Von Application Verifier angezeigte Informationen

• Parameter 1  - Wert des geleakten Handles. Führen Sie das !htrace-Handle <> aus, um zusätzliche Informationen zum Handle abzurufen, wenn die Handle-Ablaufverfolgung aktiviert ist.
• Parameter 2  - Adresse für die Zuordnungsstapelablaufverfolgung. Führen Sie dps address> aus<, um den Zuordnungsstapel anzuzeigen.
• Parameter 3  - Adresse des Besitzer-DLL-Namens. Führen Sie du <address> aus, um den DLL-Namen zu lesen.
• Parameter 4  - Basis der Besitzer-DLL. Führen Sie .reload <dll_name> = <address> 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:  BEHANDELN
• Code beenden:  900NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Ein HKEY wurde geleakt.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Besitzer-DLL des Registrierungsschlüssels beim Besitz von Ressourcen dynamisch entladen wurde.

Von Application Verifier angezeigte Informationen

• Parameter 1  - Wert des geleakten HKEY.
• Parameter 2  - Adresse für die Zuordnungsstapelablaufverfolgung. Führen Sie dps address> aus<, um den Zuordnungsstapel anzuzeigen.
• Parameter 3  - Adresse des Besitzer-DLL-Namens. Führen Sie du <address> aus, um den DLL-Namen zu lesen.
• Parameter 4  - Basis der Besitzer-DLL. Führen Sie .reload <dll_name> = <address> 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:  REGISTRIERUNG
• Code beenden:  900NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Eine virtuelle Reservierung wurde geleakt.

Wahrscheinliche Ursache

Dieser Stopp wird generiert, wenn die Besitzer-DLL der virtuellen Reservierung beim Besitz von Ressourcen dynamisch entladen wurde.

Von Application Verifier angezeigte Informationen

• Parameter 1  - Die Reservierungsadresse wurde durchgesickert.
• Parameter 2  - Adresse für die Zuordnungsstapelablaufverfolgung. Führen Sie dps address> aus<, um den Zuordnungsstapel anzuzeigen.
• Parameter 3  - Adresse des Besitzer-DLL-Namens. Führen Sie du <address> aus, um den DLL-Namen zu lesen.
• Parameter 4  - Basis der Besitzer-DLL. Führen Sie .reload <dll_name> = <address> 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
• Code beenden:  900NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Ein BSTR wurde geleakt.

Wahrscheinliche Ursache

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

Von Application Verifier angezeigte Informationen

• Parameter 1  - Adresse des geleakten BSTR. Führen Sie !heap -p -a address> aus<, um zusätzliche Informationen zur Zuordnung abzurufen.
• Parameter 2  - Adresse für die Zuordnungsstapelablaufverfolgung. Führen Sie dps address> aus<, um den Zuordnungsstapel anzuzeigen.
• Parameter 3  - Adresse des Besitzer-DLL-Namens. Führen Sie du <address> aus, um den DLL-Namen zu lesen.
• Parameter 4  - Basis der Besitzer-DLL. Führen Sie .reload <dll_name> = <address> 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
• Code beenden:  900NAN
• Schweregrad:  Fehler
• Einmalfehler: 
• Fehlerbericht:  Brechen
• Melden Sie sich an die Datei an:  Ja
• Backtrace erstellen:  Ja

Die Registrierung einer Energiebenachrichtigung wurde nicht aufgehoben.

Wahrscheinliche Ursache

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

Von Application Verifier angezeigte Informationen

• Parameter 1  - Adresse der Energiebenachrichtigungsregistrierung.
• Parameter 2  - Adresse für die Ablaufverfolgung des Registrierungsstapels. Führen Sie dps address> aus<, um den Zuordnungsstapel anzuzeigen.
• Parameter 3  - Adresse des Besitzer-DLL-Namens. Führen Sie du <address> aus, um den DLL-Namen zu lesen.
• Parameter 4  - Basis der Besitzer-DLL. Führen Sie .reload <dll_name> = <address> 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
• Code beenden:  900NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Eine COM-Zuordnung wurde durchgesickert.

Wahrscheinliche Ursache

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

Von Application Verifier angezeigte Informationen

• Parameter 1  - Adresse der kompromittierten COM-Zuordnung. Führen Sie !heap -p -a-Adresse> aus<, um zusätzliche Informationen zur Zuordnung zu erhalten.
• Parameter 2  -  Adresse an die Zuordnungsstapelablaufverfolgung. Führen Sie dps <address> aus, um den Zuordnungsstapel anzuzeigen.
• Parameter 3  - Adresse des Besitzer-DLL-Namens. Führen Sie du <address> aus, um den DLL-Namen zu lesen.
• Parameter 4  - Base der Besitzer-DLL. Führen Sie .reload <dll_name> = <address> 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:  COM_ALLOCATION
• Code beenden:  900NAN
• Schweregrad:  Fehler
• Einmaliger Fehler: 
• Fehlerbericht:  Brechen
• Protokollieren in Datei:  Ja
• Backtrace erstellen:  Ja

Weitere Informationen

Application Verifier – Stoppcodes und Definitionen

Application Verifier – Übersicht

Application Verifier – Features

Application Verifier – Testen von Anwendungen

Application Verifier – Tests in Application Verifier

Application Verifier – Debuggen der Anwendungsüberprüfung wird beendet

Application Verifier – Häufig gestellte Fragen